Web Development Process: Discovery to UAT and Launch

Most SMEs commissioning a custom system have seen a web design process before. Brief, wireframe, design, build, launch. Seven neat steps, one big reveal at the end.

That flow works for a brochure website. It falls apart on a booking engine, a customer portal or an ordering system, because those have business rules that can be right on screen and wrong in practice. Nobody spots a broken refund rule by looking at a mockup. Somebody in your accounts team spots it by running a refund.

This guide is the engineering version of the web development process. It covers what happens between the deposit and the final invoice on a custom project. What discovery must produce, why demos every fortnight beat one reveal, what staging is for, how acceptance testing is written and signed, and what the two weeks after go-live should look like. If your project is a standard marketing site, the seven-step web design process covers that path instead.

The video below explains where user acceptance testing sits in a project and who is meant to run it — the phase most of this guide builds towards.

1. What Does the Web Development Process Actually Cover?

Quick Answer: Six phases, roughly 70 to 110 working days for a mid-size SME system. Discovery, specification, build sprints, staging, UAT, then go-live with hypercare. Two of those six phases are mostly your work rather than the developer's, which is the part quotations rarely spell out. Our web development team books client time into the plan for exactly that reason.

A web development process is not a timeline of when the developer is busy. It is a timeline of when each side is busy, and the phases where the client goes quiet are the phases where projects slip.

The table below is our standard shape for a mid-size custom build — a portal, an ordering system, an internal tool. Read the last column first.

Add the client column up and it comes to roughly 35 to 55 hours of your team's time — most of it concentrated in discovery and UAT. That is a week of somebody's working life, and it is the single most common reason a project quoted at three months takes five. The wider timeline picture for standard sites is in how long it takes to build a website.

Key takeaway: Name the person who will do the 35 to 55 hours of client work before you sign. A project with no named owner on your side has no schedule, only a hope.

2. What Has to Come Out of the Discovery Workshop?

Quick Answer: Four documents, not a feature wishlist. A map of how the work happens today, the exceptions to that map, a prioritised list of what the system must do, and the rules for anything involving money or approval. A workshop that ends with only a feature list has recorded what you want, not how your business runs. The SME requirements document template is what those four turn into.

Most guides describe discovery as a chance to "align on the vision". In practice, discovery is a fact-finding exercise about exceptions, and exceptions are where custom software gets expensive.

The useful questions are unglamorous. What happens when a customer pays half now and half later? Who can override a price, and does anyone need to approve it? What do you do when the same person is both a supplier and a customer? Each answer is a business rule, and each unasked question becomes a change request in month three.

A good workshop produces:

• A current-state process map. Every step as it happens today, including the bits done in WhatsApp and the spreadsheet nobody mentions.
• An exceptions list. The "except when…" cases behind each step, written down with the person who handles them today.
• A must-have and later list. Ranked, with a rough cost against each, so trade-offs get made now rather than mid-build.
• Rules for money and approvals. Discounts, refunds, credit terms, who signs off what. These carry the highest rework cost when they are wrong.

Bring the people who do the work, not only the people who manage it. The counter staff know the exceptions. If you are still deciding whether that team sits inside your company or outside it, in-house developers against outsourcing weighs both sides. For a standard site, the shorter version of this exercise is the website brief template.

Key takeaway: Discovery is about exceptions, not features. If nobody in the room said "except when", the workshop has not finished.

3. Why Do Sprints With Demos Beat One Big Reveal?

Quick Answer: Because the cost of a change is set by when it is found, not by what it is. The same corrected business rule costs about a third as much at a sprint demo as it does after go-live. A fortnightly demo is not a progress report — it is the cheapest defect-finding tool in the whole web development process.

Fixed-price projects often discourage demos, because every demo invites comment. That instinct is backwards. The comments arrive either way; the only question is whether they arrive while the code is still warm.

We log where each change request originated and what it cost to absorb. The pattern holds across build types.

The phase in which change requests are raised on Malaysian SME custom web development projects, showing the share of all change requests raised in each phase and the relative rework cost of a change raised at that point compared with a change raised during discovery.

Phase the change is raised in	Share of all change requests	Share	Relative rework cost
Discovery workshop		21%	1×
Specification review		27%	1.5×
Sprint demo		31%	3×
User acceptance testing		15%	6×
After go-live		6%	14×

Highlighted row is where the largest share is raised. Bars are proportional to the share column. Rework cost is indexed against a change raised during discovery. Source: ZenWeb client sample, 500+ Malaysian SME accounts, 2024–2026, change requests logged on custom builds. Licence.

Roughly half of all changes get raised before a line of code is written — which is the system working. The row to watch is the last one. Only 6% of changes arrive after go-live, but each one costs about fourteen times a discovery change, so that small share does real damage to a budget.

A demo you skipped is not time saved. It is a change request rescheduled to the most expensive week of the project.

Run demos on real data where you can. A demo on sample records shows the screen works; a demo on last month's actual orders shows whether the rules do. When a project has already lost this rhythm, rescuing a stalled web project sets out how to restart it, and why projects get delayed covers the softer causes.

Key takeaway: Put fortnightly demos in the contract as a deliverable. A supplier who prefers to show you the finished system is protecting their schedule, not your budget.

4. What Should Staging Prove Before UAT Starts?

Quick Answer: That the system works outside the developer's laptop. Staging is a full copy of the live setup: same server type, same integrations, same volume of data. It proves deployment, migration and third-party connections before your team is asked to test anything. A staging site that differs from live is not a rehearsal, it is a second guess.

Staging is the step in the web development process most SMEs never hear about, because nothing visible happens in it. It still matters, because staging is where a developer finds out whether the code they wrote can be installed by somebody else, on a clean server, from the repository alone.

Four things should be proven there before your team touches the system:

• Deployment from scratch. The system goes onto an empty server using the committed scripts, not by hand. That capability is part of what you paid for — see source code ownership on a custom web app.
• Data migration with real volume. A rehearsal with your actual records, not fifty test rows. Migrations that pass on small data fail on messy data.
• Every integration in test mode. Payment gateway, e-mail, SMS or WhatsApp, e-invoice, accounting. Each one connected and firing.
• Roles and permissions. Log in as each role and confirm what that role cannot see. Access errors are cheap here and embarrassing later.

Staging also needs to be kept in step with live afterwards, or it quietly stops being useful — the failure described in fixing a staging and live mismatch. If the system holds customer records, the seven principles published by Malaysia's Personal Data Protection Department apply to your staging copy too, which is why real data on staging is masked. The practical setup is in PDPA security for web systems.

Key takeaway: Ask to see the system deployed to a fresh staging server while you watch. Fifteen minutes of that answers more about a supplier than any reference call.

5. How Do You Write UAT Scripts That Catch Real Problems?

Quick Answer: Write them as jobs, not as screens. "Refund a deposit on a cancelled booking made last month" is a script. "Check the refund page" is not. Each script names the tester, the starting data, the steps and the expected result — so a pass is a fact rather than an opinion, and sign-off means something.

User acceptance testing fails for a predictable reason: the client is handed a login and told to "have a look". Two weeks later everyone signs off, and the real defects surface in week one of live running.

Scripts fix that, and they are quicker to write than most people expect. What UAT actually catches, once scripts exist, looks like this.

Defects logged during user acceptance testing on Malaysian SME custom web development projects, grouped by defect class, showing the share of UAT defects in each class, the median time to fix, and whether a sprint demo would normally have caught that class of defect.

Defect class	Share of UAT defects	Median fix time	Would a demo have caught it?
Business rule wrong on a real edge case	29%	2 days	Rarely
Migrated data does not match the old system	18%	3 days	No
Role sees or edits what it should not	16%	1 day	Sometimes
Integration fails on a live-like case	14%	4 days	No
Mobile layout or input problems	13%	1 day	Usually
Labels, wording and number formats	10%	Same day	Usually

Highlighted row is the class no earlier phase reliably catches. Shares are of all defects logged during UAT and total 100. Source: ZenWeb client sample, 500+ Malaysian SME accounts, 2024–2026, defect logs from scripted UAT rounds. Licence.

The top four classes — nearly four defects in five — are the ones a demo cannot find, because they need real data, real roles and real transactions. That is the entire argument for scripted UAT.

How to write a UAT script your team can actually run

Five steps, each one short.

1. Start from a job, not a page. List the ten to twenty tasks the system exists to do — take a booking, issue a refund, close a shift, export for accounts. Those become your scripts.
2. Name the tester and the data. One named person per script, and the exact starting record they will use. Anonymous testing produces anonymous results.
3. Write the steps and the expected result. Number the clicks, then state what should be true at the end, including what the report and the e-mail should say.
4. Add the awkward version. For each job, one script where something is wrong — a payment fails, a booking overlaps, a discount exceeds the limit. This is where the 29% hides.
5. Log every failure in one place, with a severity. Blocker, major or minor, agreed in advance. Sign-off means all blockers closed and a dated list of what remains.

Two weeks is a realistic window for a mid-size system. Run it as scheduled sessions with the testers away from their normal duties, because UAT squeezed between customer calls is UAT that quietly does not happen.

Key takeaway: Sign-off is not a feeling that the system looks fine. It is a list of scripts marked pass, with every blocker closed and the rest dated.

6. What Happens in Go-Live and the Hypercare Window?

Quick Answer: A rehearsed deployment, then two weeks of elevated support with same-day fixes and daily check-ins. Hypercare is not the warranty period and it is not maintenance — it is the fortnight where the developer stays close because the system is meeting real users for the first time. Timelines have tightened as this became standard practice.

Go-live itself should be dull. The migration has been rehearsed on staging, the deployment runs from scripts, and someone holds a written rollback plan. Pick a quiet trading day, not a Friday evening.

Hypercare is the part worth negotiating. Ask what response time applies during those two weeks, who is on call, and how a blocker gets escalated. Then ask what changes on day fifteen, because that is when your web app maintenance and SLA plan takes over.

Year by year from 2021 to 2026 on Malaysian SME custom web development projects, the median number of working days from kickoff to go-live, the median days lost waiting for client sign-off, the median number of defects reported in the first fourteen days after launch, and the share of projects that launched on the agreed date.

Year	Median days to go-live	Days lost to sign-off delay	Defects in first 14 days	Launched on the agreed date
2021	96	23	19	41%
2022	91	21	17	47%
2023	86	19	14	55%
2024	81	17	12	61%
2025	77	15	10	68%
2026	74	13	8	72%

Highlighted row is the current position; 2026 covers January to August. Source: ZenWeb client sample, 500+ Malaysian SME accounts, 2021–2026, custom web development projects from kickoff to fourteen days after launch. Licence.

Two columns move together, and they are the interesting pair. Days lost to sign-off delay have almost halved, and first-fortnight defects have dropped by more than half. Scripted UAT explains a good part of both, because a client who knows exactly what to test signs off faster and misses less. The rest of the gain comes from the web development process being written down at all — projects with named phases and demo dates simply drift less.

Where the new system replaces public pages, plan the URL side too. Google's own guidance on site moves with URL changes sets out the redirect work, and the practical checklists are in the website launch checklist and keeping rankings through a rebuild. Confirm the backups are running before hypercare ends, not after — a backup and restore plan takes an afternoon to set up.

Key takeaway: Get hypercare written into the contract with a response time and an end date. "We will support you after launch" is a sentiment, not a service level.

7. Judge the Process Before You Judge the Portfolio

Quick Answer: Ask three questions of any quotation: how often will I see working software, what does staging prove before my team tests, and what does sign-off require. A supplier with real answers has run this before. A supplier who talks only about design stages is quoting for a website, whatever the system is called.

Portfolios show finished screens. They tell you nothing about whether a project arrived on time, or what the first fortnight after launch felt like for the client's staff.

The web development process does. Discovery that hunts for exceptions, fortnightly demos on real data, a staging rehearsal, scripted UAT with named testers, and a hypercare window with a stated response time. Five things, all of them checkable before you pay a deposit.

We run this shape on every custom build, and the phases are written into the quotation rather than described in a meeting. If you are choosing between platforms first, WordPress, Shopify or custom and headless CMS against standard WordPress are the decisions that come before this one. If you are commissioning now, start with ZenWeb web development, or see how we work across the rest of the business at ZenWeb.

8. Frequently Asked Questions

1. What are the stages of the web development process?

The web development process has six: discovery, specification, build sprints with demos, staging and integration testing, user acceptance testing, then go-live with a hypercare window. A mid-size Malaysian SME system runs about 70 to 110 working days across those six. The design-led flow you may have seen — brief, wireframe, design, build, launch — describes a marketing website and stops short of testing and sign-off.

2. How long should UAT take on a custom web app?

Seven to fourteen working days for a mid-size system, using scripts rather than free exploration. Budget 10 to 20 hours of your team's time inside that window, scheduled as sessions away from normal duties. Rushing it does not save time — defects found in the first fortnight of live running cost several times more than the same defect found during testing.

3. What is the difference between staging and UAT?

Staging is the environment; UAT is the exercise you run inside it. Staging proves the system can be deployed to a clean server, that migrated data lands correctly and that integrations connect. UAT then asks your staff to complete real jobs in that environment and confirm the results are right. Testing on a developer's machine instead of staging is the shortcut that hides deployment problems until go-live.

4. Who should do user acceptance testing — the client or the developer?

Your team, using scripts the developer and you write together. The developer has already tested that the code works; UAT asks whether the system does the business's job, and only the people doing that job daily can answer. Bring counter staff and admin staff, not only managers — they hold the exceptions that break business rules.

5. What is hypercare after a website or system launch?

A fixed period of elevated support immediately after go-live, usually two weeks, with same-day fixes and a daily check-in. It is separate from your warranty and from your monthly maintenance plan. Agree the response time, who is on call and the end date in writing, because that end date is when your ongoing support arrangement takes over.