Custom software is often priced as if the only question were the build cost. In practice, the bigger question is who carries the risk that the workflow changes, adoption takes time, or the first version reveals a better solution.
Four common models
| Model | Best when | Main trade-off |
|---|---|---|
| Fixed price | The scope and acceptance criteria are unusually clear | You pay before operational value is proven |
| Time and materials | The work is exploratory and the customer can manage a changing backlog | Budget certainty is lower |
| Retainer | A team needs continuous engineering capacity | The customer still funds the work before the outcome |
| No-upfront-development-fee subscription | One valuable workflow can be bounded and run as an ongoing product | Both parties need a clear go-live trigger and long-term commitment |
What a subscription model changes
This is the model we run. We fund the initial delivery of a defined first workflow, and your recurring subscription begins only when that workflow is live and accepted. It aligns both sides: we are pushed to keep scope disciplined and launch something useful quickly, and you are pushed to provide the access, feedback, and adoption that make it work.
It is not a way to hide the cost
A credible offer states what starts billing, what recurring service includes, what is outside the first workflow, and what happens if the relationship ends. If those facts are vague, the model creates distrust instead of removing risk.
Compare total operating cost
Look beyond the build invoice. Add subscription sprawl, the hours spent moving data between systems, error correction, delays, and the cost of software that is never updated. The best pricing structure is the one that makes the system economically useful throughout its life, not only inexpensive on day one.
Choose the model that matches the work
- Use fixed price when the output is known and final.
- Use time and materials when discovery is the work.
- Use a retainer when a team needs continuing capacity.
- Use a no-upfront-fee subscription when one operational workflow can prove value and needs a partner to run it over time.
Frequently asked questions
Is a subscription more expensive over time than a fixed-price project?
It can be, if you only count the build. A fixed-price project ends and the software starts ageing immediately: integrations drift, requirements change, and the next round is quoted again. Compare the total operating cost over several years, including the maintenance a project price does not include.
What should a credible no-upfront-fee offer state in writing?
Four things, before any development starts: what event begins billing, what the recurring fee covers, what falls outside the first workflow, and what happens to data, access, and support if the relationship ends. If any of those are vague, the model is hiding risk rather than carrying it.
When is a conventional fixed-price project the better choice?
When the output is genuinely known and final, and nobody needs to operate or evolve it afterwards: a one-off migration, a defined integration, a piece of work that ends. We will say so when that is the honest answer.
Is a subscription always cheaper than a fixed-price custom software project?
No. It changes when costs begin and how risk is shared. The right comparison includes operations, support, future changes, and the manual work the system removes.