I Built a Fortune-Telling Platform Just to See If Vibe Coding Was Real

Vibe coding is everywhere in developer circles right now. You describe what you want in plain language, the AI writes the code, and when it breaks you paste the error back and let it fix itself. Inflate that a little and you get "you don't need to know how to code to ship a service anymore."

My first reaction to claims like that is doubt.

Is that actually true?

Not "can it spit out a Todo app" — can it produce something a stranger would use and pay for? That's what I wanted to know. For the subject matter I picked saju, Korean fortune-telling, because I was already into it. That's how the saju platform started.

I wasn't trying to found a company

I didn't sit down and decide to go into the fortune-telling business. It started as a technical itch. If AI can generate code at this level, how far can one person push a single product?

Building a real service used to mean holding a lot in your head at once. Frontend. Backend. Database design. UI. Server setup. Auth. Domain wiring. Production environment. Scale it up even slightly and one developer carrying all of that stops being realistic.

AI started shaking that structure loose.

So the question I actually cared about wasn't about saju at all. With AI in the loop, can one person carry a service all the way to the finish?

Why saju, of all things

Boring answer: I was already interested in it.

I didn't want to build yet another Todo app I don't care about just to test vibe coding. It has to be something you'd use yourself, because then questions keep surfacing while you build. Things like "wait, should this screen really look like this?"

Saju turns out to be a genuinely interesting domain through a developer's eyes. There's an input — date and time of birth. You run rules over it. You interpret the relationships between the computed results. Then you have to turn something fairly tangled into language a human can follow.

Strip it down and it looks like this:

Input → Rule → Calculation → Interpretation → Output

Plenty of slots to drop AI into. That's what made it fun as a test case.

Then it went further than I expected

It really was an experiment at the start. Build a screen. Bolt on a feature. Have the AI fix it. Rip it out if I didn't like it.

But things piled up and it started to look like a service. Screens appeared, data got wired together, and there was a real flow taking user input and returning a result.

At first it was just "huh, AI can do this much." Then I was sitting in front of the monitor at two in the morning flipping through screens and my thinking shifted.

"Hold on. Could I actually launch this?"

Now I'm at the point of preparing to open it up. The one big piece left is payments. And that raised another question.

Adding payments changes what the experiment is

A free program I built for myself and a service I charge strangers for are different objects.

The moment money is involved, users become customers. You can't stop at "the feature works." Is it worth paying for? What happens if the payment errors out mid-flow? What if someone says they don't like their result? How do I handle personal data? What about outages? How do costs move as users grow? Who takes refunds and support requests?

All the non-engineering problems arrive at once. This is where I think vibe coding actually gets tested.

Making code and making a product aren't the same

One thing became obvious while working with AI: the cost of producing code has dropped enormously.

Features I'd have skipped out of sheer laziness, I now just build. Throwing one away and redoing it is cheap too. When an idea shows up, instead of first litigating whether it's feasible, I just make it. That shift is bigger than it sounds.

But something else came into focus at the same time. AI writing the code doesn't hand you a good product.

Deciding what to build was still on me. How far to take a feature, which structure is right, whether the AI had wandered off somewhere strange — I had to be the one looking.

And there was one more thing. Breaking work into pieces.

Delegating to AI changed what my job is

When I needed a feature, my first thought used to be:

"How do I implement this?"

Working with AI, the question changed:

"How do I split this up and hand it off?"

Start with the screen or the data model? How much do I delegate, and where do I check the output? Those decisions come first now. Handing over a small, carved-out piece beat throwing the whole problem over the wall more often than not.

That gave me an odd feeling. This wasn't development so much as the delegation and management I do in other parts of my job. Set the goal, split the work, hand it off, review what comes back, redirect when it drifts, stitch it together at the end.

That's why it feels like part of the developer role is sliding from executor toward conductor.

So does development experience stop mattering?

I want to be careful here.

Jumping from "vibe coding got easy" to "you don't need engineering knowledge anymore" is premature. Building this thing, I ran into the opposite.

My hands-on coding time went down, but judging whether the AI's output is wrong drew on every year of experience I have. Is the structure over-engineered? Any security holes? Does the data flow line up? Does this work today but blow up later? A human had to look at that.

Coding skill didn't lose its value. It moved. From writing every line yourself, to designing, judging, and verifying what the AI produced.

The real surprise was the cost of trying

The biggest change I felt wasn't development speed. It was the cost of failure dropping.

An idea used to trigger arithmetic. How long to build? What about design? Servers? Maintenance? Do I need to hire someone? Is the business case solid? And then it dies before anything gets built. I've killed several that way. Some of them still sting.

When building gets cheap, behavior changes. You build it first and judge after.

That difference is huge. If the startup sequence used to be idea → business case → funding → build, in some domains it might become idea → build with AI → watch how people react → decide if it's a business. Production cost has fallen far enough that building can come before validating the business case.

Now for the actual experiment

Building the saju platform confirmed that vibe coding is pretty strong at producing a product.

What I haven't confirmed is whether anyone will actually pay.

I think this is where it gets interesting. AI building a service and that service having value in a market are two different problems.

So I'm going to wire up payments and open it. See who shows up, who uses it, who comes back, who makes it to checkout.

Maybe nobody pays. That's a result too. It would tell me AI can cut your development bill but won't hand you customers.

If someone does pay, a different question opens up. Has it actually become possible for one person plus AI to build, sell, and operate a thing?

I want to see that for myself. Which is why this saju platform is, to me, less a fortune-telling service than something else. It's the first test of how far one person can get in the AI era.

The building is basically done. Who'll use it, I don't know yet.