How we scope a custom software project

Most custom software projects that go wrong were scoped badly long before a line of code was written. So when someone asks us to build a desktop app, a mobile app or a SaaS product, we spend the first part of the work on scope. This post explains how we scope a custom software project, step by step, including the parts that are uncomfortable to talk about, like money and what happens after launch.

None of this is secret or original. It is roughly what careful studios do. We write it down because people planning their first project often have no idea what to expect, and because it is easier to have a good conversation when both sides know the shape of it. If you already have something in mind, our custom development page is where to start.

Discovery: the questions we ask first

The first conversation is mostly questions. We try not to talk about technology at all in the first half hour. The questions that tell us the most are these:

Who uses it, and what are they doing right before they open it? An app used in a warehouse on a shared tablet is a different product from one used at a desk with two monitors, even if the features read the same on paper.
What happens today without it? Usually there is a spreadsheet, a paper form or a patchwork of other tools. That existing process is the real competitor, and it tells us what "better" has to mean.
What would make the first version a success in three months? We want a number or an observable change. "Staff stop emailing the spreadsheet around" is a good answer. "Users love it" is not one yet.
What must it connect to? Payment providers, an existing database, a login system, a piece of hardware. Integrations cause more estimate misses than any screen we will ever draw.
What is fixed? A launch date tied to an event, a budget ceiling, a platform the client's customers already use. Fixed things shape everything else, so we want them out in the open early.

For small projects this takes a call and a follow-up document. For anything larger we suggest a short, paid discovery phase, typically one to two weeks. The output is a written brief, rough wireframes of the main screens, a list of integrations with their unknowns, and an estimate. The client owns all of it and can take it to another studio if they want. That keeps the incentives honest on both sides.

Must, should, could

After discovery there is always a long list of features. Every one of them sounds reasonable. The next step is sorting them into three groups, a simple version of the method often called MoSCoW:

Must. Without this, the first version does not do its job. If the app is for booking rooms, booking a room is a must.
Should. Important, and likely to come soon, but the first version still works without it. Recurring bookings, perhaps.
Could. Nice ideas that go on a later list. Calendar sync with three different providers, a dark mode, an admin dashboard with charts.

The rule we try to hold is that the must list stays short enough that a person can read it aloud in under a minute. When it grows longer, something on it is really a should. The discussion is often harder than it sounds, because every item has someone who cares about it. We find it helps to ask, for each feature, what a user would do in the first month if it were missing. If the answer is "use a workaround that takes two minutes", it is probably not a must.

A thin first version

We try to get a real, working first version into real hands as early as possible. Thin, in our sense, does not mean a clickable prototype or a demo with fake data. It means a narrow product that does the must list properly: it saves data, it handles errors, it signs people in securely, and it can be updated. It just does not do much else yet.

The reason is simple. Whatever we all believe during discovery, the first two weeks of real use will change some of it. A feature everyone was sure about turns out to be rarely used, and a small annoyance nobody mentioned turns out to matter every day. A thin version lets that learning happen while the budget still has room to respond to it.

For a typical small project, we aim to have the first version in use somewhere between six and twelve weeks after discovery. Larger products take longer, but we still look for a first slice that can ship on its own.

Choosing the platform

We try to let the platform follow the users, not the other way round. A few rules of thumb we use:

If people will use it at a desk, all day, and it needs files, local hardware or offline work, a desktop app is often the better fit. It can also be the cheaper one to run, with no servers to pay for.
If people will use it on the move, with the camera, location or notifications, it wants to be a mobile app. We then decide between native iOS and Android or a shared codebase, based mostly on how much the app depends on platform features.
If many people need to share the same data from many places, it is a web product, and often a SaaS with its own hosting and accounts.

Plenty of projects need two of these, usually a web back end with a mobile or desktop front end. When that happens we still try to launch one front end first and add the second when the first is stable.

Estimates as ranges, and how we price

We give estimates as ranges, such as "eight to eleven weeks" or a cost band, never a single number. A single number suggests a precision that nobody has at the start of a project. The range narrows as the work goes on and unknowns get resolved, and we update it openly when it does.

The width of the range tells you something too. If one part of the estimate is much wider than the rest, it usually points at an integration or a requirement that nobody fully understands yet. We would rather resolve that with a short spike (a few days of focused, throwaway exploration) than guess.

For pricing there are two common models, and both are reasonable:

Fixed price works well for small, clearly defined projects. The client knows the cost up front. The trade-off is that changes need a formal change request, and the studio adds a margin to cover risk, so you pay for certainty.
Time and materials works better when scope will move, which is most of the time with new products. You pay for the time spent, usually in weekly or fortnightly blocks, and can reprioritise freely. The trade-off is that the total is not fixed, so it needs regular, honest reporting.

We often combine them: a fixed price for discovery, then time and materials with an agreed budget ceiling for the build, reviewed every couple of weeks.

Handover and maintenance

The last part of scope is what happens after release, and it is the part most often left out. Software is not finished when it ships. Operating systems update every year, app stores change their requirements (Google Play, for example, regularly raises the minimum target API level for app updates), certificates expire and dependencies need security fixes.

Before we start, we agree on a few things in writing:

The client owns the code, the repository, the domain and the store accounts from day one. We work inside their accounts, not ours.
The handover includes documentation that another developer could follow: how to build, how to deploy, where the secrets live and who has access.
There is a maintenance plan, even if it is small. Some clients want a monthly retainer for updates and fixes. Others prefer to call us when needed. Either is fine, as long as it is decided before the first operating system update breaks something.

If you are planning something and want a second opinion on scope, send us a short description through the custom development form. The most useful thing to include is the answer to our first question: who will use it, and what they are doing right before they open it.