How long does custom software take to build?
Custom business software usually takes 5 to 10 weeks to put a first working phase into production and 10 to 24 weeks for a complete operations system, going by the typical timelines MyFloww publishes for those scopes; a larger system such as a full hospital ERP takes longer. Scope, integrations, data migration and the speed of decisions move the figure more than the coding does.
- Written by
- Neil Sharma, Lead Architect and CEO
- Published
- Updated
- Reading time
- 7 min read
Every honest answer to this question starts with "it depends", and many stop there. This one gives the typical timelines MyFloww publishes, explains what each phase is for, and spends most of its length on what makes projects slow — which is rarely the code.
Typical timelines, by kind of project
These are the ranges MyFloww publishes on its own city and industry pages for scopes businesses commonly ask for. They are typical, not promises: a project's own timeline comes with its scope, once the requirement is understood.
| Kind of project | Typical timeline | What usually sets the pace |
|---|---|---|
| A small business website of up to eight pages (the Launch plan) | About 2–3 weeks | Your content: photographs, services, timings, prices. |
| A WhatsApp Business API set-up with templates and a human takeover | 2–5 weeks | Meta's business verification. |
| An enquiry agent answering from the business's own content | 3–6 weeks | How complete and current that content is. |
| A fixed-scope MVP: one kind of user, one job | Weeks rather than months; the exact figure comes with the scope | How firmly the scope is held once the build starts. |
| The first phase of an operations system: one workflow, end to end, in production | 5–9 weeks; 6–10 on a production line or traceability process | Decisions on how the workflow should run, and the opening data. |
| A complete order, dispatch and receivables system for a trading or distribution business | 10–20 weeks | The integrations, especially the handover to accounts. |
| A larger operations system: several GST registrations, export documentation or production traceability | 12–22 weeks; 12–24 for laboratory traceability with an audit trail | Each registration, document type or audit requirement adds rules. |
| A hospital's first phase: registration, OPD, billing and pharmacy | 12–20 weeks | Departments agreeing on one record. |
| A full hospital ERP: admissions and beds, the insurance desk, lab and imaging interfaces, HR and payroll | 24–40 weeks | The interfaces to existing equipment and systems. |
First phases are measured in weeks and complete systems in months, which is the case for phasing: the business is using something real long before the whole system exists. And the longest ranges belong to the systems with the most interfaces and the most people to agree, not the most screens.
The phases, and what each one is for
- Understanding and scoping
- Who uses the system, what they do all day, what breaks today, and what done looks like — written down, with what is in and what is out. Projects that go wrong almost always went wrong here.
- A first working version
- The smallest version that does real work: not a prototype, and not the whole system. MyFloww builds it on a live preview from the first week, so you see the software rather than a report about it.
- Testing with real users
- The people who will use it, doing real work on their own phones and counters. The cases nobody mentioned during scoping turn up here.
- Data migration
- Customer and supplier lists, opening stock, open balances and history brought across from spreadsheets or the old system. How clean the data is decides how long this takes, and it is the phase most often discovered late.
- Training
- Short, and by role. The counter needs three screens; the owner needs the reports.
- Launch
- Live, with the opening data in place and someone on hand for the first days of real use.
- Phased releases
- The next module or workflow, scoped from how the first one is actually used rather than from the original wish list.
- The changes after first contact
- Real use always finds situations nobody predicted. Plan time and budget for them from the start; they are a normal part of the work, not a sign it went wrong.
What makes projects slow
When a project overruns, the code is seldom the reason. The usual causes sit around it.
- Decisions that wait
- A question that takes a week to answer costs a week. Two people who must both agree, or approvals that need a meeting, multiply that.
- Content and data that are not ready
- Price lists, item lists, opening stock, photographs. Software can be finished and still unable to go live because the data it runs on has not arrived.
- Third-party approvals
- The WhatsApp Business API depends on Meta verifying your business, a payment gateway completes its own checks on you before live payments are switched on, and a logistics partner or government portal has to issue credentials. These run on other organisations' calendars, and no builder can hurry them.
- Integrations
- Each one is somebody else's system, documentation and downtime, and they are where estimates are most often wrong.
- Migration discovered late
- Records spread across three inconsistent systems, or partly on paper, can turn a straightforward phase into a long one.
- Scope that grows mid-build
- New ideas are welcome, but when they join the current phase instead of the next one, the date moves with them.
How to get to a useful version sooner
The aim is a shorter time to value, which is not the same thing as a shorter project.
- Ask for a first useful version — one workflow, end to end, in daily use — rather than the whole system delivered at the end.
- Name one decision-maker who can answer questions within a day or two.
- Get the data ready early: export it, clean it, and agree which list is the right one.
- Start third-party applications on the first day — WhatsApp verification, the payment gateway, API access — in your own name.
- Keep a list for the next phase, and put new ideas on it rather than into the current one.
- Leave out what the first version does not need. For a product, that is the discipline behind MVP and SaaS development; for a business system, it means starting with the module that costs you most every day.
This is how we run custom software development, and it is a reasonable thing to ask of any builder. What the WhatsApp approval involves is set out in what the WhatsApp Business API costs and whether you need it.
Why a short fixed deadline for everything is a red flag
A builder who promises the complete system by a near date, before anyone has worked out the scope, is doing one of three things: they have not understood what you need, they intend to deliver something thinner than you imagine, or they plan to find the time by cutting testing and data migration. None of those shows until it is expensive.
A firm date is reasonable for a scoped first phase. Hold a builder to that, and expect each later phase to be dated when it is scoped. More on judging a builder is in how to choose a software development company.
Sometimes the fastest software is not custom
If you need something working this week, no custom build competes with an off-the-shelf product you can sign up for today, and that is often the right answer. The build-or-buy question is set out for a CRM and for an ERP.
Questions
Related questions
How long does an MVP take to build?
A fixed-scope MVP is built in weeks rather than months, because its scope is cut to the one job the product has to do; the exact timeline is set with the scope.
What keeps it short is what is left out of the first version: a second type of user, admin screens beyond the basics, and integrations nobody has asked for yet.
Can custom software be built in a month?
A single narrow piece can — MyFloww publishes 2–5 weeks for a WhatsApp Business API set-up and 3–6 weeks for an enquiry agent — but a complete business system cannot, and a promise that it will be is a promise of something smaller than you think.
Why does data migration take so long?
Because business data is rarely in one clean place: the same customer appears three ways across spreadsheets, stock counts disagree with the books, and someone has to decide which version is right before anything can be imported.
Starting that clean-up during the build, rather than after it, brings a launch forward.
Should I insist on a fixed deadline?
Insist on a firm date for a scoped first phase, not for the whole system before it has been scoped — a deadline set before the scope exists is a guess, and the work gets cut to fit it.
What slows custom software projects down most?
Most delays come from around the code rather than the code itself: slow decisions, data and content that are not ready, third-party approvals such as WhatsApp Business verification or payment gateway checks, integrations, and migration discovered late.