Understand, Architect, Build, Deploy: How We Ship

Lab Twelve ships software in four phases: understand the build, architect the system, implement and test it properly, then deploy the product. Each phase has one job and one exit condition. You do not move to architecture until the scope is understood. You do not write code until the architecture is decided. You do not deploy until tests pass. That sequence is the whole method, and it is why a fixed price can hold from first conversation to production URL.

Most app projects skip a phase. They start coding before scope is understood, or deploy before anything is tested. The skipped phase does not disappear. It comes back later as a change order, a rewrite, or a 2am rollback. The four-phase method front-loads the cheap decisions so the expensive ones never surprise you.

Phase 1: Understand the build

Understanding is not a kickoff call where everyone nods. It is a structured extraction of what the software has to do, who uses it, and where the edges are. The deliverable is a written scope both sides can read.

This is where the AI scope chat does its work. You describe your app in plain language at /start. The chat asks follow-up questions until it can fill a structured spec: screens, auth model, integrations, data entities, notifications, and an explicit out-of-scope list. The model classifies; it does not invent. When the spec is complete enough to price, you get a fixed number from our published tiers.

What understanding catches that gut-feel estimates miss:

• Hidden auth. "Users log in" is one screen. "Admins, members, and guests with different permissions" is a different tier.
• Hidden state. A payment flow has webhooks, idempotency, and refund paths. A booking flow has conflicts and time zones. These are scope, not afterthoughts.
• Hidden admin. Founders forget the back office. If an operator needs to approve, export, or audit, that is screens and logic.

A build you understand can be priced. A build you do not understand can only be guessed at, and guesses are how fixed-price projects fail. The exit condition for this phase is a locked scope and a clarity score high enough to commit.

Phase 2: Architect the system

Once scope is understood, the question changes from "what" to "how." Architecture is the set of decisions that are expensive to reverse: the data model, the framework, the deployment target, the boundaries between services.

This is the phase agencies tend to outsource to whoever is free that week. At Lab Twelve it is the phase that earns the fee, because the right architecture for your build is rarely the trendiest one. We are polyglot on purpose. A content-heavy marketing app wants Next.js and a Postgres database. A data pipeline or an ML-backed feature often wants Python and FastAPI. A latency-critical service might want Go or Rust. Picking the right tool is an architecture decision, and I cover the tradeoffs in choosing the right stack.

Architecture decisions made in this phase:

• Data model first. Entities, relations, what cascades on delete. Migration bugs are born here when this is skipped.
• Framework and language per concern. The stack serves the build, not the other way around.
• Integration contracts. Stripe, email, storage, OAuth. Each one needs credentials, test mode, and error handling defined before code, not discovered during it.
• Deploy target. Where it runs, how it rolls back, what monitoring exists. Shipping is a design constraint, not a final step.

The exit condition is an architecture you could hand to any competent engineer and they would build the same shape. If the plan only lives in one person's head, it is not architecture. It is a bottleneck.

Architecture is the set of decisions you cannot cheaply undo. Spend an hour on it now or a sprint on it later.

Phase 3: Build and test it properly

Now code gets written, and this is where the AI-native pipeline earns its speed. Work splits into scoped missions, each with acceptance criteria and a verify gate. Agents draft against the spec. A senior operator holds the pass on taste, security, and edge cases.

"Properly" is the load-bearing word. Building properly means the test suite runs before anything is called done. It means the happy path and the failure paths both get walked: empty states, permission errors, expired sessions, the Safari quirk that breaks your date picker. Agents are good at the happy path. Humans walk the failures.

It also means the design constitution holds. Generated UI regresses to purple gradients and identical bento grids unless a written law and a lint gate say no. Building properly is partly refusing the median.

One active mission at a time, finished before the next starts. That is not slowness, it is throughput. I made the full case in why one active request ships faster. The exit condition for this phase is a feature set that passes its tests and matches the locked scope, with no half-plated screens.

Phase 4: Deploy the product

Deployment is the phase that separates a demo from a product. A build that runs on a laptop is not shipped. A build with no rollback plan is a liability waiting for Friday.

Deploy work in this phase:

• Environment parity. The thing you tested is the thing that ships. Env vars documented, secrets handled, no "works on my machine."
• Migrations and seed data. The database arrives in a known state, with a path forward and a path back.
• Monitoring and health checks. You find out something broke from a dashboard, not from a customer email.
• Handoff. Repo access, deploy credentials, env documentation. You own the code you paid for. There is no hostage clause where the app lives on the vendor's account forever.

The product lands in your dashboard with a live URL, test accounts, and the docs to run it. That is the definition of done. Not "the design is approved." Not "the code is on a branch." Live, tested, and yours.

Why four phases beat one big push

The phases are sequenced so that every expensive mistake is caught while it is still cheap. A scope misunderstanding caught in Phase 1 costs a clarifying question. The same misunderstanding caught in Phase 4 costs a rewrite. The discipline is front-loading the cheap decisions.

| Mistake caught in | Cost to fix | |-------------------|-------------| | Phase 1 (Understand) | A follow-up question | | Phase 2 (Architect) | A diagram revision | | Phase 3 (Build) | A reworked mission | | Phase 4 (Deploy) | A production incident | | After launch | A rewrite and a refund argument |

This is also why a fixed price can be honest. The number is derived from a scope that was understood and an architecture that was decided. There is no ambiguity left for the invoice to absorb later. Compare the math against agency and freelance ranges in the 2026 cost guide.

Where this method fits and where it does not

The four-phase method fits founders and teams with a defined problem: an MVP, an internal tool, a customer portal, a launch page. You know the job-to-be-done. You want it built right on a known budget.

It is a weaker fit for open-ended research with no definition of done, or compliance-heavy systems that need bespoke audit work before a UI is even ethical to ship. If your problem statement changes weekly, you are still in discovery, and discovery belongs in customer interviews, not in an active build. Read how to scope an MVP before you decide you are ready.

The honest take

The method is boring on purpose. Understand, architect, build, deploy. No phase is clever. The value is in refusing to skip one. Studios that look fast by jumping straight to code are borrowing time from their future selves at a brutal interest rate. Slow on Tuesday is fast by Friday.

If you have a build you can describe and a budget you want to hold, start with the first phase. Run your idea through the scope chat at /start, see the fixed price, and decide. Compare tiers on pricing. That is the front door to all four phases.