How I Vibe Coded 3 SaaS Apps with Enterprise Features (and What I Learned)

I vibe-coded 3 apps using AI — then hit a wall. So I invented a new reasoning layer to fix it. This is how I went from chaos to clarity

I didn’t plan to invent an API.

I just wanted to build fast.
So I did what every founder with no team and a hundred ideas does:
I opened Cursor, fired up Sonnet, and started vibe coding.

Three apps later — Search+, Zenplus, and Novaheadshot — I had over 20,000 users, tons of product feedback, and something I didn’t expect:

A wall.

Agents were hallucinating.
Code review time was eating me alive.
The bigger the feature, the messier the prompts.
And I kept realizing something no one talks about:

The bottleneck isn’t code.
It’s reasoning.

I was hitting what I now call the Reasoning Ceiling — the point where pattern-matching breaks down and the model can’t go any further.

So I started writing down every pattern, every failure, every workaround.
Eventually, it clicked. I wasn’t just coding — I was discovering the rules of AI-first development.

That’s when I built the Reasoning API — a system that turns natural prompts into structured specs, detects ambiguity, and reduces hallucination across the stack.
It’s how I went from “shipping chaos” to building production-grade tools as a solo founder.

In this post, I’ll share:

• What I learned building 3 real apps with just AI and vibes

• The theories that changed how I think about intelligence

• The tools I had to build just to move faster

• Why the Reasoning API might change how AI apps are built next

And at the end — if you’re building with AI and tired of guessing — you’ll be able to try it too.

Vibe Coding Three Real Apps

I wasn’t trying to prove a theory. I was just trying to ship.

I built:

• Search+ – A document search tool that lets users ask real questions of thousand-page PDFs.

• Zenplus – A voice AI that answers calls, schedules appointments, and runs on autopilot.

• Novaheadshot – An AI tool for generating professional, studio-quality headshots.

I built all three solo — using Cursor, Claude Code, LLMs, and a lot of caffeine.

No fixed roadmap. No heavy planning.
Just a prompt, an agent, and a loose vision of what I wanted to exist.

And it worked.
I was shipping fast.
Users were signing up.
Features were flying out the door.

But over time… I started noticing the cracks.

• Agents would refactor entire files for no reason.

• I’d spend days reviewing and rewriting AI-generated code.

• Features that felt "done" would break the moment a new one was added.

• The same prompt would work on Monday and fail on Thursday.

I was moving fast — but burning out.
And I started asking myself:

Why does AI coding feel so good at first… and so chaotic when it gets serious?

The Wall: When Vibes Weren’t Enough

At some point, I realized I wasn’t coding anymore — I was firefighting.

The AI could generate a button, a handler, even a whole backend flow.
But it didn’t know why I wanted it.
Or what should be out of scope.
Or when something was “done.”

Every time I hit friction, it was the same root problem:

The agent didn’t know how to reason.

It knew how to autocomplete.
It didn’t know how to hold constraints in place.

And the more complex the app got — the more the hallucinations crept in, the more review time exploded, the more I started second-guessing whether AI could even scale as a dev tool.

That’s when I realized:
I was hitting the Reasoning Ceiling.

The limit where pattern-matching breaks down.
Where LLMs stop feeling magical and start feeling… brittle.
Where the agent sounds confident, but delivers code that collapses under real world complexity.

I would spend Monday morning creating the perfect PRD for a comprehensive feature that would’ve taken me months to build as an engineer pre-AI.
I’d spend the rest of the day using Cursor and Claude Code to generate the code.
Then I’d spend the rest of the week reviewing that code, rewriting the broken parts, and plugging in missing logic.

Yes — code generation was exponentially faster.
But code review became the bottleneck.
I wasn’t building faster. I was just shifting the pain downstream.

That’s when I stopped prompting and started asking a different question:

What if we taught the AI what we wanted — not how to do it, but what mattered, what shouldn’t break, and what success actually looked like?

That’s when I started writing down patterns.
The things I kept saying over and over in prompts.
The boundaries I kept forgetting to specify.
The success criteria I kept assuming the model “got.”

And little by little, that became a language.
That language became a theory.
And that theory became the backbone of everything I’ve built since.

From Chaos to Clarity: The Theories That Changed Everything

The first breakthrough came when I started thinking in triples:

What I wanted.
Boundaries I needed to respect.
Success I expected to see.

That became the core of everything — a simple mental model I called WBS:
What – Boundaries – Success.

Let me show what this looks like for a real feature

Before (A “vibe” prompt):

Hey Claude, add a rate limiter to my login API to stop brute force attacks.

This seems clear, but the AI is forced to guess a dozen details. The result is often wrong.

After (A What-Boundaries-Success Spec):

Feature: Authentication {
  What:
    - "Prevent brute force login attacks by limiting requests per IP."
    
  Boundaries:
    - "Limit: 10 failed attempts per IP per hour."
    - "Use Redis for tracking counts."
    - "Do not rate-limit successful logins."
    
  Success:
    - "An IP is correctly blocked after the 11th failed attempt."
    - "A legitimate user is never blocked."
}

The difference is night and day. There's no ambiguity. I'm no longer asking the AI to read my mind; I'm giving it a precise, testable blueprint.

The moment I did that, the hallucination rate dropped.
The model started behaving more predictably.
Code generation felt less like gambling, more like collaboration.

That was the moment I realized something:

Intelligence doesn’t scale with more compute. It scales with clearer constraints.

That idea became Bora’s Law — a principle I now live by:

🧠 Bora’s Law

I = Bi(C²) — Intelligence scales exponentially with constraints, not compute.

It wasn’t about making the AI smarter.
It was about limiting the solution space so it couldn’t wander off and invent things I didn’t ask for.

Later, I developed ideas like:

• CBTL (Constraint-Based Transfer Learning) — teaching the system how to generalize constraints across tasks and domains.

• Constraint Graphs — so boundaries could be reused across features, apps, even different LLMs.

• IntentAPI — a new constraint-based API architecture aimed at reducing hallucinations.

• Natural Boundary Theory — a fundamental solution to recursive decomposition in constraint-driven systems: break work down until it reaches naturally executable units, not arbitrary task lengths

  • Human-sized chunks

  • Measurable outcomes

  • Implementable in under 2–4 hours

Instead of “guess-and-check” loops, the system now decomposes with intention — and stops when each part becomes clearly human-executable. It’s how I prevent infinite agent recursion and keep reasoning grounded.

All of these ideas — and more — are part of what I now call Intent Science: a full mathematical and engineering framework for turning ideas into reality through structured constraints.

These practical insights grew into a full engineering philosophy. For those who want to go down the rabbit hole, I’ve published the deeper theory here:
Fundamental Theories of Intent Science (Substack)

And eventually, all of this turned into something real — something I could call an actual product.

The Reasoning API.

Building the Reasoning API: My Personal Productivity Engine

At some point I realized:
I was spending more time re-prompting and reviewing than actually building.
So I asked: What if I didn’t just write specs for the model? What if I built a system that did it for me?

That’s what the Reasoning API became.

A layer that sits between me and the LLM.
It takes in natural prompts — messy, human ones — and converts them into clean, structured WBS specs.

Then it runs those specs through a pipeline I built:

• Detects ambiguity → asks clarifying questions

• Decomposes requests using natural human boundaries

• Reduces hallucination by using a growing library of constraints and enforcing historical constraints

• Reuses success criteria across features

• Automatically maps vague intent into concrete boundaries

For example, when building a core feature for Zenplus, I gave it a high-level request for a "daily approvals workflow."
The Reasoning API came back with a complete constraint discovery plan.

This is what the engine looks like in action. You’ll notice:

• Each part of the system is scoped by domain

• Constraints are organized by WBS

• Boundaries link to AISpecs and IntentAPI structures

• The system prepares to systematically discover constraints across all domains

This isn't a toy example.
This is a production-grade spec for a complex backend feature, identifying everything from the database models to the business logic.
It's the thinking scaffold that lets me build enterprise features solo.

It wasn’t just better outputs.
It was faster everything:

• Code generation time dropped

• Review time dropped

• Rollbacks dropped

• Features became easier to ship and keep stable

When I hooked it up to Cursor, it felt like my AI pair programmer finally understood me.
When I used it with Claude Code, it stopped generating "maybe this?" code and started hitting real targets.

And the biggest surprise?
It worked across all three apps — Search+, Zenplus, and Novaheadshot — even though they’re totally different products.

Because what I had built wasn’t a feature.
It was a thinking scaffold.
And once I had that, the rest moved fast.

Try It Yourself — Reasoning API is Now in Beta

I didn’t build this for fun.

I built it because I had to.
Because vibe coding stops working when the stakes get real.
Because LLMs don’t need more prompting — they need clarity.

And now, that clarity is available to you too.

The Reasoning API is in private beta. It integrates with tools such Cursor and Claude Code through the MCP (Model Context Protocol).
It’s the engine behind how I built Search+, Zenplus, and Novaheadshot — the same tools that now serve over 20,000 users.

Everything I’ve learned, every framework I developed — WBS, Bora’s Law, CBTL, The Natural Boundary Theory, the IntentAPI — it’s all baked in.

• Structure your requests

• Reduce hallucination

• Speed up implementation

• Catch ambiguity before it becomes tech debt

If you’re building with AI — agents, apps, internal tools, whatever — and you’re tired of chaotic prompting and brittle outputs, this might be the layer you've been missing.

👉 Join the Reasoning API waitlist