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.
12 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.
The build is quoted, budgeted and approved. The upkeep is nobody’s line item until the app stops working, which on mobile it eventually will, without anyone touching it.
Review usually takes a day or two, unless something on this list is missing — in which case it takes a week, twice. None of the common causes are difficult; they are simply forgotten.
Development happens on new phones. Your customers are on four-year-old Androids with the storage full and battery saver on, and that is where apps actually break.
Most of what breaks in an app happens outside your app: the permission dialog, the payment sheet, the push notification, the process the operating system killed while nobody was looking.
Everyone assumes both. Sometimes both cost almost nothing extra; sometimes one is a month of work you could have spent learning whether anyone wants the app at all.
One codebase or two is the first real decision in a mobile project and the one most often made for the wrong reasons. Four questions that settle it.
The honest answer is a range, and the range is wide for a reason. Here is what sits inside it, and the four things that change the figure more than anything on the feature list.
The demo always works. What fails in month two is the paid order whose seller was banned, the deposit that half-arrived, and the dispute about a file nobody kept. A list worth reading before you sign anything.
Generation costs money every time someone taps the button. Here is the metering, refund and abuse question to settle before you ship an AI feature, and what it looks like when it is done properly.
Before the catalogue, before the app, one question decides your build, your legal shape and your support load: at what moment does the buyer stop owning the money and the seller start.
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.
A two-sided marketplace is three products, not one. Here is what genuinely drives the timeline, and which decisions add months without adding value for your first users.
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.