All posts
Owner's Manualabout 10 hours ago6 min read

The Anatomy of a Web Project: What Actually Happens Between Deposit and Launch

You pay a deposit, and then... what? A plain-English walk through the four phases of a web project, what each one is for, what you should see along the way, and the red flags that tell you a project is badly structured before it goes wrong.

J

Jake Moreland

Senior Engineer, Initial Studios

The words Web Project in bold type beside a teal-tinted photo of a hand holding a pencil over dark paper, the series mark for the Owner's Manual series

When you buy a car, someone hands you the keys and an owner's manual. When you buy a website or an app, you get the keys if you're lucky, and nobody has ever handed anyone the manual. This series is that manual. Over the next two weeks we're covering the full life of the thing you're buying: how a project actually works, what happens after launch, how software ages, and how to make the maintain-or-rebuild call when the time comes.

Today: the project itself. Because the period between "here's my deposit" and "we're live" is where most owners feel most in the dark, and it's also where the quality of your outcome is mostly decided.

What are you actually buying?

Here's the reframe that makes everything else in this post make sense: you are not buying pages, you are buying a process that turns your business problem into a working system. The pages are what falls out the end of it.

That matters because two quotes for "a website" can describe wildly different things. One is a person who will start decorating on day one. The other is a team that will first work out why your current enquiries go nowhere, then design and build around fixing that. The second one is buying you an outcome. The first is buying you a brochure.

So when you compare quotes, you're not comparing prices for the same product. You're comparing processes, and the easiest way to judge a process is to know what a good one looks like from the inside.

The four phases, in plain English

Almost every well-run web project, from a landing page to a booking platform, moves through the same four phases. The names change from studio to studio; the jobs don't.

A hand drafting on plans with a pencil and ruler, tinted teal

Discovery is where the thinking happens. Before anyone designs anything, someone should be asking you uncomfortable questions. Where do your customers actually come from? What happens when someone calls and you're on a job? Which enquiries are a waste of your time? Discovery exists to stop you paying for the wrong thing, and it's the phase most often skipped by whoever gave you the cheapest quote. For most small business projects it's measured in days, not weeks.

Design is where you say no cheaply. Layouts, words, and the shape of the thing, shown to you before it's built. The entire point of this phase is that changing a design costs minutes and changing a built feature costs days. If you're going to hate the direction, this is the affordable place to hate it. Speak up here; a good team wants pushback at this stage, not after launch.

Build is where it becomes real. Code gets written, content goes in, forms get wired to your inbox, payments and bookings get connected. From the outside this is the quietest phase, which is exactly why the next section matters.

Launch is a checklist, not a party. Domain pointed, email still working, forms tested with real submissions, analytics recording, old links redirected so Google doesn't lose you. Launch day should be boring. If it's exciting, something was skipped.

What should a week inside the build look like?

You should be able to see progress without asking for a meeting. The single biggest structural difference between a healthy project and a doomed one is a staging link: a private, live version of your unfinished site that you can open on your own phone whenever you like.

Two people talking over coffee at a table by a window, tinted teal

With a staging link, a normal week looks like this: the thing visibly grows, you click around it, you send back "the phone number's wrong and can the photos be bigger", and small course corrections happen while they're still small. Without one, you're waiting for a reveal, and reveals are where budgets go to die, because every piece of feedback you give at the reveal is feedback on something already built.

You don't need to understand the code. You need to see the thing, early and often, in your own hands.

What are the red flags?

A badly structured project announces itself early. In our experience rescuing projects that started elsewhere, these are the tells:

  • No questions about your business. If the first meeting is all templates and colour swatches, you're buying decoration, not an outcome.
  • No staging link. "We'll show you when it's ready" is the single most reliable predictor of a painful project.
  • Vague milestones. "Design phase: 4 weeks" tells you nothing. "You'll have the homepage design to review by the 24th" is a commitment.
  • A one-line quote. "Website: $X" hides everything that matters. You want to see what's included, what's excluded, and what happens when scope changes.
  • Nobody mentions what happens after launch. A team that says nothing about renewals, updates, or ownership is planning to hand you the keys and vanish. More on that in the next post.

None of these mean bad people. They mean a bad structure, and structure is what you're paying for.

What does it cost?

Numbers, because a guide without numbers is a pamphlet. Our fixed build sprints start from $7,400 inc. GST, our day rate is $1,300 inc. GST, and a serious small-business build typically lands in a few weeks, not months. Cheaper exists and can be fine for a simple brochure site. What you're checking is that the price and the process match: a $2,000 quote with a discovery phase is a fiction, and a $30,000 quote without a staging link is a red flag with a lot of zeros.

One more thing about cost: the expensive part of a web project is almost never the code. It's rework. Every phase above exists to catch decisions while they're still cheap to change, which is why a well-structured project routinely costs less than a "cheap" one by the time both are actually finished.

Where this series goes next

Later this week: the part nobody budgets for. Launch day feels like the finish line, and it's actually the starting line, because a website is not a thing you bought, it's a thing you now own. That distinction has a price tag, and it's smaller than you fear and much smaller than ignoring it.

Questions owners actually ask

How long does a website take to build?
For most Australian small businesses, a properly scoped website takes a few weeks from kickoff to launch: days of discovery, about a week of design, one to three weeks of build depending on features like bookings or payments, and a short launch checklist. Months-long timelines usually signal a scoping problem, not a bigger site.
What is a discovery phase, and do I really need one?
Discovery is the short phase where the team works out what your business actually needs before designing anything: where enquiries come from, what wastes your time, what the site must do. For small projects it can be a single structured workshop. Skipping it is how you end up with a beautiful site that doesn't fix anything.
What should a website quote include?
A useful quote names the phases and what each delivers, lists what's included and excluded, states the price inc. GST, commits to a staging link you can view during the build, and says who owns the domain, hosting, and code after launch. A single line reading "website: $X" is a negotiation, not a quote.
Start here

Tell us what is slowing the business down. We will reply with the clearest next step.

No commitment required
Strategy-first conversation
Response within 24 hours

Contact Form