Philosophy
From vibe to viable.
You shipped a prototype with Lovable, Bolt, or Replit. It proved a market. Now the next decision is who builds the real version. This is the gap, and how Sulis closes it.
Things you don't learn
Universities teach algorithms. Bootcamps teach frameworks. The Missing Semester (MIT's free course on the tools nobody taught you) teaches the shell, git, and debugging. None of them teach what keeps a system alive once real users find it. That's the gap Sulis fills — and the gap this page is about.
Two gaps, not one
Two gaps sit between a working prototype and a viable product.
The first is cultural. The production knowledge — auth, observability, idempotency, the boring-but-critical reasoning — used to be picked up by accident, working alongside engineers who had seen things break before. That apprenticeship is now rare; AI build tools have taken its place.
AI build tools are genuinely good at one job: getting an idea on the screen. You describe what you want, you get a working interface, and within an afternoon you have something that demos. That's the vibe.
The second gap is technical. What comes out the other side is a prototype. The frontend works because frontends are forgiving — one user, no concurrent requests, no real money moving. The backend that came with it isn't built to survive contact with reality. Auth tokens are trusted on faith. Payments charge without idempotency. Emails get stored without consent. There's no observability, no rate limits, no errors surfaced. The first real customer to hit an edge case finds out before anyone else.
This isn't a criticism of those tools — they did the part they're good at. The hard part moved. What used to be "I can't get this idea to compile" is now "I can't get this idea to survive." That's the work that's left.
Five things AI build tools won't add for you
Concrete examples of the technical gap. Each is a small, well-known piece of production backend that gets left out of generated code, and each has a specific failure mode the first time it matters.
-
1
Token validation
Generated auth code often trusts whatever the cookie says. Without server-side validation, a forged token authenticates anyone as anyone.
When it matters: the first wrong charge against the wrong account.
-
2
Idempotency on payments
A network retry hits the "charge customer" endpoint twice. Without an idempotency key, the customer is billed twice. Stripe's docs cover this; generated code usually doesn't.
When it matters: the first chargeback dispute.
-
3
Rate limits
A bot finds the signup endpoint and creates 10,000 accounts overnight. Without rate limits, the bill is real — storage, verification emails, cleanup time.
When it matters: the first morning the storage graph spikes.
-
4
Observability
A request fails in production. Without logs, traces, or alerts, the first signal is a customer email — and the request is no longer reproducible.
When it matters: the first incident report with no data behind it.
-
5
Consent flows
Storing user emails for receipts without an explicit consent flow. For an EU-facing product, that's a GDPR fine larger than the runway raised to build the product.
When it matters: the first regulator letter.
None of these are difficult to do well. All of them are easy to skip when the goal is shipping a demo. The eight pillars below are what Sulis checks, every time, so they don't get skipped.
What "viable" actually means
Viable, here, isn't a feeling. It's a measurable bar that backend code has to clear before real customers can use it. Sulis runs eight checks, and won't say a piece of work is done until all eight pass:
You don't have to remember any of this. /sulis:code-health runs all of them at once and tells you, in plain English, what's solid and what isn't.
The lifecycle Sulis walks you through
Sulis doesn't just check the work — it walks you through producing it, in seven phases. Each phase exists because skipping it has a specific, repeatable cost:
-
1
Greet — what are you trying to build?
Capture your goal in plain English. Route correctly: build, fix, harden, audit.
-
2
Discover — what already exists?
Map the repo. Greenfield (empty) or brownfield (existing code)? Sulis builds on what's there, not over it.
Skipped: Sulis re-invents things you already had, and breaks compatibility with the rest of your stack.
-
3
Specify — what should it do?
A guided conversation produces a written requirements document. One question at a time. Functional and non-functional.
Skipped: you build the wrong thing perfectly, then rewrite. The expensive failure mode.
-
4
Design — how should it be built?
An engineering architect turns the spec into a technical blueprint + an ordered to-do list of independent, shippable tasks.
Skipped: ad-hoc decisions accumulate, then collapse under load when no one remembers why they were made.
-
5
Implement — actually build it.
Each task: write the failing test first, then minimum code to pass, then refactor, then commit. Atomic units of work.
Skipped: you ship code that worked once on your laptop, breaks on the first edge case in production.
-
6
Verify — does the built code match the design?
Every feature has tests. Every architectural decision was honoured. Nothing accidentally dropped.
Skipped: silent gaps between what you said and what you built. Discovered later, by customers.
-
7
Secure — anything that could harm users or the business?
A security review across the built product. CRITICAL findings get fixed before ship. CONCERN findings get queued.
Skipped: you find out from your first GDPR fine, or your first leaked-secret incident, or a customer's lawyer.
When you don't need the full cycle
Not every change is worth seven phases. A typo fix, a comment update, a tweaked config — those get a fast path. Sulis applies the trivial-change carve-out automatically when:
- The change is under 30 lines.
- No new artifacts are needed (no new spec, no new architectural decision).
- It's text, comments, or config — not behaviour.
Substantive work goes through the full cycle. Surgical fixes don't. Sulis decides which is which — and tells you what it picked.
What Sulis actually is
Read end to end, these eight pillars and seven phases describe one thing: the senior backend engineer many of us didn't get to apprentice with. Two decades of production pattern-recognition, codified into something that lives in the repo and runs alongside you while you build.
Not a code generator. Not a linter. Not a CI tool. A team of one — engineer and product manager — that holds the standards a mentor would have, and walks the work through them with you. The default state is calm. The artifacts are yours. The standards don't slip.