Product development is not project delivery
Most of the disappointment I see in software budgets comes from one unexamined assumption: that the thing being bought is a project. A project has a scope, a delivery date, and an end. When it is delivered, the transaction is complete.
Product development does not work that way, and the difference is not a matter of degree. A project ends when the scope is delivered. A product ends when nobody uses it any more. Everything downstream of that sentence — how you architect, how you budget, who you hire — changes depending on which one you are actually doing.
If you are trying to work out which of the two you have, that is the question custom software development should answer before anyone writes code, because getting it wrong is expensive in a way that is hard to see for about eight months.
The tell is what happens after launch
Ask what the plan is for month four. If the answer describes a warranty period, a bug-fix window, and a handover document, that is a project. If the answer describes a roadmap, a feedback loop, and someone whose job is deciding what happens next, that is a product.
Both are legitimate. A payroll integration that runs unchanged for six years is a project, and treating it as a product wastes money on flexibility nobody will use. A two-sided marketplace is a product, and treating it as a project produces something that works on the launch date and calcifies immediately afterwards.
The failure mode is asymmetric, which is why this matters. An over-engineered project is a bounded waste — you paid for extensibility you did not need. An under-engineered product is unbounded: every change costs more than the last one, until the sensible move is a rewrite.
Four decisions that get made differently
Data model. A project can model the process as it exists today. A product has to model the parts that will not change and leave the rest soft. That is harder, and it is the decision most likely to be quietly deferred.
Deployment. A project can ship on a date. A product needs to ship on a Tuesday afternoon without ceremony, which means the deployment path itself is a deliverable rather than an afterthought.
Observability. A project needs to prove it works at handover. A product needs to answer “is it still working” at 2am eighteen months later, from someone who did not build it.
Ownership. A project can be handed over. A product needs a person who decides what is worth building next. If that person does not exist, you have a project with a roadmap-shaped hole in it.
What “operated” is doing in the phrase
This studio describes its work as built, shipped, and operated. The third word is the one carrying weight, and it is also the one that constrains what I can take on.
Operating something means being on the hook when it misbehaves. That is a real commitment with a real limit: I am one person. I can hold operational responsibility for a small number of systems at a time, and I cannot hold it for five parallel workstreams. If you need five parallel workstreams, an agency is the right answer and I will tell you so on the call.
The visible version of that commitment is on the case studies page — two native apps over one deterministic shared core, where the shared code is strictly the engine and every pixel is platform-native. That architecture is more work up front than a cross-platform UI framework. It was chosen because the product was expected to outlive the framework, and it is the kind of decision that only makes sense under product assumptions.
Where the budget actually goes
The common shape of a product budget surprises people who have only bought projects. Roughly speaking, the first release is not the expensive part.
The expensive part is the second year: the accumulated cost of decisions that were correct at the time and are not any more. Technical debt is not carelessness — it is the interest on a loan you took deliberately in order to ship. A product budget that does not include a line for repaying it is not a budget, it is a forecast of a rewrite.
I would rather say this before an engagement than during one. A quote that covers only the first release is easy to win with and dishonest to deliver against.
How to decide, in one pass
Write down the answer to three questions before you brief anyone.
- Who decides what gets built in month six, by name?
- What is the first thing you expect to change after real users arrive?
- If this system were frozen exactly as delivered, how long until it stops being useful?
If question one has no name in it, you are buying a project whether or not you meant to. If question three is measured in years, a project is genuinely the cheaper and better answer — build the narrow thing, build it well, and stop.
Related reading: application development covers what the delivery work actually involves. The development process I run describes the sequence and where it has failed. And enterprise software covers the work that gets added when the buyer and the user are different people — which is a product assumption in disguise, because it means the roadmap answers to someone who never opens the thing.
What this article does not tell you
It does not tell you whether your specific idea should be a product. That depends on things I cannot see from here: your funding shape, your competition, and whether anyone has confirmed that the problem is real. Naming a limit is cheaper than defending an overclaim, and the limit here is that this is a framework for a conversation, not a substitute for one.