How long a custom web development project actually takes, with real numbers

Getting a straight answer about custom web application development timelines is harder than it should be. Most agencies hedge with "it depends," and most clients end up somewhere between guessing and hoping. After 760 builds across 15 years, I can give you real numbers: the range is 6 to 16 weeks for most projects, and what drives that range is not what most people assume.

The real numbers: 6 to 16 weeks, and what drives the range

Most custom web application development projects run between 6 and 16 weeks from a signed scope document to live deployment. The 6-week end is a tight single-feature build: one workflow digitised, one integration connected, one specific bottleneck removed. Think a custom booking form with calendar sync, or a VirtueMart customisation that automates a pricing update your team runs manually three times a week.

The 16-week end is a full-scale application: multiple user roles, third-party data feeds, a payment layer, and a data migration off a system that has been outgrown. A custom real estate website with a live MLS integration, a client portal, and automated lead routing sits in this range.

What moves a project toward the short end or the long end? Almost never build speed. The variable is brief quality, and more specifically, how many decisions get left undocumented going into build.

I've had projects that should have taken 8 weeks run to 22. Not because the work was hard, but because requirements arrived in pieces. Every undiscussed edge case became a revision cycle.

Week 1 determines whether week 8 is launch or revision

What happens in week 1 sets the trajectory for the entire project, including whether week 8 is a launch or a revision loop. Here's a real build story that shows exactly how much it matters.

In 2023, a property management company came to us after spending four months with another developer on an MLS integration project. They had nothing deployable. The original brief was three paragraphs long and contained no acceptance criteria, no data model, and no written agreement on which edge cases the integration needed to handle.

We started week 1 with a 90-minute structured discovery session. By the end of that week, we had a documented data flow, written acceptance criteria for each of the seven integration endpoints, a prioritised feature list with explicit out-of-scope items, and a 14-page scope document.

The build took nine weeks. QA took one more week. They were live in week 11, including full data migration from their previous system. The previous developer's four months had produced nothing, because there was no agreed-on definition of "done" for a single deliverable.

We call this the Week-1 Lock: a complete, client-approved specification document before the build environment is even touched. What it produces is a document that turns vague features into buildable specifications. "Show listings near a location" sounds clear until you ask: what radius? What property types? What happens if the radius returns zero results? What's the sort order? Each of those questions, answered in week 1, saves a revision round-trip in week 8.

Every decision left undocumented in week 1 becomes a revision request mid-build. A 14-page scope document isn't bureaucracy. It's what makes a 9-week delivery possible.

Where the hours go: a phase-by-phase breakdown

These figures come from delivered projects. Your scope shifts the numbers, but the proportions are consistent.

Discovery and specification: 8 to 24 hours. Stakeholder sessions, user flow mapping, data model documentation, and the written spec. Shorter for a focused single-feature build, longer for anything with third-party data sources or multiple user roles.

Design: 12 to 40 hours. Wireframes, component design, and client review. On projects where the client already has a design system or a detailed style guide, this compresses considerably. On ground-up builds, expect the upper end.

Build: 60 to 200 hours. The widest range, because scope is the variable. A custom Joomla component with a single data entity and a straightforward admin interface sits toward the low end. A multi-role web application with a live MLS feed, automated lead assignment, and a payment integration sits at the high end.

Integration and configuration: 8 to 40 hours. Connecting external APIs, configuring server environments, setting up deployment pipelines. MLS integrations run toward the high end because feed formats vary significantly between providers, and documentation quality ranges from thorough to nearly absent.

QA and launch: 10 to 24 hours. Testing across browsers and devices, fixing what surfaces at scale, a structured launch checklist. This phase has a floor: under 10 hours means something was skipped, and you'll find out what at an inconvenient time.

Total: 98 to 328 hours across a full project. None of those phases are optional. Compressing them doesn't make the work disappear. It moves it to after launch.

How many of your team's current manual workarounds exist because a past project skipped the Week-1 Lock? A scoping conversation with Fastw3b is where that question gets a written answer. From the call you walk away with a documented data flow and acceptance criteria for each feature, out-of-scope items committed to paper before a line of code is written, and a week-by-week timeline tied to your actual requirements rather than a three-paragraph brief. When the spec is signed, a 9-week delivery becomes possible instead of a 22-week drift. Get a week-by-week scope for your custom build →

Why a well-specified custom build often ships faster than a CMS migration

This surprises most clients. Migrating off WordPress or WooCommerce looks like the conservative timeline choice. Often it isn't.

In 2022, a WooCommerce store with eight years of customisation history wanted to move to a custom web application with cleaner inventory management and better order processing. A competing agency had proposed a 10-week migration. When we audited the current system, we found 23 active plugins, 6 of which had been modified at the source code level, not overridden through a child theme but actually edited in place. The checkout flow touched four plugins simultaneously. Four years of order history sat in a non-standard database schema.

That 10-week migration would have run to 26 weeks minimum, and more likely longer once the non-standard schema required custom transformation logic. The ground-up custom build, specified properly from week 1, took 14 weeks. It shipped with better inventory tooling, zero plugin debt, and a codebase any competent developer can maintain.

Hidden platform dependencies are the specific mechanism that inflates migration timelines. Plugins build on top of other plugins. Theme overrides conceal business logic. A proposal that shows a migration as a lift-and-shift is describing the happy path, not the actual path.

If you're evaluating a CMS migration against a ground-up custom build, ask for a full dependency audit of the current system before you accept any timeline estimate. The audit result is the real starting point.

A ground-up custom web application with a solid spec often ships in less time than a platform migration with hidden dependencies. Get the dependency audit before you accept the migration timeline.

The one honest caveat: when a boxed platform is the right call

A platform like WordPress or Joomla genuinely wins on timeline and cost in three specific situations, and I'd rather name them directly.

If your requirement is genuinely standard, a platform gets you there faster and cheaper. A straightforward informational site with a blog, a contact form, and no workflow integration doesn't need custom development. WordPress or a Joomla template will serve you well, and I'll tell you that plainly if you ask.

If speed to market matters more than fit, and you need something live in four weeks because a business commitment depends on it, a configured platform will get you there and a custom build won't. The cost of that trade-off shows up later, when your team starts working around the platform's limitations. But sometimes the trade-off is worth making.

If your workflow maps cleanly to what a platform does out of the box, there's no argument for custom. Most workflows don't map cleanly, which is why businesses eventually outgrow their platforms. But if yours does, build on the platform.

The signal that custom is the right call usually shows up in one of two ways: your team does regular manual work to compensate for what the system can't automate, or a developer has modified plugin source code to make the software match your actual process. At that point, the platform is already costing you more in time and workarounds than a custom build would cost upfront.

What to expect when you reach out

The first conversation is not about your website. It's about your process: what your team actually does day to day, and where the current system forces a workaround or a manual step. That conversation takes about 45 minutes.

From there, we produce a written project scope document before any code is written. It covers functional requirements, the data model, integration points, out-of-scope items, and a realistic week-by-week timeline. That document is yours to take to any developer. A developer who won't produce it before billing you for build hours is worth questioning.

Every project I've shipped in the past 15 years started with that document. The ones that missed their timelines almost always skipped it.

Frequently asked questions

How long does custom web application development take?

Most projects run between 6 and 16 weeks from a signed scope document to live deployment. Simple single-feature builds land at the 6-week end. Full multi-role applications with third-party integrations and data migration sit between 14 and 16 weeks.

What is the biggest timeline risk in a custom project?

A vague or incomplete specification in week 1. Across 760 delivered builds, the projects that ran over schedule almost always had requirements that arrived mid-build, not a build team that worked slowly.

Is migrating from WooCommerce or Joomla faster than building from scratch?

Not always. Platform migrations carry hidden dependencies (plugin chains, modified source code, non-standard database schemas) that inflate timelines well beyond the initial estimate. A well-specified ground-up custom build often ships faster than a complicated migration. Get a dependency audit of the current system before accepting any migration timeline.

When is a platform like WordPress the right choice?

When your requirements are genuinely standard, when you need to go live in under four weeks, or when your workflow maps cleanly to what the platform does out of the box. The clearest signal that custom is right: your team does regular manual workarounds, or a developer has modified plugin source code to match your actual process.

The difference between a 9-week delivery and a 22-week drift is usually one document, and the scoping call with Fastw3b is where that document gets written. Book a custom development scoping call →