Fixed-scope vs embedded development: which model is right for a startup?

Founders usually ask us "how much will this cost" before they've decided which of these two models they actually want — and the model changes the answer more than the feature list does.

Fixed-scope: you know what "done" looks like

You come in with a defined product — a spec, a set of screens, a clear v1. We quote a price and a timeline against that scope, build it, and hand over something working with fixed milestones along the way.

Good fit when:

• You've validated the idea and know what v1 needs to do.
• You want cost and timeline certainty before you commit.
• The scope is genuinely boundable — a defined app, a defined set of workflows.

The tradeoff: changing the scope mid-build means re-scoping, not a quiet feature creep. That's a feature, not a bug — it's what makes the price and date mean something. But it's the wrong model if you expect to be discovering the product as you go.

Embedded: we work inside your team, ongoing

Instead of a fixed deliverable, you get senior engineering capacity for a period of time — sprint by sprint, working from your backlog, in your repo, alongside whatever team you already have (or as the whole team, if you don't have one yet).

Good fit when:

• The product is still being discovered — requirements will change as you learn from users.
• You need ongoing capacity, not a single deliverable.
• You want the option to redirect priorities week to week without renegotiating a contract.

The tradeoff: less cost predictability than fixed-scope, because the work isn't bounded in advance. You're paying for capacity and judgment, not a fixed outcome.

The honest way to decide

Ask yourself one question: do I know what "done" means for v1, or am I still figuring that out?

• If you can write the v1 spec today, even roughly — fixed-scope will give you a real number and a real date.
• If the honest answer is "we'll know more once real users touch it" — embedded gets you moving without forcing a premature commitment to a scope that will change anyway.

Some engagements start fixed-scope for a v1, then move to embedded once the product is live and the priority is fast iteration instead of a defined build. That's normal, not a failure of planning.

Either way, you own the code, the repos, and the accounts from day one — that doesn't change based on the model. If you're not sure which one fits, that's exactly what a 15-minute build-readiness call is for.