How long does it take to build a website or web app?

Timelines are the second question after cost, and they're easier to answer honestly: most delays come from a handful of predictable causes, and a good process is mostly about avoiding them. Here's how projects run from kickoff to launch and where the time goes.

Rough timelines

• Marketing site or landing page: typically a few weeks from kickoff to launch, depending on the number of pages and how much of the content already exists.
• Custom web application: usually a few months for a first version — longer for products with many roles, billing, or complex integrations.
• Mobile app on an existing web product: shorter than the web build, since the backend is shared — plus app-store review time, which you don't control.

These aren't quotes. Every project gets a specific timeline in discovery, and that's the one I hold myself to.

Where the time goes

• Discovery. Goals, users, budget, and a written scope. Usually the shortest phase and the one that saves the most time later.
• Design. Look, flow, and screens — shared early so direction gets settled before production code. Most timeline risk lives here, because design changes are cheap now and expensive later.
• Build. Focused milestones with clickable previews at each step. You see working software throughout, not a reveal at the end.
• Launch. Domain, hosting, analytics, and — for mobile — App Store and Play Store review.

What makes projects run long

• Content arriving late. On marketing sites, waiting on copy, photos, and logos is the number one delay. Start gathering them before kickoff.
• Decisions by committee. One decision-maker with clear authority moves faster than a group that reconvenes weekly.
• Scope drift. “While we're in there” is how a six-week project becomes a four-month one. Fixed scope protects your timeline as much as your budget.
• Third-party surprises. A partner's API turns out to be undocumented, a store review bounces. These happen; a buffer in the plan absorbs them.

What makes projects ship early

• Examples of what you like. Screenshots, competitors, tools you already use.
• Existing content, even rough. A messy doc beats a blank page.
• Fast feedback on previews. A day's turnaround on each milestone compounds over a project.
• A clear version one. The smallest thing that changes how you work, with everything else on a list for version two.

Need it by a date?

Tell me the date and why it matters — a launch, a season, an event — and I'll tell you in discovery whether it's realistic and what scope fits inside it. Hard dates are workable; surprise dates are not.