One-time build or subscription team? How to choose

Every company buying software development is choosing between two shapes, whether the vendor names them or not: a one-time build — fixed scope, fixed quote, handover at the end — or a standing team that stays month after month. Vendors usually push whichever one they sell. We sell both, which makes this the rare guide with no thumb on the scale.

What a one-time build is actually for

A one-time build works when the thing has edges. A booking system for a clinic chain. A customer portal to replace the spreadsheet-and-email routine. An MVP to put in front of investors. You can describe done, and done stays put long enough to build to it.

Its virtues are real: you know the total cost before you commit, you own everything at the end, and there’s no ongoing relationship to manage. When it’s finished, it’s finished.

Its risk is equally real, and vendors who sell only builds won’t lead with it: the fixed scope is a bet that you specified the right thing. A build shop prices the spec, builds the spec, and hands over the spec. If the spec was wrong — and on first versions it usually is somewhere — you own a finished, polished mistake. This is why the scoping conversation matters more than the quote, and why a vendor who starts building before interrogating your spec is quoting you for risk you’re carrying alone.

What a subscription team is actually for

A standing team works when the software is alive. Real users generating real feedback, a roadmap that changes as you learn, integrations that break when third parties change things, and the compounding list of small improvements that separates products people tolerate from products people recommend.

The virtue is continuity. The same people who built it are the people improving it — no handover, no “getting up to speed,” no re-explaining the domain to a new contractor every six months. Velocity compounds when context does.

The risk: a monthly fee with vague deliverables can drift into a retainer that produces motion instead of outcomes. The defence is structural — a team that includes product management, reporting in outcomes rather than hours, on terms you can leave with notice. If a subscription locks you in for a year or reports in “hours consumed,” that’s a staffing contract wearing a subscription costume.

The decision rule

Ask one question: when this ships, is it done?

• Internal tool automating a stable process → probably done → build
• Compliance-driven system with fixed requirements → done → build
• MVP to test a market → done for now → build, then decide
• Customer-facing product you intend to grow → never done → team
• Anything with paying users and a competitor → never done → team

The honest wrinkle: plenty of one-time builds turn out to be the first chapter of a living product. That’s not a failure — it’s the cheapest way to find out. The mistake is signing up for a standing team before anything exists, or clinging to project-by-project quotes after the product plainly has a pulse. Sequence them: build first, subscribe when the software earns it.

The question underneath both

Neither shape saves you if the thing itself is wrong. Building got cheap — a competent team can now produce almost anything you specify, on time, to budget. Which moves the expensive failure upstream: the thing you built well that nobody needed.

So before pricing either shape, pressure-test the direction. What number does this move? What did you decide not to build, and can anyone name it? If those questions have crisp answers, choose your shape with the rule above. If they don’t, the cheapest thing you can buy is two weeks of direction work — it’s the difference between quoting a build and quoting a guess.

At Formula Station the sequence is explicit: we work out what’s worth building, quote it as a one-time build or staff it as a subscription team, and the same people carry the decision through to the release. Whichever shape you buy, buy the direction first.