Two studios quote what the client describes as the same website, and the estimates come back at five weeks and fourteen. Both can be honest. The gap between them is almost entirely a question of what the site has to do once somebody logs in.
Most builds land between four and twelve weeks. A marketing site with a CMS sits near the bottom of that range, because the shape is well understood and most of the work is design and content dropping into it. A platform with accounts, payments, and role-based permissions sits closer to the top, because each of those is a system carrying its own states and failure modes that have to be decided, built, and tested before anyone can launch.
Asked plainly, the question is about duration. What an estimate is really counting is scope: how many separate systems the product needs, and how many decisions about them are still open on the day work starts. This post is about commissioning something new. If you already have a site and you are weighing how far to go, the governing variable is the architecture you inherited rather than the scope you are choosing, and redesign versus rebuild covers that case instead.
How long each type of build takes
Page count is what buyers tend to count, and it is a poor predictor. Twenty pages built from one template is a smaller job than three pages with a payment flow behind them.
| Roughly | What it is | Where the time goes |
|---|---|---|
| Four weeks | Marketing site with a CMS | Design and content into a known shape. Few integrations, no user accounts, no permissions |
| Six to eight weeks | Content site with real functionality: booking, a gated area, a calculator, one meaningful integration | One or two systems that carry their own states, plus the handling for what happens when they misbehave |
| Twelve weeks | Platform with accounts, payments, and role-based permissions | Each of those is a system in its own right. Failed payments, password recovery, and who is allowed to see what |
These are ranges rather than promises, and the boundaries are soft. What the table is really sorting is the number of things that can be in more than one state at once. A brochure page is either published or it is not. A subscription can be active, lapsed, in a failed-payment retry, cancelled but paid up to the end of the month, or refunded, and every one of those has to look right to the user and to whoever handles support.
The four things that set the number
Past raw scope, four variables move a timeline more than anything else. Two of them sit on the client’s side of the table, which is the part most people are not expecting.
-
Scope surface: systems, not pages. Authentication, payments, and permissions each bring a set of states nobody demos. The demo shows a successful login and a successful checkout. The build has to cover the forgotten password, the expired card, the user who was invited to two accounts, and the admin who should see everything except payroll. That work is invisible in a screenshot and unavoidable in a launch, and it is also the honest input to whether you should be building this from scratch at all, since those same states are the ones an off-the-shelf tool has already solved.
-
Decision latency: how quickly answers come back. A build waits on choices only you can make, and a question that sits unanswered for a week costs a week. This is rarely anyone being slow on purpose. It is usually that the question needed three people in a room and the calendar did not cooperate. Naming the decisions early, and knowing who owns each one, is the cheapest schedule protection available to a client.
-
Content readiness: the copy nobody scheduled. Design and development can work around missing content for a while, and then they cannot. Writing, sourcing, and approving real copy reliably takes longer than people plan for, and it tends to bite late, when there is no slack left to absorb it. Of everything we watch stall a timeline, content is the most common by a comfortable margin, and it is also the most fixable, because it can be started before the build does.
-
Integrations: every system you do not control. A CRM, a payment provider, a booking tool, an inherited database. Each one arrives with its own authentication, its own data shape, its own behavior when something goes wrong, and its own support queue when the problem turns out to be on their side. One integration is a task. Four are a workstream, and their turnaround times are not yours to set.
Why the stack barely moves it
There is a tempting conclusion here that the answer is to pick a faster technology. For the initial build, framework choice is close to noise next to the four variables above. The same feature set takes roughly the same time to specify, build, and test whatever it is built on.
Where the stack does matter is everything after launch. It sets how cheaply the site can be changed, how a refresh two years from now goes, and whether the second redesign updates the site or replaces it. Whether a marketing site needs a JavaScript framework at all is worth deciding carefully, and the architecture that decides redesign cost is worth more attention than the launch date. Neither is what makes your build four weeks or twelve.
Why you should see something real early
Every estimate is a prediction, and predictions about software age badly in private. The useful hedge is not a more detailed spec at the start but working software in front of you quickly, which is why everything we build puts something usable in your hands inside the first two weeks regardless of whether the total is four weeks or twelve.
That matters to a timeline question specifically. When you are clicking through a real thing in week two, the wrong assumptions surface while there is still room to act on them. When the first real look happens at a reveal in week eleven, whatever was misunderstood in week one has had ten weeks to get built on top of, and the correction is no longer a conversation. It is a change order.
How to read an estimate
The number on its own tells you very little. These five questions tell you whether it was arrived at seriously, and the shape of the answer matters more than the exact words.
1. What is on my side of the timeline, and when do you need it? Looking for: a specific list with dates, usually content, brand assets, access credentials, and named decision-makers. An estimate that asks nothing of you has quietly assumed you will be instant.
2. Which parts of this are systems rather than pages? Looking for: accounts, payments, and permissions called out separately, with their edge cases named. If the whole scope is described in pages, the states have not been counted.
3. When do I first see working software? Looking for: weeks, not months. A first look scheduled near the end means the estimate cannot be corrected while correcting it is still cheap.
4. What happens to the date if a decision takes a week? Looking for: a straight answer that the date moves, ideally with which decisions sit on the critical path. Anyone who says the schedule absorbs it has either padded the estimate or is planning to have this argument later.
5. What is not in this estimate? Looking for: the exclusions stated without prompting. Content, third-party licenses, and post-launch support are the usual ones. A quote with no exclusions is not a smaller project, only a less complete answer.
A studio that handles all five with specifics has estimated your project. One that stays vague on more than one has estimated a project shaped roughly like yours.
A long quote is often the honest one
When an estimate comes back longer than expected, the instinct is to read it as padding or as slowness. More often it means somebody counted the failed payments, the permission rules, and the two weeks your team will need to write the copy. The estimate that looks impressively short is frequently the one that stopped counting early, and the difference shows up in month three rather than in the proposal.
If you have a quote in hand and you want a second read on what it does and does not cover, tell us what you’re building. We respond within one business day with the questions we would want answered and a rough scope of our own.