You have signed. The kick off is next Tuesday. Twelve to sixteen weeks from now there is supposed to be a live site. Between those two points sits a process most clients experience as a series of emails asking for things, followed by a long quiet period, followed by a link to a staging site that looks nothing like what they pictured.
It does not have to work that way, and understanding the phases is the cheapest insurance you can buy. When a website development company runs a build well, each phase has an input, an output and a decision gate. When it runs badly, the phases blur, approvals never quite happen, and the first real conversation about whether this is the right site occurs at the point when changing it is most expensive.
This is a walkthrough of the phases as they actually run, with the specific failure mode attached to each one. It is written from the delivery side, because that is the side clients rarely get to see.
Phase zero: discovery, and why it is not free
Discovery is where the project is actually decided. Everything afterwards is execution of decisions made here.
A proper discovery produces four artefacts. A requirements document that lists every page type, every form, every integration and every user role. A sitemap. A content inventory, meaning a row per page with an owner and a source. And a technical approach note covering hosting, CMS, third party dependencies and anything that needs an API key from you.
Duration is typically one to three weeks depending on complexity. Many firms fold this into the proposal stage and effectively give it away, which sounds generous and usually is not. Free discovery is shallow discovery, because nobody can afford to spend a week of senior time on a project they might not win. The consequence is that the requirements document is really an assumption document, and the assumptions get discovered one by one over the following three months.
Where it goes wrong: the stakeholder who was not in the room. Somebody in finance, or legal, or the regional office, who has a hard requirement nobody surfaced. They appear in week nine and their requirement is structural. The fix is procedural and boring: name every person who has approval rights over any part of the site, in writing, in week one. If that list has more than five names, you have a governance problem to solve before you have a build problem.
Second failure mode: discovery that is purely functional and never asks what the site is for commercially. If nobody has written down the conversion goal and how it will be measured, the design phase will optimise for the thing that is easiest to judge, which is appearance. We recommend fixing the measurement plan before the first wireframe, because it changes the wireframe.
Phase one: information architecture and wireframes
Output is a page by page structural blueprint, usually low fidelity, deliberately grey and ugly.
The greyness is the point and clients push back on it constantly. Wireframes are ugly because colour, imagery and typography are extremely good at concealing structural problems. A wireframe that reads poorly will read poorly in full colour too, you just will not notice until launch.
What to actually review at this stage: does each page answer the question a visitor arrives with, in the order they would ask it. Is the primary action visible without scrolling on the templates that matter. Is there a template for every content type in the inventory, including the awkward ones. Does the navigation survive the twelfth menu item.
Where it goes wrong: approving wireframes without reading them properly because they are not exciting. We have seen more expensive rework originate from a rubber stamped wireframe stage than from any other single point in the process. A structural change at wireframe stage costs an hour. The same change after design costs a day. After development, a week. After launch, a renegotiation.
The second failure at this stage is designing the sitemap around the org chart. Departments want their own section. Visitors do not care how you are organised. If your navigation mirrors your internal structure rather than your customers' questions, you are building a site for an audience of employees. This is where a real content strategy earns its fee, because somebody has to be willing to tell the head of a department that their section is merging into someone else's.
Phase two: visual design
Output is high fidelity designs for every unique template, plus a component library covering buttons, forms, cards, tables and states.
The component library matters more than the homepage and gets a fraction of the attention. It is what makes page 40 look like page 1. Ask to see it. If the answer is that the developer will work it out, you are buying a site that will drift.
Realistic duration is two to four weeks with two rounds of revision. Note the phrase two rounds. Revision rounds must be defined in the contract, because open ended revision is the most common route to a project that runs three months late with nobody clearly at fault.
Where it goes wrong: design review by committee with no decision maker. Five people give five opinions, the agency tries to satisfy all of them, and the result is a composite nobody chose. Name one approver. Others advise, one decides.
The second failure is designing with lorem ipsum. Placeholder text is always the perfect length. Real headlines are not. Real product names run onto three lines and break the card layout. Insist that at minimum the key templates are designed with real copy for the real longest and shortest cases, and if that copy does not exist yet, this is the moment to commission blog and article writing or a proper copy pass rather than after the templates are locked.
Phase three: build
Output is a working site on a staging environment, then a content loaded site, then a tested site.
Internally this splits into three sub stages that clients often experience as one long silence. Template development, where the designs become functional code. Content population, where the actual words and images go in. Integration and testing, where the forms connect to wherever they need to connect and everything is checked across browsers and devices.
The silence is a management failure, not a technical necessity. A weekly staging link with a note on what changed costs the agency twenty minutes and prevents the single worst outcome in web projects, which is a client seeing the near finished site for the first time and disliking it fundamentally.
Where it goes wrong, in order of frequency:
Content arrives late. This is the number one cause of overrun and it is usually the client side. Agencies know it and should have built staged content deadlines into the plan. Clients underestimate it because writing 40 pages of copy feels like a task and is actually a project.
Scope creep through informal requests. A request made in a phone call is still a change. Without a written change process, these accumulate invisibly until the timeline breaks and neither party can reconstruct why.
Integrations that turn out to be harder than scoped. The CRM has a rate limit. The payment gateway needs a merchant account that takes three weeks. The inventory system exports CSV on a schedule rather than offering an API. Every one of these is discoverable in discovery if someone asks, and almost none of them are discovered if nobody does.
Performance treated as a final step. Page weight is decided in design and build, not in an optimisation pass at the end. A design with four full width video backgrounds is a slow site and no amount of website speed optimisation at the end will fully fix a decision made at the start. When we audit sluggish sites, the largest single contributor is almost always uncompressed hero imagery that was signed off visually and never questioned technically.
Phase four: launch
Output is the site on the live domain, with redirects in place, analytics firing and DNS propagated.
Launch is a checklist, not an event. The checklist that matters most on a rebuild is redirect mapping: every old URL pointed at its closest new equivalent, with a 301, verified after go live rather than assumed. Missing redirects are the most common cause of the traffic drop that clients report four weeks after a relaunch.
The rest of the list: analytics and tag verification on the live domain, not staging. Form submissions tested end to end including the notification email actually arriving in an inbox somebody monitors. SSL. Sitemap submitted. Robots file checked, because a staging noindex left in place is a genuinely common and catastrophic mistake. Search Console verified and the old sitemap left in place briefly so the crawler can find the redirects.
Where it goes wrong: launching on a Friday. Nothing about a Friday launch is good. The team who can fix things is gone for two days and you are exposed for the entire weekend.
Second failure: launching without a rollback plan. A snapshot of the previous site, retrievable within an hour, costs nothing and is the difference between an inconvenience and a crisis.
Phase five: the first ninety days
This is the phase nobody scopes and everybody needs.
The first two weeks after launch will surface bugs that no amount of testing catches, because real users do things test plans do not. Budget for it. A defect window of 30 days at no charge is a reasonable market norm and you should confirm in writing what counts as a defect versus a change.
Weeks three to twelve are where the site either starts producing results or quietly does not. This is when you look at actual behaviour: which pages people land on, where they leave, whether the forms convert, whether the search traffic recovered to pre launch levels and then exceeded them. Rankings typically wobble for two to six weeks after a well executed migration. If they have not recovered by week eight, something structural is wrong and it is usually redirects or an indexation directive.
It is also when you find out whether the site is usable by your own team. If nobody in your organisation has published a page by day 45, that is a signal, and the response is training rather than acceptance.
Why fixed price builds go wrong
Here is the part that runs against standard buying advice.
Buyers are told to insist on fixed price, because fixed price transfers risk to the vendor. In reality, fixed price on a uncertain scope transfers risk to nobody. It converts it into conflict.
Here is the mechanism. To quote a fixed price, the vendor must price the worst realistic case, or price the expected case and defend the boundary aggressively. Cautious firms do the first, which means you pay a risk premium on a problem that may not occur. Competitive firms do the second, which means the moment reality diverges from the assumption, every conversation becomes a scope negotiation. Neither of these is a partnership. Both are predictable.
A common mistake we see is buyers choosing a fixed price for the entire engagement when the uncertainty is concentrated in one or two components. The sensible structure is usually mixed: fix the price on the parts that are knowable, which is most of design and template development, and use a time and materials or capped allowance on the parts that are not, which is typically integrations and data migration. Then agree a written change mechanism for everything else.
The other thing buyers are told is to get everything in the contract. Worth doing, and it will not save you. Contracts govern disputes. They do not produce good websites. What produces good websites is a short feedback loop, a named decision maker on each side, and a vendor who tells you when you are wrong. If the relationship needs the contract, the project is already in trouble.
A related point on the lowest quote. It is not usually the lowest cost. It is the quote with the fewest assumptions stated, which means it has the most room to grow. When we normalise quotes for clients, the cheapest submission is the one that moves most.
Where one build went sideways, and why
One Singapore logistics services provider we worked with had a build stall at 80 per cent complete for nearly four months. The agency was blaming content. The client was blaming the agency. Both were partly right and neither had a mechanism to resolve it.
The underlying problem was structural. The site had been scoped with a single case study template. During build, the commercial team decided case studies should be filterable by industry, by service line and by region. That is not a content change, it is a taxonomy change, and taxonomy changes touch the database structure, the template, the listing page, the filter component and the URL pattern. It had been requested verbally in a status call and had never been written down as a change.
We did three things. First, we froze the scope in writing and listed every outstanding item as either defect, in scope or change, with the client and agency signing off the classification jointly. That exercise alone took a day and resolved most of the dispute, because the majority of the disputed items turned out to be in scope and were simply unsequenced.
Second, we split the launch. The filterable case study system was pulled out and shipped six weeks after the main site rather than holding the entire build hostage. The core site went live with a simple chronological listing.
Third, we set a content deadline with a stated consequence: any page without final copy by the cut off launched with the approved interim text and would be updated post launch. That removed the incentive to keep waiting for perfect copy.
The site launched 23 days after that intervention, having been stalled for roughly sixteen weeks. The change request for the filter system came in at just under SGD 9,000, which both parties accepted once it was priced as a change rather than argued about as an obligation. Total additional cost to the client was less than the value of a single month of the delay.
The lesson we took from it is not about that client. It is that the absence of a written change process does not prevent changes. It just makes them free to request, impossible to price and expensive to resolve.
Phase timings and what drives them
| Phase | Typical duration | Primary client input | Most common cause of slip |
|---|---|---|---|
| Discovery | 1 to 3 weeks | Stakeholder access, existing data | Missing approver surfaced late |
| IA and wireframes | 1 to 2 weeks | Structural approval | Rubber stamped without review |
| Visual design | 2 to 4 weeks | One named approver, real copy samples | Committee review, no decision maker |
| Template build | 3 to 6 weeks | Brand assets, API credentials | Integration complexity underscoped |
| Content population | 2 to 5 weeks | Final copy and images | Copy not written, no interim fallback |
| Testing and QA | 1 to 2 weeks | UAT participation | Client UAT never scheduled |
| Launch | 2 to 5 days | DNS access, sign off | Redirect map incomplete |
| Stabilisation | 30 to 90 days | Reporting review | No owner assigned post launch |
Two things to note about this table. The client input column is the one that determines whether the duration column holds. And the sum of the ranges is roughly eleven to twenty three weeks, which is why the honest answer to how long a website takes is a range and not a date.
What to ask for at every gate
At the end of each phase, ask for the same three things. What is the deliverable, in a form I can open. What am I approving, specifically, and what becomes expensive to change after I approve it. What do you need from me next, by when, and what happens if it is late.
Those three questions, asked at six gates, prevent most of what goes wrong on website projects. They are not technical questions. They are project management questions, and the reason they work is that they force both sides to be explicit at exactly the moments when it is tempting to be vague.
Field Notes
Looking back across the builds and rescue projects we handled for Singapore clients over the last year, three numbers stand out.
Content was on the critical path in roughly 70 per cent of the delayed projects we reviewed. Not design, not development, not integrations. Words and images.
Of the relaunches we audited where organic traffic fell and stayed down, incomplete or incorrect redirect mapping accounted for the majority. In one case a site had 340 old URLs and 41 redirects, and the recovery work cost more than the redirect mapping would have cost to do properly at launch.
Median number of change requests on a mid sized build, by our count, is between four and seven. Zero is not the realistic target. A written process for handling them is.
Where to go from here
If you are about to start a build, the highest value hour you will spend is the one where you write down every stakeholder with approval rights and every system the site has to talk to. Do it before the kick off.
If you are mid build and it feels like it is drifting, the intervention is almost always the same: freeze, classify every outstanding item, and re sequence. It is unpleasant for a day and it usually saves a month.
You can see how we structure builds on our website design page, including landing page work where the scope is narrower and faster, and ecommerce builds where it is neither. If you want the search side handled inside the build rather than bolted on afterwards, that sits with our on page SEO team, and if visual assets are the gap, our corporate photography service usually removes the longest content delay. For a sense of how budgets typically break down on the search side, our piece on SEO services cost in Singapore covers the same territory. When you want a second pair of eyes on a live project, talk to us.
Natasha Tan is the founder of Digital Marketing Singapore, a full-service SEO and digital marketing agency based in Singapore. With hands-on experience across SEO, paid media, and content strategy, she works directly with Singapore businesses to build organic visibility and generate consistent leads. Natasha specialises in the Singapore market — including local search behaviour, PDPA compliance, and government grant navigation for SMEs.
