Most custom software takes between two and sixteen weeks to reach its first live release. A focused MVP or internal tool can be in use within one to three weeks, a custom CRM usually takes three to six, and a multi-module ERP takes six to sixteen, released in phases. How long custom software development takes for your project depends far less on the number of screens than on integrations, data migration and how quickly decisions get made.
This guide breaks the timeline down phase by phase, gives indicative durations by project type, and covers the delays that push launch dates back. For what actually happens inside each stage and what you should receive from it, read the companion guide to the custom software development process.
What determines how long custom software development takes?
In short: the scope of the first release, integrations, data migration, user roles and the speed of your decisions set the timeline. Team size matters less than people expect.
Clients usually estimate by counting screens. It is one of the least reliable predictors. Five factors do most of the work:
- Scope of the first release. One workflow for one team is a matter of weeks. Every department at once is months. The biggest timeline decision you make is what you leave out of release one.
- Integrations. Each connection to another system (accounting package, payment provider, e-mail, a marketplace) brings its own login method, error handling and undocumented behaviour. Each one can add days, or weeks if the other side is slow to grant access.
- Data migration. Moving years of history out of spreadsheets or an old system means finding duplicates, inconsistent codes and missing fields before anything can be imported.
- Roles and business rules. Five user types with different permissions and approval limits mean more to build and much more to test than one.
- Decision speed. A question that waits a week for an answer costs a week. This is the one factor you control completely.
Adding developers to a small project adds coordination before it adds speed. A small senior team on a well-cut scope usually ships sooner than a large team on a vague one.
How long do discovery and requirements take?
In short: days, not months, for most SME projects. Expect a scoped plan within a day of the first call and detailed requirements within the first week.
Discovery answers three questions: what problem are we solving, how will we know it worked, and what is the smallest release that proves it. For a focused business system that is a call or two and a working session, not a three-month specification exercise.
At DataVolve you get a written scoped plan, with a price range and a timeline, within 24 hours of the first call. Turning that into detailed requirements (user stories, roles, a list of data and integrations) typically takes a few days to a week and overlaps with design.
Discovery runs long for two reasons, and neither is technical: nobody inside the business owns the process being changed, or several departments each want their own version of release one.
How long does UX/UI design take?
In short: roughly a week for a clickable prototype of a focused system; longer for a customer-facing product with a distinctive visual identity.
For internal and operational software, design means flows and screens that match how your team actually works. We build a clickable prototype your team can test before any code is written, which is the cheapest point at which to find out that a screen is wrong.
As a rough guide, not a quote: a few days to a week for an internal tool or single module, one to two weeks for a CRM or customer portal (often overlapping with the start of development), and longer for a consumer app where the brand and visual polish are part of what you are selling.
Design moves faster when you bring real material: the spreadsheet your team uses today, screenshots of tools they like, and the forms your customers fill in.
How long does development take?
In short: usually the largest block of time, delivered in weekly increments, with the first usable slice live well before the whole system is finished.
Development is where the agreed scope becomes working software. On a well-run project it is not a long silence: you see working software in a demo every week, and you can change course after any of them.
The number to watch is not total development time but time to first working release. For a focused tool, that can be about 10 days. For a larger system, the first module should be in daily use long before the last one is started.
Integrations and data migration usually happen inside this phase, which is why they move the date so much. A CRM with a clean contact list and no integrations is a different project from the same CRM connected to accounting, e-mail and telephony with eight years of history to import. Our guide to custom software integrations explains what that connection work involves.
How long do testing and QA take?
In short: testing runs alongside development, followed by a user acceptance window of a few days to two weeks before launch.
Good teams test continuously. Automated tests run every time code changes, and each weekly demo is a chance for you to check behaviour. That leaves a focused window before launch for user acceptance testing (UAT), where your own staff run real scenarios on a staging copy of the system.
UAT length depends mostly on you. Two or three staff with time blocked out can finish in days. If they fit it around their normal jobs, the same work takes two weeks. Book your testers before the build starts.
Skipping testing to hit a date does not save time. It moves the time to after launch, when fixes are slower, more visible and more expensive.
How long does deployment take?
In short: a web application can go live in a day once it is ready. Mobile apps add app store review, and data migration adds a cut-over window.
Deploying web software to production is quick when hosting, environments and the release pipeline are set up early in the project rather than at the end. The time goes on what surrounds it: the final data migration, training, and a short period of close support (often called hypercare) after go-live.
Mobile apps also need store approval. Apple says App Review typically reviews at least 50% of submissions in under 24 hours and 90% in under 48 hours. Google Play says some apps and some developer accounts get extended reviews of up to seven days, or longer in exceptional cases. A rejection means a fix and a resubmission, so leave buffer before any date you announce.
Publishing under your company name on the App Store also needs an Apple Developer Program organisation enrolment, which requires a D-U-N-S Number and a working company website. Start that in week one, not launch week.
What is a typical MVP development timeline?
In short: one to two weeks for a validation MVP that proves one workflow; four to ten weeks for a mobile MVP on iOS and Android.
An MVP (minimum viable product) is the smallest version real users can work with to prove or disprove an idea. A validation MVP covering a single workflow typically takes one to two weeks with us. A mobile MVP for iOS and Android sits within the four to ten week range for mobile apps, depending on backend work and integrations.
Illustrative example: a 10-working-day validation MVP
- Days 1–2: scope and prototypeOne workflow and one success measure agreed; clickable screens tested by two or three users
- Days 3–5: core buildData model, the main screen flow and login, deployed to a staging copy
- Day 5: first demoYou use it yourself and change course if something is wrong
- Days 6–8: finish and testEdge cases, automated tests and your feedback applied
- Days 9–10: live with first usersDeployed to production, monitored, feedback captured
The fastest MVPs have one thing in common: a single question they are built to answer. “Will our field engineers log jobs on a phone instead of paper?” can be tested in two weeks. “Build the platform” cannot.
Typical business software timeline by project type
In short: indicative time to first live release ranges from a few days for a single automation to six to sixteen weeks for a phased ERP.
| Project type | Typical time to first live release | What usually stretches it |
|---|---|---|
| Validation MVP: one workflow, prove the idea | 1–2 weeks | Adding a second workflow before the first is proven |
| Internal tool that replaces a spreadsheet | 2–3 weeks | Cleaning the data in the spreadsheet |
| Single business module: inventory, purchasing, pipeline or payroll | 2–4 weeks | Business rules nobody has written down |
| Custom CRM with automation and reporting | 3–6 weeks | E-mail, telephony and accounting integrations; importing contact history |
| Multi-module ERP platform | 6–16 weeks, phased | Data migration, multiple locations, approval chains |
| Mobile app (iOS and Android) | 4–10 weeks | Backend work and app store review |
| E-commerce platform with custom logic | 3–8 weeks | Payment, shipping and stock integrations |
| AI agent (chat or voice) | 2–4 weeks | Connecting to booking or CRM systems; testing real conversations |
| Automation between two systems | 3–10 days | Getting API access and credentials |
These are indicative DataVolve timelines, not a quote. Your timeline is fixed in writing after scoping, alongside the price. For the cost of the same project types, see our UK custom software development cost guide in pounds or the US cost guide in dollars.
Here is how one of those ranges turns into a web application development timeline, week by week.
Illustrative example: a six-week custom CRM (not a real client project)
| Week | What happens | What you see |
|---|---|---|
| Before week 1 | Discovery call; scoped plan, price and timeline within 24 hours; sign-off | A written plan |
| Week 1 | Requirements, roles, data and integration list; clickable prototype | A prototype your sales team clicks through |
| Week 2 | Data model, contacts and pipeline built | First weekly demo on staging |
| Week 3 | First working release: pipeline in use by one sales team | Real enquiries tracked in the new system |
| Week 4 | E-mail and accounting integrations; automated follow-ups | Integrations demonstrated with test data |
| Week 5 | Reporting; trial data migration; user acceptance testing | Your staff testing real scenarios |
| Week 6 | Final migration, training, go-live for the whole team | The old spreadsheet retired |
| Weeks 7–8 | Hypercare: close monitoring and quick fixes | Issues fixed within days |
Notice that real users are working in the system from week three. That is the point of phasing: the software project timeline to first value is half the timeline to “finished”.
What causes delays in a software project?
In short: most delays come from scope changes, data, integrations, slow decisions and third-party approvals, not from how fast anyone writes code.
Scope change mid-build
Every “while you are at it” is reasonable on its own. Together they move the date. Park new ideas on a release-two list, and if one genuinely matters more than something already planned, swap it in rather than adding it.
Data migration
Data is always messier than expected: duplicate customers, product codes that changed meaning years ago, stock levels below zero. Start cleaning before the build and run a trial migration well before go-live, not the weekend before.
Integrations
Third-party systems have rate limits, test environments that behave differently from the live one, and access that has to be requested from a vendor or your IT provider. Request credentials in week one.
Slow decisions
The most common delay and the most avoidable. A developer waiting on an answer either stops or guesses, and guessing is worse because it gets built.
Third-party approvals
App store review, payment provider onboarding, a customer’s IT security questionnaire, a vendor’s approval for API access. You do not control these timelines, so start them early and leave buffer around them.
How to launch custom software faster
In short: phase the work, ship one workflow first, prepare data and access early, and give one person the authority to decide.
- Phase the release. Agree that release one is the smallest slice that pays its way. A phased ERP puts its first module into daily use within weeks instead of waiting months for every module.
- Start with one workflow. One team, one process, one location. It teaches everyone more than weeks of specification, and the next workflow goes faster because the foundations exist.
- Name a decision owner. One person with real authority who answers questions within a day. This alone shortens most projects more than any technical choice.
- Prepare data and access early. Clean the spreadsheet, request API credentials and set up developer accounts before the build needs them.
- Keep what works. Integrate with your accounting package rather than replace it. Replacing working software adds time and risk for little gain.
- Insist on weekly demos. Problems found in week two cost hours. The same problems found in week eight cost weeks.
When you compare vendors, ask each one how they would phase your project and what would be live first. A clear answer is a good sign; our guide on how to choose a software development company covers the other questions worth asking. If you are weighing hiring your own developers to move faster, the in-house vs outsourced development cost calculator compares the two, including recruitment and the months a role can sit empty.
That is how we run our own custom software development projects: a written plan within 24 hours, a clickable prototype before code, a first working release of a focused tool in about 10 days, and a demo every week after that, with the code, cloud account and domain in your name from the first commit.