How long does bespoke software take to build?
A focused system that does one job well takes weeks. A full platform with a customer app, payments and staff tools is typically a few months: a bespoke swim school system, for example, runs eight to sixteen weeks from first call to launch. What sets the clock is rarely the code. It is how quickly decisions get made, how many other systems it has to talk to, and who is writing the content.
The honest answer
Anyone who gives you a timeline before understanding the job is guessing. That said, the ranges are not mysterious, and a supplier who will not give you one at all is being unhelpful.
A single well-defined tool, something that replaces one spreadsheet and does one job, is usually a matter of weeks. A platform with a customer-facing app, payments, and tools your staff use daily is usually a few months. A bespoke swim school system, to take a concrete example we quote regularly, runs eight to sixteen weeks from the first call to launch.
The width of that range is not vagueness. It is the difference between a client who has already decided how their rules work and a client who discovers three new requirements during the build. Both are normal. Only one of them finishes in eight weeks.
What actually sets the clock
Development time is the part people imagine, and it is rarely the part that slips. These are the things that genuinely move a launch date.
| Factor | Makes it faster | Makes it slower |
|---|---|---|
| Decisions | One person can approve | Every question goes to a committee |
| Rules | Written down before the build starts | Discovered while it is being built |
| Integrations | One payment provider, nothing else | Accounting, CRM and a legacy database |
| Content | Ready, or we write it | Waiting on copy and photographs |
| Data migration | Clean export from one system | Three systems that disagree with each other |
| Testing | Named person who tries it weekly | Everyone looks at it in the final week |
| Scope | Fixed, with a phase two on paper | Growing quietly throughout |
Three things a client can do
Most of the levers that shorten a build sit on your side of the table, not ours.
Name one decider. Not a committee. The single most reliable predictor of a build finishing on time is that one person can answer a question the same day. Committees are how a two-week task becomes a six-week task without anyone doing anything wrong.
Write your awkward rule down before we start. Every business has one: the credit policy, the pricing exception, the customer who is billed differently. If you can state it in a sentence, it can be built. If you cannot, it currently lives in somebody\'s head, and it will surface in week nine.
Try it weekly. Software that is reviewed every week for ten weeks arrives finished. Software that is reviewed once, at the end, arrives at the start of a second project. Fifteen minutes a week from the person who will actually use it is worth more than a long specification.
Phasing beats waiting
If a date matters more than a feature list, say so at the start, because it changes how the work is ordered rather than how much there is.
The approach that works is to launch the part that removes the most admin first and add the rest afterwards. For a booking business that usually means bookings and payments live first, with reporting, extra staff tools and the nicer parts of the customer app following in the weeks after. You get the benefit sooner, and the things that turn out to matter most are built with real usage behind them rather than a guess.
The alternative, holding everything back until it is all ready, means the business carries the old admin burden for the entire build and every decision is made in the dark.
What launch actually means
Ask what happens the day after. A launch date is only meaningful if it comes with an answer about support, because the useful questions all arrive once real people are using the thing.
Our own builds are priced in writing before work starts, and support continues after launch rather than ending at it. Whoever you use, get the same two things in writing: what the price is, and who fixes it in month three. A timeline without those attached is a marketing number.
Common questions
A focused tool that does one job is usually a matter of weeks. A full platform with a customer app, payments and staff tools is typically a few months. A bespoke swim school system, as a concrete example, runs eight to sixteen weeks from first call to launch. The range depends mostly on how many decisions are already made before the build starts.
Usually because they are estimating different things. One price may cover design, build, migration, testing and support, and another only the build. Ask what happens to the timeline if a requirement changes in week six, and ask who fixes a problem in month three. The answers tell you more about the estimate than the number does.
Usually, by phasing rather than by rushing. Launch the part that removes the most admin first, typically bookings and payments, then add reporting and the remaining tools over the following weeks. You get the benefit earlier, and the later features are built with real usage behind them instead of a guess.
Decisions, not development. Waiting on an approval, discovering a business rule halfway through, or waiting on copy and photographs. The next most common is testing left until the end: software reviewed weekly arrives finished, software reviewed once at the end arrives at the start of a second project.
We give a written, fixed price after a short discovery call, agreed before work starts. Dates are given as a range at that point and firm up once scope is agreed, because an honest range beats a precise number nobody believes. If a specific date is the constraint, say so early and the work gets ordered around it.
Where to go next
If you want a straight answer about your own situation, tell us what you are trying to do and we will say what we would do, including when the answer is that you do not need us. Start a conversation.