The biggest fork in the road for estimating the cost of a website

When a client asks, “How much does a website cost?” the first thing we always ask is… Are we designing this thing from the ground up, or are we figuring it out as we go?

This is the biggest fork in the road when estimating the cost a site build—and the path you choose has ripple effects on cost, time, ownership, and flexibility. One road leads to a full strategic design process using design tools like Photoshop, Adobe XD, or Figma. The other? A faster, leaner, copy-paste-and-customize approach that evolves live in the browser. Both are valid. But they serve very different types of clients and projects.

Route 1: Full Design Using Design Tools

This is the classic “measure twice, cut once” approach. Everything—from wireframes to final mockups—is thoughtfully designed in a visual design tool before a single line of code is written.

Pros:

  • Strategic Alignment
    You get to zoom out and see the whole story: branding, messaging, user flow, and visual hierarchy. It’s ideal for organizations that need consensus across stakeholders or are doing a full rebrand.

  • Client Confidence
    Stakeholders can “see” the site long before it’s live. That reduces surprises and feedback loops later in the dev phase.

  • Pixel Precision
    Designers get to obsess over the details, which can result in a more polished, unique final product. Perfect for projects where brand perception matters big-time.

  • Design Handoff = Cleaner Dev
    A well-structured design tool file can be gold for developers, especially when paired with component libraries and style guides.

Cons:

  • It’s Slower
    Designing a 10-page site in Figma with all breakpoints and states? That’s weeks of work before dev even begins.

  • It’s More Expensive
    You’re essentially building the site twice—once in a design tool, once in code. That adds hours to the quote.

  • Clients Change Their Mind
    And when they do, everything downstream gets messy. Revisions in design → back to dev → re-QA → lost hours.

  • Designs Can Be Unrealistic
    Sometimes designers add features or layouts that look great in theory but tank performance or blow the dev scope wide open.

This route is ideal if you’re launching something high-profile, investing heavily in brand, or have a lot of cooks in the kitchen. It’s slower and more expensive, yes—but it brings clarity and alignment that ad-hoc building can’t.


Route 2: Build As You Go (aka “Agile method”)

The second path skips the formal design phase and dives right into development using templates, existing components, and a little creative duct tape. This approach relies heavily on mimicking patterns that already work, modifying them, and letting the site evolve in the browser.

Pros:

  • It’s Fast
    You can get a working homepage up in a day, then tweak and build out subpages on the fly.

  • It’s Cheaper
    No design phase means fewer billable hours. You can focus the budget on features or marketing instead.

  • It’s Flexible
    Need to pivot? No problem. Because you’re building live, changes are fast and usually low-cost.

  • Great for MVPs
    If your goal is to launch quickly, test ideas, or validate an offering, this method keeps you moving.

Cons:

  • Risk of Incoherence
    Without a solid design strategy, the site can start to feel stitched together. Think five fonts, six button styles, and no real sense of flow.

  • Harder to Scale
    As the site grows, retrofitting consistency becomes painful. A brand style guide built from live code often becomes an afterthought.

  • Can Undermine UX
    Mimicking without context sometimes misses the why behind a component’s original design. That can lead to usability issues.

  • Fewer Stakeholder Checkpoints
    Without static mockups to review, clients often struggle to visualize the big picture until it’s too late.

This approach shines for startups, solo founders, or low-risk projects where speed and experimentation are more valuable than perfection. It’s also good when clients trust you to guide things without getting deep in the design weeds.


So… Which Fork Is Right?

Here’s the real talk: most small-to-midsize businesses want the polish of a full design process, but need the speed and flexibility of the build-as-you-go model.

At C7.ca, we usually ask:

  • What is your budget? While many people would like Route 1, they may not have the budget for it.
  • How many people need to approve this thing? Are we dealing with one person who is quick and concise or do we need to get umpteen people on a zoom call on a weekly basis.

  • How fast do you need to launch?

  • Is this your forever site, or a stepping stone?

Sometimes we’ll do a hybrid: map out a few key layouts in design tools for stakeholder buy-in, then wing the rest using proven components and CMS-friendly blocks.

The truth is, neither path is “better.” They just solve different problems.

But when you are looking for a quote on a website, not knowing which road you’re on will create a large discrepancy on the quotes you get back. So the take away tip from this article is, get clear on it early, and everything flows from there.


Want help choosing the right path for your next website? Let’s talk.

Simon McCaffrey

Simon has been building software for Canadian businesses for 27 years, from Toronto, on too much coffee. He wires AI into how businesses actually run, and tells you when it is not worth it yet.