After "what does it cost?", this is the question every client asks in the first call: how long will it take? And just like with cost, most answers you'll find online are uselessly vague. "It depends" is true, but it doesn't help you plan a budget cycle, brief your team, or decide whether to start now or after summer.
So here are real numbers. They're based on typical business software projects — internal tools, integrations, customer portals — not on venture-backed product startups building for millions of users. If that's you, different article.
Realistic timelines by project type
- API integration between two systems: 2 to 6 weeks. Connecting your ERP to a supplier portal, syncing your CRM with an invoicing tool. The range depends almost entirely on the quality of the APIs involved, not on the amount of code.
- Internal tool or first working version (MVP): 6 to 12 weeks. A planning tool, an order-intake system, a dashboard that replaces three spreadsheets. Enough to run part of your operation on, not every feature you'll ever want.
- Customer-facing application: 3 to 6 months. A client portal, a mobile app, a booking system. Customer-facing means higher standards: polished UI, proper authentication, edge cases handled, because you can't walk over to a customer's desk and explain a workaround.
- Replacing a legacy system: 4 to 9 months. The build itself is often the fast part. Data migration, running old and new side by side, and untangling twenty years of undocumented business rules is what takes time.
Notice that none of these say "one week" and none say "two years". If a supplier quotes far outside these ranges for a comparable project, ask why. Sometimes there's a good reason. Often there isn't.
What actually determines the timeline
People assume the timeline is about how fast a developer types. It isn't. Four factors dominate:
- Scope clarity. A project where decisions are made upfront moves twice as fast as one where every screen triggers a new discussion. This is why a discovery phase of one to three weeks pays for itself: it front-loads the decisions.
- Integrations. Every external system you connect to adds risk you don't control. A well-documented API costs days. A legacy system with no documentation and a vendor who responds within "five business days" costs weeks.
- Feedback speed. Software gets built in increments, and each increment needs your review. If you respond in two days, the project keeps moving. If reviews sit in an inbox for three weeks, your six-week project quietly becomes a four-month project — with no extra work done.
- The number of people who can say no. One decision-maker: fast. A steering committee of five that meets monthly: slow. This factor alone explains most of the difference between SMB and enterprise timelines for identical functionality.
Where the time actually goes
A typical 10-week project doesn't mean 10 weeks of writing code. It breaks down roughly like this:
- Discovery and design: 1–2 weeks. Working out what to build, what to skip, and how data flows.
- Building in increments: 6–7 weeks. Working software every one to two weeks, reviewed by you.
- Testing, migration and launch: 1–2 weeks. Real data, real users, real edge cases. Always messier than expected — plan for it instead of being surprised by it.
And launch isn't the finish line. Budget for a support period right after go-live, because the first two weeks of real use surface things no test ever will.
How to keep your project short
You control more of the timeline than you think:
- Appoint one decision-maker who can answer questions within 48 hours. Not a committee, one person.
- Arrange access before the project starts: API keys, test accounts, sample data, the contact person at your other vendors. Waiting for access is the most common — and most avoidable — delay.
- Cut scope, not quality. If the timeline is tight, remove features from version one. Shipping 70% of the features in 100% working order beats the reverse, every time.
- Distrust deadlines without a scope attached. "Live in six weeks" means nothing until it's clear what "it" is.
One more honest note: a small studio is often faster than a large agency here, not because anyone types faster, but because there are no handoffs. The person you talk to is the person who builds it. No account manager relaying requirements, no junior team waiting for a senior review. Shorter lines, shorter timelines.
Want a concrete estimate instead of ranges?
Ranges are useful for orientation, but your project has a specific scope, specific integrations, and a specific deadline. Describe your situation and we'll tell you what's realistic — including what we'd cut to hit your date. Want to know where your project lands? Get in touch.