What to work out before you build custom software

Not "we need an app". A sentence like "chasing job sheets back from site costs us two admin days a week", or "quotes take four days to go out and we lose work to whoever answers first". The shape to aim for is a problem, a frequency and a cost.

If you cannot put a number on it yet, that is worth knowing, because it is the first thing to go and find out. The number does two jobs. It tells you what the software is allowed to cost, and after launch it is the measure that tells you whether the project worked. A project with no number attached can never fail, which sounds comfortable and is actually the problem.

A tool for your own staff and a product for your customers are different projects wearing the same description. An internal tool can be plain, needs staff logins, and justifies itself with payback arithmetic: hours saved, multiplied by what those hours cost. A customer-facing product needs public sign-up, password resets and account recovery, carries far more design weight, and cannot promise revenue in advance, which changes how you should judge the spend.

The difference is real money. In our published pricing, staff logins are two to four days of work while public accounts are four to eight, and that pattern repeats through every part of the build. You can serve both audiences eventually. Decide which one earns its keep first.

The process you want software for is already running somewhere: in a spreadsheet, a wall planner, a WhatsApp group, and the memory of whoever has done the job longest. That battered ten-year-old spreadsheet is the best requirements document you will ever own. Its odd columns are rules nobody wrote down. The notes field is a museum of edge cases, each one a real incident. The workarounds your team performs without thinking are requirements no brief would ever have captured.

Bring all of it to the first conversation, and do not tidy it first. The mess is the information. A developer can get more truth out of an hour with your spreadsheet and the person who runs it than out of twenty pages of requirements written specially for the occasion.

Integrations move quotes more than screens do. The accounts package, the till, the courier, the supplier price feeds, the calendar: name every system the software must talk to, and find out for each one whether it has an API or an export, because a system with no way in has to be worked around, and workarounds are where budgets go.

At our published rates a named integration with something mainstream like Xero, Sage or Stripe runs one and a half to three days. Something obscure or badly documented runs three to six. The sentence "it just needs to pull the orders across" has started more difficult conversations than any other in this trade, so the earlier the list exists, the more accurate every quote you receive becomes.

If your process matches how the rest of your industry works, somebody already sells software for it, at a subscription price a custom build cannot compete with. Custom software earns its cost in two situations: when the process is genuinely yours, the thing that makes you better than your competitors, or when the job is gluing together systems that nothing off the shelf will connect.

We tell people to buy something off the shelf on discovery calls regularly, and any developer worth hiring will do the same, because a build that should have been a subscription becomes a millstone for both sides. We have written a fuller comparison in tailored vs off-the-shelf if you are weighing it up.

Whatever the full vision is, the first release should be small enough to be delivered in ten to fourteen weeks and put in front of the people who will actually use it. One process covered end to end beats five processes half covered, every time. Real users finding the gaps in a working release teach you more in a fortnight than another quarter of planning would.

There is a harder-nosed reason too. A project priced in slices is a project you can stop, and the ability to stop is worth more than any discount. If a first release fails, you have spent a slice and learned something. If a two-year everything-project fails, it usually fails in month twenty.

Every quote you will ever receive is a day rate multiplied by a number of days, and the variance between quotes lives almost entirely in those two numbers. We have published the full arithmetic we quote from, including the day bands behind each piece of functionality, and our cost calculator will turn your own answers into a costed estimate in about three minutes without asking for an email address.

Armed with that, ask every bidder the same three questions: how many people, at what level, for how many days. A cheap blended rate covering two juniors and a project manager can produce a larger invoice than a higher rate covering one senior engineer who has built the thing before. And check whether the figure you are holding includes VAT before it goes anywhere near a board.

You do not need a specification document, wireframes, or an opinion about technology. Producing those is the developer's job, and doing it together during discovery is precisely what the early stage of a project is for. Arriving with a fixed solution can even work against you, because you will be quoted for the solution you asked for rather than the problem you have.

Bring the problem, the number, the spreadsheet and the list of systems. That is a better starting position than most projects ever get.