"How long will this take?"
It's the second question every client asks, right after "how much will it cost?" And the honest answer — "it depends" — is correct but useless. You're trying to plan a budget, set expectations with stakeholders, or coordinate a launch. You need a number, not a philosophy.
So here's what we've learned from delivering custom software projects over the years: not a generic industry average, but the actual timelines we see, what drives them, and where projects lose time that nobody planned for.
The short answer
Most custom software projects take between 3 and 9 months from kickoff to production. That range covers the majority of what businesses actually build: internal tools, client portals, custom CRMs, workflow automation platforms, and SaaS MVPs.
Below 3 months, you're building something small and well-defined — a single-purpose tool, a data migration, or a marketing site with some custom logic. Above 9 months, you're in enterprise territory — multi-module systems, complex integrations with legacy software, or platforms serving thousands of concurrent users.
But that range is meaningless without understanding what determines where your project falls on the spectrum.
What actually determines the timeline
Number of screens and user roles
This is the simplest proxy for project size. A 10-screen application with one user role is a fundamentally different project from a 40-screen application with five user roles, each seeing different data and having different permissions. More screens means more design, more development, more testing, and more edge cases.
Rough guide from our experience: 5-15 screens typically means 2-4 months of development. 15-30 screens means 4-6 months. 30+ screens means 6-9 months or more.
Integrations with other systems
Every integration with an external system — a payment gateway, an accounting tool, a legacy database, a third-party API — adds time. Not because the integration itself is hard (most aren't), but because you're now dependent on another system's documentation, reliability, and response time.
A project with zero integrations is straightforward. A project that needs to sync with SAP, pull data from three APIs, and push notifications through a telecom provider's gateway? That's a different timeline entirely. We typically add 2-4 weeks per significant integration.
How fast decisions get made
This is the factor nobody talks about, and it's often the biggest driver of timeline variance.
We've had projects where the client reviewed designs within 48 hours, answered questions the same day, and made decisions in a single meeting. Those projects finished ahead of schedule. We've had equally-sized projects where design approval took three weeks because it needed five people's sign-off, and questions sat in someone's inbox for days. Those projects took twice as long.
The development team's speed is only half the equation. The client's responsiveness is the other half. A fast agency with a slow client delivers slower than a normal agency with an engaged client.
Clarity of requirements
Projects where the client arrives with a clear brief, validated wireframes, and prioritized features start building faster and stay on track. Projects where requirements are still being discovered during development take longer — not because discovery is bad, but because building while discovering means rework.
We've written a guide on how to write a good software brief specifically to help clients start from a stronger position. The time you invest in clarity before development starts pays back double during development.
Where projects actually lose time
In our experience, the development work itself rarely causes delays. Code gets written. Features get built. The lost time happens around the development, not inside it.
Scope creep without trade-offs. "Can we also add..." is fine — as long as something else gets pushed to Phase 2. When new features get added without removing or deferring anything, the timeline stretches. This is why we use a phased delivery process with explicit scope boundaries.
Design approval loops. A design review that was supposed to take 3 days takes 3 weeks because the decision-maker is traveling, or because "the team" needs to weigh in and the team has 8 opinions. Build a single decision-maker into your process.
Unclear feedback. "I don't like it" without specifics sends the team back to guess. "The dashboard should show monthly trends, not daily" is actionable. The quality of feedback directly affects the speed of iteration.
Integration surprises. The third-party API doesn't work as documented. The legacy system's data is messier than anyone knew. The payment provider takes 3 weeks to approve a sandbox account. These are real, and they're hard to predict. The best mitigation is starting integration work early, not saving it for the end.
A realistic timeline breakdown
Here's how a typical 5-month project breaks down in our process:
Weeks 1-2: Scoping and requirements. Turning the client's brief into a structured requirements document with user stories, priorities, and explicit boundaries. This phase is short but critical — skipping it costs months later.
Weeks 3-4: Design and validation. Wireframes, then UI design. The client sees and approves every screen before we write code. This is where misunderstandings get caught cheaply.
Weeks 5-16: Development in sprints. Two-week cycles with a demo at the end of each. The client sees working software every 14 days. This is the bulk of the timeline, and it's where the screen count and integration complexity determine the actual duration.
Weeks 17-20: Testing, polish, and deployment. QA on staging, client acceptance testing, bug fixes, performance optimization, and the actual go-live. This phase gets compressed on too many projects — don't let it. Rushing to production with untested software costs more than the extra two weeks of QA.
Can you build faster?
Yes, with trade-offs.
Reduce scope. The fastest way to ship sooner is to build less. Launch with the 5 features that matter most and add the rest after production. This is the MVP approach, and it works — but only if the client is willing to launch something that doesn't do everything.
Make decisions faster. If you can commit to 48-hour turnarounds on design reviews and questions, you'll shave weeks off the project without any change in development speed.
Don't add people. Adding developers to a late project makes it later. This is a law of software engineering, not a suggestion. A small, focused team that communicates well will always outperform a large team with coordination overhead.
Use a framework with a mature ecosystem. This is why we build on Laravel — the ecosystem handles auth, admin panels, deployment, and monitoring out of the box, which eliminates weeks of work that would otherwise be built from scratch.
What to do with this information
If you're planning a custom software project, here's how to get a realistic timeline:
Count your screens. List your integrations. Identify your decision-maker. Write a clear brief. Then ask your agency to break the project into phases with time estimates for each phase — not a single "it'll take 6 months" answer.
A good agency will give you a phased timeline that you can track against. A bad agency will give you a single date and hope for the best.
We've written about how pricing models affect project outcomes and when to build vs. buy. Timeline is one piece of a larger set of decisions that determine whether your project succeeds.
Want a realistic timeline for your specific project? Let's scope it together →