Short answer: An MVP Build, the smallest version that does the main job, typically takes 6 to 12 weeks. A Technical Audit typically takes 1 to 2 weeks. A full custom platform usually takes longer, depending on scope, integrations and how quickly decisions get made. Exact dates go in the written quote, next to the scope.
"How long will it take?" is the second question everyone asks about custom software, right after "how much?". It's a fair question, and the honest answer is that it depends on decisions you haven't made yet. That sounds like a dodge. It isn't. Most of the time on a software project goes into things that nobody can see from the outside, and most of the delays come from a handful of predictable places.
This article covers what decides the timeline, where projects usually lose time, and what you can do to get something useful working sooner.
What decides how long custom software takes?
How many kinds of user there are
A tool used by one team doing one job is one thing. Add customers who log in, managers who approve, an admin who sees everything and a partner who sees some of it, and each of those people needs their own screens, permissions and rules. In our view, the number of user types is a better predictor of effort than the number of features.
How well the work is understood
If your team can explain exactly how an order moves from enquiry to invoice, building it is mostly a matter of typing. If the process lives in one person's head, or works differently depending on who's in that week, someone has to figure it out first. That figuring out is real work, and it's better done before the code than after.
What it has to connect to
Your accounting software, your CRM, a payment provider, a supplier's system, a spreadsheet that refuses to die. Each connection depends on how good the other side's documentation is, whether there's a test environment, and how quickly someone there answers questions. Integrations are where estimates most often go wrong, because the unknowns live in someone else's system.
Moving data over
Your old data is never as clean as you hope. Duplicate customers, dates in three formats, a field that means one thing before 2022 and another after. Moving it into a new system means cleaning it, mapping it and checking it. Teams often forget to plan for this until the week before launch.
Rules you have to follow
Personal data under GDPR, payment handling, industry-specific record-keeping, accessibility (usually measured against WCAG 2.2). None of these are optional, and each adds design, build and testing work. Better to know about them on day one than to discover them in a review.
How quickly decisions get made
This is the one nobody puts in the estimate. A question about how refunds should work can be answered in ten minutes or in three weeks, depending on who has to agree. In our view, waiting for decisions often takes more calendar time than building.
Where projects usually lose time
- Scope that grows quietly. Each extra feature seems small. Together they double the job.
- Building everything before anyone uses anything. Then real users arrive and half of it needs changing.
- Designing while building. If screens are still being argued about while developers work on them, someone ends up doing the work twice.
- Late surprises from other systems. An API that doesn't do what its documentation says, found in the last month.
- Testing squeezed at the end. When the deadline is fixed and everything else ran late, testing is what gets cut. That's how bugs reach customers.
How can you build a custom platform faster?
Build the smallest version that does the main job
This is what people mean by an MVP, a minimum viable product, though the term gets stretched. The idea is simple: find the one job the platform must do well, build that properly, and put it in front of real users. Everything else waits.
For an internal tool, that might be "staff can log a job, assign it and mark it done". Reports, notifications, a mobile view and the integration with accounting can come in the second round. The first version should be small, but it shouldn't be sloppy. Small and solid beats big and shaky. That is the scope of our MVP build package.
Write down what's out
A list of what you're building is useful. A list of what you're deliberately not building yet is more useful, because that's where the arguments happen. When someone asks for a new feature halfway through, the list makes the conversation easy: it's a good idea, it goes on the list for the next version.
Use off-the-shelf parts where they fit
Nobody needs a custom login system, a custom payment processor or a custom email sender. Proven services exist for those, and using them can save weeks. Save the custom work for the parts that are specific to your business, because those are the parts that are worth paying for.
Get one person who can decide
Give the project one person on your side who can answer questions and make calls within a day or two. They don't need to know anything about software. They need to know the business and have the authority to say yes or no. This alone can save more time than any technical choice.
Design before you build
Clickable screens let you test the idea with real users before anyone writes code. Changing a layout costs an afternoon. Changing a built feature can cost a week. Doing the design first feels slower and is almost always faster.
Ship in pieces
Rather than one big launch at the end, aim for working pieces every couple of weeks that your team can click through. You catch misunderstandings early, and you can start using parts of the system before it's finished.
Deal with the data early
Export a sample of your old data in the first week and let the developers look at it. Most of the ugly surprises show up immediately, while there's still time to plan for them.
What a realistic plan looks like
A good plan for a custom platform usually has a short discovery phase where the work is mapped and the scope is agreed, a design phase where screens are tested, then building in stages with something you can try at the end of each one. Launch comes when the core job works, not when every idea is done. After that, the next version is shaped by what real users asked for, rather than what everyone guessed at the start.
Anyone who gives you a firm date before understanding how your work actually happens is guessing. A better answer is a date for the first version, with the scope written next to it, and an honest list of the things that could move it.
Sources
- Regulation (EU) 2016/679 (GDPR) on EUR-Lex, the personal data rules mentioned above.
- W3C, Web Content Accessibility Guidelines (WCAG) 2.2, the usual reference for accessibility requirements.
If you have a process that's outgrown its spreadsheets, our custom software page explains how we approach it. Or book a free call and tell us what the software needs to do. We'll tell you what we'd build first.