Insights · 11 min read
A real timeline comes from three things: the size of the build, the size of the team, and what you actually mean by done. Here is how to get an honest answer.
By GGP Editorial
Most founders ask about cost first, but the timeline is the question that actually shapes the plan. Budget is a number you can move around. Time you cannot buy back, and it decides when you start earning, when you beat a competitor to market, and whether your runway survives the build.
I run a software development company and have been through enough kickoff calls to know that "how long will it take?" is usually the wrong question until a few things are pinned down. Here is how I answer it, and how you should think about it before you sign anything.
Anyone who gives you a timeline before they understand your scope is guessing. A real timeline is the product of three variables: the size of what you are building, the size of the team building it, and what you actually mean by "done."
This is the biggest lever and the one most people understate. A single-purpose app with one user type and one core workflow is a small build. A system with multiple roles, permissions, third-party integrations, and payment or compliance requirements is a different project entirely. The gap between "a CRM" and "a CRM that syncs with three other systems, handles invoicing, and has a mobile app" is not small. It is often a factor of three or four in time.
The honest way to size a build is to count workflows, roles, integrations, and the number of screens that need real logic behind them. Screens are cheap. Logic is not. Two builds can look identical on a wireframe and take wildly different amounts of time, because one of them has simple data entry behind the screens and the other has business rules, validation, and failure handling.
A team of two senior engineers and a team of eight are different machines. The larger team can move faster up to a point, but past that point coordination cost eats the gains. For most business software, a small senior team of three to five people out-delivers a large junior team on both speed and quality. This is one of the reasons our own delivery model leans on senior engineers working in dedicated teams rather than a large interchangeable bench. The calendar is set by the people who actually understand the problem, not by the number of heads.
"Done" is where timelines go to die. Done can mean a working demo, a product you can put in front of five customers, or a system that has passed security review, load testing, and handover to your internal team. Those are three different projects with three different end dates. Before you ask a vendor how long, agree on what done means: which features, which integrations, which non-functional requirements, and who signs off that it is finished. If you cannot say what done means, no vendor can tell you when you get there.
These are ranges we work with, not guarantees. Where you land inside a range depends on scope clarity and how quickly decisions get made.
| Project type | What it usually includes | Typical timeline |
|---|---|---|
| Single-purpose app or internal tool | one core workflow, limited integrations, small user base | 2-3 months |
| Business system (CRM, ERP module, portal) | multiple roles and workflows, several integrations, reporting | 4-7 months |
| Enterprise platform or marketplace | multi-tenant, payments, compliance, complex integrations | 6-12+ months |
A few notes on reading this table. First, these assume a dedicated team is working on your project, not squeezing it in between other clients. Second, the long end of each range is where unclear requirements live. A tightly scoped business system can ship in four months; the same system with vague requirements and slow approvals takes seven or eight.
Third, and this matters, the range covers development and testing. It does not cover your own time in discovery, legal review, or waiting on a third party like a payment provider or a bank to approve you. Those external dependencies sit outside the vendor's control and they show up in every project.
It is rarely the coding. The code is the most predictable part of the build. Projects lose time in the places below, and every one of them is controllable if you know to look.
| Time sink | What actually happens | How to avoid it |
|---|---|---|
| Fuzzy requirements | The team builds, you correct, they rebuild | Spend real time on discovery and scoping first |
| Scope changes mid-build | "Small additions" that are not small | Freeze scope for v1, park new ideas in a list |
| Slow approvals | A decision that takes two weeks blocks everyone | Name a single decision-maker with response times |
| Third-party dependencies | Waiting on a bank, API approval, or vendor | Start integrations and approvals early |
| Skipped QA | Bugs found in production, then emergency fixes | Budget for testing from day one |
The single most expensive line in that table is the first one. Unclear requirements are why two quotes for the same project can differ so much, and why a project that should take three months takes seven. We have written separately about why custom software quotes vary, but the short version is that vendors are pricing your requirements clarity as much as your scope.
The temptation is to skip discovery and start building. It feels like progress. It is usually the opposite.
Two to four weeks of discovery and scoping before development starts is the best time you will spend on the whole project. In that window you define the workflows, the roles, the integrations, and the acceptance criteria. You answer the questions that would otherwise stall the team mid-build, when a stalled team costs money every day. A project that starts with clear requirements ships faster than one that starts early and figures it out on the way.
This is also where a good vendor earns their fee. We treat discovery as a distinct phase with its own deliverable: a requirements document you can actually build from. Our guide to writing a software requirements document walks through what that document should contain, and it is the artifact that makes a timeline reliable.
There is a saying in software that nine women cannot make a baby in a month. It is crude, but it holds. Throwing developers at a late project usually makes it later, because new people need onboarding, the work needs re-splitting, and communication overhead grows with every added head.
The better lever is seniority. Two senior engineers who have built similar systems before will outpace five juniors who are learning the domain on your budget. This is a real argument for choosing a development company on the strength of the specific engineers assigned, not the size of the company. Ask who will actually be on your project, and ask what similar systems they have shipped.
One of the fastest ways to shorten a timeline is to not build the whole thing at once. An MVP with one core workflow gets you to real users in two to three months, and the feedback you get there is worth more than any amount of upfront planning.
The catch is that an MVP only saves time if you treat it as a learning tool, not a smaller version of the full product. Cut scope to the one thing users must be able to do, ship it, and let real usage decide what you build next. We have written about how to define an MVP before hiring developers and about shipping less and learning faster. The timeline benefit is real: an MVP that takes three months to ship beats a full product that takes twelve and misses the market.
If you want the build to move faster, most of the levers are on your side, not the vendor's. Decide fast. Put one person in charge of approvals and hold them to a response time. Freeze the scope for the first version and write every "can we also add" idea into a backlog for later. Start third-party integrations and approvals on day one, because a bank or a payment provider will not move on your schedule. And budget for testing up front, because bugs found in production are far more expensive than bugs found in QA.
On the contracting side, the structure matters too. A fixed price project has a different relationship to time than a time-and-materials engagement: fixed price rewards a locked scope, while time and materials rewards flexibility. If your requirements are still moving, time and materials with a senior team is usually the faster path to done, because you are not renegotiating scope every time you learn something new.
GlobeSoft is a China-based software company with a global delivery model, 40-plus engineers, and more than 300 delivered projects. We work across time zones in English and Portuguese, with clients in Brazil, South Africa, Singapore, and the US, and our stack runs on Java, Spring Boot, Spring Cloud, Go, Node, Python, Vue, and React, with MySQL, Redis, and Nginx underneath.
The way we keep timelines honest is to front-load them. We scope the project before we quote a date, we put senior engineers on the work rather than padding the team, and we agree on a definition of done before development starts. Our clients own their source code, and the delivery plan we agree on is the one we work to.
If you have a project in mind and want a straight read on how long it will take, the useful first step is a scoping conversation. Tell us what you are building, who uses it, and what done means to you, and we can give you a realistic range and tell you which parts of the plan carry the most risk.
How long does a typical custom software project take?
Most business software falls in the four-to-seven-month range for a dedicated team. A single-purpose app can ship in two to three months, and a large platform or marketplace often runs six months or more. The spread comes from scope clarity more than anything else.
Can a project be delivered faster than these ranges?
Sometimes. A tightly scoped MVP with a senior team and fast decisions can ship in two to three months. The levers are scope, seniority, and decision speed, and all three are mostly in your control.
Why do vendors give such different timelines for the same project?
Because they are making different assumptions about scope, team size, and quality. A longer estimate often includes discovery, testing, and the non-functional work; a shorter one may be pricing a demo rather than a product. This is the same reason quotes vary, and you should read every estimate against the definition of done it assumes.
Does a bigger team mean a faster project?
Not past a point. A small senior team usually ships faster than a large junior one, because coordination overhead grows with headcount and experience is what keeps a project from stalling. Ask who is actually assigned, not how many people the company employs.
When should I plan for the timeline to slip?
Plan for slippage around the places outside anyone's control: third-party approvals, changing requirements, and slow internal decisions. Build buffer into those, not into the coding, and the overall plan stays honest.
A timeline is only as good as the scope and decisions behind it. Define what done means, staff it with senior people, and make decisions quickly, and the build will land about where you planned. If you want help turning your idea into a scoped plan with a realistic date, get in touch.
Tell us what you are building and where you are today. We typically reply within 24 hours.
