Notes for the person deciding whether to build something, and what to build first. Software development cost, timelines, the trade-offs nobody mentions until the invoice arrives. Nothing here is written for other developers: if a piece cannot help you decide something or ask a better question, it does not get published.
11 articles so far, in four groups: what an internal tool costs and how it is scoped, what changes when the product lives on a phone, how automated tests earn their keep, and what it takes to release and keep something alive. New ones arrive every few days — the schedule is set, so the queue does not depend on anybody remembering.
Nobody knows exactly what they want at the start, and pretending otherwise is what makes change expensive. The cost is set by when you find out, not by whether you change.
The final invoice is paid, the call happens, the access is transferred. Six months later nobody can deploy. Handover is a process, not a meeting, and it is the cheapest insurance in a project.
Most clients assume paying for a build means owning it. Usually true of the code, and often false of everything the code needs in order to run.
Everyone agrees on starting small and nobody agrees on how small. The rule that has worked for us: one journey, all the way through, including its bad days.
Studios rarely tell you not to build. Here is the test we use, and the three situations where the honest advice is to buy a boxed product instead.
You send one brief and get back three very different numbers. The spread is not greed — it is four different readings of the same sentences, and closing it is your job as much as theirs.
Manager, admin, operator. Three roles will get you through the first year, and then someone opens a second location. What replaces roles, and why it is painful to add later.
Offline-first is easy to promise and expensive to retrofit. What it actually requires, why a silent sync is worse than no sync, and how to tell whether your project genuinely needs it.
Off-the-shelf systems assume the thing you are making already exists as a specification. When every item is built for one person from measurements taken once, that assumption quietly breaks everything downstream.
Vague briefs come back as padded estimates, and the padding protects the studio, not you. Six things to write down before you ask anyone for a number.
Custom software is not automatically the right answer. Here is how the money actually breaks down, and the three situations where an off-the-shelf product will serve you better.
Reading rather than deciding? The case studies are the same arguments applied to two real products, with the prices, the timelines and a demo you can open on sample data.