A Framework by Justin McKelvey

The Build Order

Vibe-code the prototype. Hire to ship the v1. Bring in a fractional CTO before you scale. Never reverse the order.

Sanity-check your Build Order See the decision matrix

Quick Answer

The Build Order is a 3-stage sequencing framework for non-technical founders building software. Prototype: vibe-code (Cursor, Lovable, Replit, Bolt). V1: hire a developer. Scale: bring in a fractional CTO. Each stage has one right approach and several expensive wrong ones. As of mid-2026, most rescue engagements I run come from founders who reversed the order — hired the CTO for the prototype, vibe-coded the v1, or skipped the CTO entirely and ended up rebuilding the architecture in year two.

Coined by Justin McKelvey, fractional CTO · Updated June 2026

What is the Build Order?

Real-time strategy games taught a generation of operators that order matters more than strength. The same units, deployed in the wrong order, lose. The Build Order applies the same logic to software products built by non-technical founders.

Each stage of building has a right resource — a tool, a person, a relationship — that matches the stage's actual constraints. Prototype needs speed and disposability. V1 needs quality and maintainability. Scale needs architectural judgment and risk management. Matching the resource to the stage is the whole framework.

The order can't be reversed. A fractional CTO on a prototype produces architecture for code that should have been thrown away. A vibe-coded v1 ships Vibe Debt to paying customers. A scale phase without a CTO produces decisions that take a rebuild to undo. Each violation is paid for later — in cash, in months, or in both. I get one of these rescue calls a week. They're the same call every time.

The Structure

What are the 3 stages of the Build Order?

Stage 1 · Hours to days

Prototype → Vibe-code

Goal: Prove the idea works. Show it to 5–20 potential users. Find out whether anyone cares before you spend money on real code.

Right approach: Vibe coding tools — Cursor, Lovable, Replit, Bolt, Claude Code, v0. Cheap, fast, disposable. The code doesn't have to be good; it has to demonstrate the concept.

Wrong approaches: Hiring a developer (too slow, too expensive for disposable work). Bringing in a fractional CTO (architecture for code you'll throw away). Hiring an agency (you'd pay $30K for a "real" prototype you don't need yet).

Stage 2 · Weeks to months

V1 → Hire a developer

Goal: Ship the version paying customers will actually use. Quality matters. Security matters. Someone other than you needs to be able to maintain it.

Right approach: Hire one strong developer — contractor or first hire. They can review, refactor, or replace what the prototype generated. They own the code through launch and the first few months of production. Real review, real tests, real deploy process.

Wrong approaches: Vibe-coding the v1 yourself (Vibe Debt enters production). Hiring an agency for an open-ended v1 (cost overruns, slow iteration). Bringing in a fractional CTO this early (you don't have anything to architect yet).

Stage 3 · Months to years

Scale → Fractional CTO

Goal: Make decisions that are expensive to reverse with the right inputs. Architecture. Hiring. Infrastructure. AI integration. Multi-tenancy. Compliance. Payment systems.

Right approach: Bring in a fractional CTO. They review what the v1 developer shipped, prioritize the next architectural decisions, mentor or hire additional engineers, and de-risk the bets you can't easily walk back. The engagement is usually 90 days or longer, with ongoing retainer once things are working.

Wrong approaches: Skipping the CTO and letting the v1 developer make architectural decisions alone (they may be excellent but they're optimizing for code, not for the business). Hiring a full-time CTO too early (you'll outgrow them or underutilize them). Trying to vibe-code the scaling features (Vibe Debt in your most important code).

The Decision Matrix

Which approach fits which stage?

Approach Prototype V1 Scale
Vibe-code (Cursor, Lovable, Bolt, etc.) ✓ Right ✗ Vibe Debt ✗ Don't
Hire a developer ~ Overkill ✓ Right ~ Necessary, not sufficient
Fractional CTO ✗ Premature ~ Too early ✓ Right
Agency ✗ Wasteful ~ If scope is fixed ✗ Inflexible

Every row has exactly one right answer and several costly wrong ones. The Build Order rule: read each column top-to-bottom and pick the row marked ✓. If you find yourself defending a ✗, that's the rationalization. The matrix is right; the rationalization is expensive.

What happens when founders reverse the Build Order?

The three most common reversals I see, and what each one costs:

  • → Hiring the CTO for the prototype: Founder is technical-anxious, brings in a fractional CTO before there's anything to architect. Engagement is spent on disposable work. Founder feels they got value; product has no real user signal. By v1, architecture is baked around an unvalidated thesis. Common cost: 3–6 months of rework.
  • → Vibe-coding the v1: Prototype worked, founder kept going. The v1 ships to production carrying every form of Vibe Debt. By month six, the code is unmaintainable. Common cost: a Crash Cart engagement ($25K–$50K) or a rewrite ($75K+).
  • → Skipping the fractional CTO at scale: V1 worked, team grew, but nobody is the architect. Decisions get made in PRs by whoever's free that day. Eighteen months later, the architecture is a junk drawer of consultant suggestions. Common cost: a year-two rebuild.

Frequently Asked Questions

Build Order FAQ

What is the Build Order?
The Build Order is a sequencing framework for non-technical founders building software products. The rule: vibe-code the prototype, hire a developer to ship the v1, bring in a fractional CTO before you scale. Never reverse the order. Each stage has a right approach and several wrong approaches; matching the approach to the stage saves months and tens of thousands of dollars. Coined by Justin McKelvey, fractional CTO, 2026.
When should I vibe-code vs hire a developer?
Vibe-code at the prototype stage — your goal is proving the idea works in a few hours, on a few users, with disposable code. Hire a developer at the v1 stage — when real users are paying or relying on the product, you need code that's maintainable, secure, and shippable by someone other than you. Vibe-coding the v1 creates Vibe Debt that costs more to fix than the developer would have cost upfront.
When do I need a fractional CTO?
Before you scale. The fractional CTO comes in when you've shipped a v1 that's working, you have a small dev team or contractor, and you're about to make architectural decisions that will be expensive to reverse — multi-tenancy, payment infrastructure, real-time features, AI integration, compliance. Bringing in the fractional CTO at this point saves the rebuild that founders without one always end up paying for in year two.
Can I skip the vibe-coding stage if I already have a developer?
Yes — but most founders shouldn't. Even with a developer on the team, prototyping with AI tools lets you test ideas without burning developer time on disposable code. The developer's expensive hours should go to v1, not to scaffolding throwaway prototypes. The exception: technical founders who can prototype faster in their own editor than they can with vibe coding tools. Most non-technical founders aren't in that category.
What if I'm already past v1 and shipped without a CTO?
You're not alone, and it's fixable. The signs you needed a CTO and didn't have one: every architectural decision feels expensive to walk back, your dev team disagrees about how to build the next big feature, you're paying for SaaS infrastructure that doesn't quite fit and nobody knows why. Bring in a fractional CTO for a 90-day engagement to audit, prioritize, and de-risk the next phase. Cheaper than the rebuild you'd otherwise be heading toward.
Do I need an agency at any stage of the Build Order?
Rarely. Agencies optimize for delivering a finished spec — they're great at v1 if you have a fixed scope and a clear timeline, but they're expensive and inflexible for prototypes and bad for the iterative work that comes after v1 ships. The Build Order's right answer is usually 'individual developer' or 'small in-house team plus fractional CTO,' not agency. Agencies make sense for very specific bounded projects, not for ongoing product work.
What happens when founders reverse the Build Order?
The most common reverse: hiring a fractional CTO for the prototype because the founder is technical-anxious. The CTO spends the engagement on work that should be disposable, the founder feels they got value, but the actual product hasn't been pressure-tested by real users. By the time they reach v1, the architecture has decisions baked in that don't match what users actually want. The second most common reverse: vibe-coding the v1 because v1 felt like a fancy prototype. Result: Vibe Debt that ships to production.
How does the Build Order relate to the other frameworks?
The Build Order sequences the building. Vibe Debt is the cost you accrue if you vibe-code past the prototype stage. The Crash Cart is what you roll when you've reversed the Build Order and need rescue. The Operator's Ladder is about how the founder uses AI personally; the Build Order is about how the product gets built. They're complementary — most rescue engagements involve all four frameworks simultaneously.

Related reading

Vibe Debt — the cost of breaking Build Order rule #2

What you accumulate when you vibe-code past the prototype stage.

The Crash Cart — what you roll when you've reversed the Build Order

The 5-step triage for codebases that shipped without the right resource at the right stage.

Fractional CTO services

What the fractional CTO stage looks like in practice — scope, cadence, pricing.

Not sure which stage you're in?

Thirty minutes. We'll walk through where you actually are (not where you think you are) and figure out the right next step — vibe-coding tools, your first dev hire, or a fractional CTO engagement.

Book a strategy call