Every prospective client asks the same question: "How long will this take?"
We used to give the diplomatic answer. "It depends on requirements." "Let's scope it first." All true, all useless. The honest answer is simpler: it depends on how disciplined we all are. Not how talented the developers are. Not how big the budget is. How disciplined.
We've shipped projects in six weeks. We've also watched projects at other agencies stretch past six months with less functionality. The gap between those two outcomes has almost nothing to do with the code. It has everything to do with decisions made before a single line gets written.
What 6-week builds have in common
The fastest projects we've delivered share three traits: clear scope, an opinionated stack, and a client who trusts the process.
WSV is a good example. One month, start to finish. The client came in knowing what they needed: a content-driven site with a comprehensive animation system, specific sections, specific pages. No ambiguity about what "done" looked like. We chose Sanity as the CMS on day one. No debate. No two-week evaluation of five different headless CMS options. We picked the tool, configured it, and moved on.
That decisiveness compounds. Every day you don't spend debating a technology choice is a day you spend building. Every feature that's clearly defined in week one is a feature that doesn't get redesigned in week four. The scope document for WSV was tight enough that our designers and developers could work in parallel from the start. While layouts were getting finalized, the CMS schema was already built and content was being entered.
The result wasn't a rushed product. It was a focused one. WSV launched with everything the client needed and nothing they didn't ask for. That's not cutting corners. That's respecting the scope.
What adds weeks (and when that's fine)
Not every project can ship in six weeks, and that's not a failure. Some projects are genuinely more complex, and the timeline should reflect that.
BookIt Sports took two months. The additional time wasn't wasted. It was earned by real complexity: live API integrations pulling scores and odds across multiple leagues, leaderboard systems that needed to handle concurrent users, and data pipelines that had to stay current throughout game days. You can't shortcut an API integration. The third-party service responds how it responds, rate-limits how it rate-limits, and you build around that reality.
The key distinction is that BookIt's longer timeline was planned, not accidental. We knew going in that live data integrations would add weeks. We scoped for it, scheduled for it, and communicated it to the client before the contract was signed. There were no surprises at week six when we said "we need two more weeks for the odds feed." That was always the plan.
Complexity isn't the enemy. Unplanned complexity is. If your project needs real-time data, third-party auth flows, or multi-tenant architecture, it's going to take longer than a content site. That's fine. What matters is that everyone knows it upfront.
What adds months
The projects that stretch to three, four, six months almost never do so because the technical requirements demanded it. They stretch because of decisions that weren't made, or decisions that got unmade halfway through.
Scope creep is the obvious one. "While we're at it, can we add..." is the most expensive sentence in software development. Every feature added mid-sprint doesn't just cost its own development time. It costs the time to re-evaluate how it interacts with everything already built, the time to adjust the design, and the time to re-test what was already working.
Indecision is the quieter killer. We've seen projects lose entire weeks to a client debating between two layouts that are functionally identical. Or two weeks evaluating CMS options that all would have worked fine. Or a month redesigning a dashboard because someone's boss saw a competitor's site and wanted it to "feel more like that."
Footy Access took three months to build. That's three times as long as WSV, but it was longer by design, not by accident. The scope was genuinely larger: subscription management, content scraping pipelines, admin tools for non-technical staff, and a media management system. We knew from the kickoff call that this was a three-month project. The timeline matched the ambition, and the ambition was defined before we started.
The difference between a three-month project that ships on time and a one-month project that ships in three months is planning. One was scoped honestly. The other was scoped wishfully.
The decisions that save the most time
After delivering dozens of projects, we've learned that a handful of decisions made in week one have more impact on timeline than anything that happens in the build phase.
Pick your CMS on day one. Sanity, Payload, Contentful, Strapi. They all work. Spending two weeks evaluating them will not meaningfully change the outcome. What will change the outcome is having content entry start in week two instead of week four.
Use Stripe for payments. Unless you have a regulatory reason to do otherwise, Stripe handles subscriptions, invoicing, and checkout better than anything you'll build yourself. We've seen teams burn six weeks building custom payment flows that Stripe handles out of the box with a few API calls.
Deploy to managed infrastructure. Vercel, Railway, Fly. Pick one. Do not set up your own servers for a v1 launch. The hours spent configuring nginx and SSL certificates are hours not spent building features your users actually care about.
Say no to "nice to have" in v1. This is the hardest one, and it saves the most time. Every feature in your launch should pass a simple test: does the product work without it? If yes, it goes in v2. Dark mode, advanced analytics dashboards, multi-language support, custom notification preferences. All good features. None of them need to be in your first release.
Make design decisions once. Pick your type scale, your color system, your component patterns in the first week. Build a small system, then use it everywhere. Projects that redesign components mid-build don't just lose the redesign time. They lose the time spent rebuilding everything that used the old version.
Our actual process
We keep this tight because tight processes ship faster than loose ones.
Week 1: Scope and architecture. We define every page, every feature, every integration. The client signs off on a scope document that's specific enough to build from. We make our stack decisions here. CMS, hosting, auth, payments. No decisions get deferred.
Weeks 1-2: Design. Design and architecture overlap intentionally. While the system architecture is being set up, design is producing layouts. The client sees designs early enough to give feedback before any code depends on them.
Weeks 2-5: Build. This is where parallel workstreams matter. Frontend, backend, CMS configuration, and content entry all happen simultaneously. We deploy to a staging environment from day one of the build phase, so the client sees real progress every week. No big reveal at the end.
Week 5-6: Polish and launch. QA, performance optimization, SEO checks, accessibility review. We fix what needs fixing and deploy. Launch day is a non-event because the client has been looking at the live staging site for weeks.
The timelines stretch proportionally for larger projects, but the structure stays the same. BookIt followed the same phases over two months. Footy Access followed them over three. The process scales. The discipline doesn't change.
The real answer
So, how long will your project take? If you come in with a clear idea of what you need, trust us to make the technical decisions, and resist the urge to expand scope mid-build, we can move fast. Very fast.
If the scope is still fuzzy, if every decision needs a committee, if "just one more feature" keeps sneaking in after kickoff, it's going to take longer. Not because we're slow. Because the project isn't ready to be built quickly.
The best thing you can do before hiring any development team is get honest about what you actually need for launch. Not what you eventually want. What you need to go live and start learning from real users. Start there. Ship that. Build the rest once you know it matters.