What the first version should contain, and what it must not
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.
Notes for the person deciding whether to build something, and what to build first. Budgets, 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.
26 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.
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.
Nobody has the budget to cover every screen, and covering every screen would not help anyway. A short, opinionated method for choosing the first fifteen journeys.
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.
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.
Almost every team we meet has tests. Half of them are failing, the pipeline is set to continue anyway, and everyone has quietly agreed not to mention it. The cause is almost never laziness.
Sending clients a folder link works until the day someone asks who saw what, or the wrong version gets signed. Here is where the line actually is.
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.
Data migration is the part of a CRM project that is quoted as a line item and turns out to be a quarter of the work. Here is what makes it expensive and what you can decide in advance to make it cheaper.
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.
This is a business decision that quietly rewrites your software. Pick it before the build, because each answer needs a different thing to exist on day one.
Access rules are the part of a client portal that breaks silently and looks normal from the inside. Here is what to specify before anyone writes code.
Quotes for test automation range from four thousand to forty-five, for work that sounds identical on the page. Here is what sits behind the numbers and how to tell which one you are being sold.
The number depends on four things, and none of them is the number of screens. Here they are, in the order they move the price.
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.
Disintermediation is not a bug you can patch. It is a pricing problem wearing a technical costume, and the platforms that survive it solve it with what they offer, not with what they block.
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.
It is not the number of screens. It is the number of systems the portal has to read from, and whether any of them can be trusted to answer on time.
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.
Most companies should buy the box, and we say so before taking money. Here is the specific test that tells you which side of the line you are on, and what it costs to be wrong in each direction.
Holding a buyer’s money until the work is accepted is the feature that makes a marketplace a marketplace. It is also what separates an eight-week build from a twelve-week one. Here is what you are buying.
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.
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.