Engineering Practice
Engineering Practice5 min read
How long does it take to build custom software? A realistic timeline, phase by phase
Every project has a date someone wants it by. Here is what actually sets the schedule, where time disappears, and how to tell a believable timeline from a hopeful one.
Working on something like this?
Get an estimateThe short version
- Elapsed time is mostly decisions, approvals, and integrations, not typing code.
- The honest answer is a range with named assumptions, never a single date.
- Discovery feels like delay and is the cheapest schedule insurance you can buy.
- A faster date almost always means a smaller first release, not a faster team.
Ask three agencies how long a project will take and you will get three confident answers that disagree. They are usually not disagreeing about how fast engineers type. They are making different assumptions about everything that surrounds the typing: how quickly you will answer questions, what the system has to connect to, and what counts as finished.
This guide breaks a custom build into its phases, shows what stretches each one, and gives you a way to test whether a timeline you have been quoted is believable. The ranges are rough, general guidance for planning, not a quote for your project.
The short answer
A focused first release, one user role and a small number of workflows, is typically a matter of a few months from kickoff to launch. A multi-role platform with several integrations and compliance requirements is better measured in quarters. Anything that must replace a legacy system while it is still running sits at the far end, and is better planned in stages than as a single date.
The phases, and what each one is really doing
1
Discovery and scoping
Turning “we need a portal” into a written scope, an architecture sketch, and a list of what is deliberately left out. It feels like a delay because nothing visible ships. It is the cheapest place in the project to find that two stakeholders disagree, or that a system you must connect to has no usable API. Scoping an MVP covers how to draw that line.
2
Design and prototyping
Flows, screens, and a clickable prototype real users can react to. Time here depends mostly on whether you already have a brand and component library, and on how quickly feedback arrives. Design that waits a week for each round of comments takes a month longer than the design itself.
3
Foundations
Authentication, roles and permissions, environments, deployment pipeline, and the data model. Invisible in a demo and expensive to retrofit. Teams that skip this to show progress early pay for it in the last third of the project.
4
Core build in short cycles
The product itself, delivered in increments you can use and judge, not one reveal at the end. This is the phase people picture when they ask about timelines, and it is rarely the longest in elapsed terms.
5
Integration and data migration
Connecting to payment providers, ERPs, CRMs, or an EHR, and moving existing records across. Elapsed time here is driven by other organisations' sandboxes, approvals, and the true state of your legacy data.
6
Testing, security review, and hardening
Functional testing, performance checks, and a security pass. For regulated work, add evidence collection for HIPAA or SOC 2. Plan it as a phase, not as the last two days.
7
Launch and stabilisation
A staged rollout, monitoring, and a period of fixing what real usage reveals. Launch is the start of the product's life, not the end of the project, and a support arrangement belongs in the plan.
What stretches a schedule
- Slow decisions. The most common cause of overrun is a question that sits unanswered for a week. Name one person who can decide, and agree how fast they respond.
- Integrations you do not control. A third-party sandbox that behaves differently from production, or an approval process measured in weeks, will outlast any internal estimate.
- Scope that grows by agreement. Each reasonable addition is small. Together they are a second project. Keep a written list of what was deferred.
- Unclear ownership on your side. Three people each with partial authority produce the same delay as no one with authority.
- Legacy data. It is never as clean as the person describing it believes, and cleaning it is rarely in the first estimate.
- Compliance discovered late. Requirements that change how authentication, logging, and hosting are built are cheap on day one and costly in month five.
How to make it faster without making it fragile
Levers that genuinely shorten the timeline
- Ship a smaller first release and add to it, rather than compressing a large one
- Defer integrations that can be a manual process or a CSV export for now
- Start from an existing design system or component library
- Give the team one decision-maker and a fixed review turnaround
- Get integration credentials and sandbox access in the first week
- Settle compliance requirements before design starts, not after
Notice what is absent: adding more developers to a late project. Past a point, more people means more coordination, and the schedule does not shrink in proportion. Cutting scope and removing waiting time are the reliable levers.
How to judge a timeline you have been quoted
- 1Is it a range, with assumptions written down? A single date with no assumptions is either padded or about to move.
- 2Does it include discovery, testing, and launch support? A timeline covering only the build phase is not a project timeline.
- 3Does it name the dependencies? Integrations, approvals, and data access should appear as risks, with owners.
- 4Is there a working release along the way? If the first thing you can use arrives at the end, you cannot correct course.
- 5Can you talk to the engineers? The people estimating should be the people building.
Questions to ask a software development agency turns this into a conversation checklist. If you are still weighing whether to build at all, build versus buy is the earlier decision, and timeline is often what tips it.
When you have a specific project and a date in mind, talk to us. We will tell you what we think is realistic, what would move it, and what we would cut to hit the date you need.
Working through this on a real project?
Tell us what you are building. You will get a scoped estimate and an architecture you own, not a capability deck.
Common questions
It depends on scope more than anything. A focused first release with one user role and few integrations is typically a few months from kickoff. A multi-role platform with integrations, single sign-on, and reporting is measured in quarters, and a legacy replacement is best planned in stages. Treat any single figure given before discovery as a guess.
A narrow web application covering one workflow can reach launch in a few months. The elapsed time is driven less by the number of screens than by integrations, user roles, compliance requirements, and how quickly decisions and feedback arrive on the client side.
Usually the shortest of any project type, because the point is to cut breadth. An MVP with one role and no external integrations is commonly a matter of a few months. Every added role or integration extends it, which is why scoping what to leave out is the most effective way to shorten it.
Most often because of waiting, not working: unanswered questions, slow approvals, third-party integrations that behave differently from their documentation, and scope that grew by small agreed additions. Late discovery of compliance or data-quality problems is the other common cause.
Rarely, once the project is underway. New people need time to learn the codebase and add coordination overhead, so the schedule does not shrink in proportion. Cutting scope, removing decision delays, and unblocking integrations are more reliable ways to move a date.
Discovery and scoping, design and prototyping, technical foundations, the core build in short cycles, integration and data migration, testing and security review, and launch with a stabilisation period. Not every project needs every phase at full weight, but skipping discovery or testing usually shows up as delay later.
Ask for a range with the assumptions and dependencies listed, and for the three things most likely to move it. A realistic plan includes discovery, testing, and launch support, delivers something usable early, and is estimated by the engineers who will build it.
It fixes the price for an agreed scope, not the certainty of the schedule. If scope is genuinely fixed, the date is more predictable. If scope changes, which on a first version it usually does, the change-order process decides what happens to both date and cost.