ViewQuantum Digital ViewQuantum Digital
Wide view of a Singapore web studio in the afternoon, desks and monitors with the screens turned away, haze through the window

Project stages, explained plainly

How a website project moves from brief to launch

Every website project follows roughly the same path, whether it costs a few thousand dollars or runs into six figures. What changes is how long each stage takes and how much detail goes into it.

A working guide to web development, UX/UI design and ongoing maintenance

What this page covers

Discovery, design, build, content, testing, launch and maintenance — in the order they usually happen, with the honest cost and time variables named at each stage.

The same seven stages, every time

A brochure site, an online store and a custom web app are built from the same sequence. The difference is depth: a one-week discovery on a small corporate site becomes several workshops on a platform with logins and third-party integrations. Knowing the sequence helps you ask better questions before you sign anything, and it helps you recognise when a stage is being quietly skipped.

The order below is not a project management method. It is simply what most studios in Singapore do, in the order that keeps rework cheap. Each stage closes with something you can read and approve before the next one opens.

Discovery sets the ceiling for everything else

Typical length: one week small site, several weeks for a platform

Discovery is where you and the team agree on what the site must do, who it serves, and what success looks like. It usually produces a sitemap, a scope document, and a rough budget. Skipping it feels faster and almost always costs more later, because changes get expensive once design and code exist.

Come prepared with the pages you know you need, the tasks visitors must be able to complete, and any system the site has to talk to — a booking tool, a stock system, a payment provider. If you cannot name those yet, discovery is the stage where they get named.

Design is more than how it looks

Wireframes first, then visual design, then a clickable prototype

Design covers structure, navigation, and the path a visitor takes to complete a task. Wireframes come first, then visual design, then a prototype you can click through. Responsive design is decided here, not added at the end.

If your site needs to work on phones, tablets, and desktops, that has to be visible in the design stage. Retrofitting it afterward means rebuilding layouts, and the rebuild is billed as new work because it is new work.

Structure

Sitemap and navigation that match how people look for things.

Interface

Type, colour, spacing and components, applied consistently.

Behaviour

What happens on tap, on error, and on a slow connection.

Over-the-shoulder view of a designer reviewing a page layout on a studio monitor, hand resting on a trackpad

Reviewing layout and behaviour before anything is built

Staging review, week by week

Build, and what "done" means

During build, the design becomes working code on your chosen platform. This is where CMS templates get configured, forms connect to something, and integrations are wired up. Progress is usually shown in a staging environment you can review — ask for the staging link early and keep using it.

A CMS-driven site and a custom application feel very different to build. The first is mostly configuration and template work; the second adds data models, permissions, and logic that has to be tested against real cases.

Agree this before build starts

"Done" should be defined before build starts: which pages, which browsers, which devices, which integrations. Without that list, scope drifts and timelines slip.

  • The page list, including legal and error pages.
  • Browsers and devices your audience actually uses.
  • Which third-party services must connect, and who owns each account.
  • What counts as a change request after sign-off.

Content is the most common delay. Text, images, product data and legal pages have to come from somewhere — and in most projects, that somewhere is you.

Content arriving late is the single most frequent reason a launch date moves. If you can, gather and approve content in parallel with design. It keeps the build stage from stalling while you chase photos.

Where content support is offered, agree it in the scope rather than assuming it. Ask who writes, who approves, and how many rounds of edits are included before anything is billed as extra.

Testing before anyone sees it

Testing checks that pages load, forms submit, links work, and the site behaves on the devices your audience uses. It also covers accessibility basics and page speed. For stores, it means placing test orders and checking shipping and tax rules end to end.

This stage is not optional, and it is not the same as "we looked at it on our laptop." Ask for a written list of what was tested and on which devices, so you know what was checked and what was never in scope.

Typical checklist: page load, form submission, link routing, mobile layout, accessibility basics, page speed, store checkout

Launch day is quieter than people expect

Going live means moving the site to its production hosting, pointing the domain, and confirming everything works in the real environment. It is usually a short, careful process rather than a dramatic one.

Plan for a quiet period right after launch. Something almost always needs a small fix in the first week.

What maintenance really involves

After launch, a site needs updates: platform and plugin versions, security patches, content changes, and occasional new features. How much depends on the platform. A simple brochure site might need a few hours a month. A store or web app needs more.

Decide who owns this before launch. If it is not the original studio, someone else needs access and documentation — hosting logins, domain records, and a short written note on how the site is assembled.

Monthly or as released

Security patches

Applied as releases land, not batched once a year.

Quarterly minimum

Platform versions

Core and plugin updates, tested on staging first.

As needed

Content changes

Price edits, new pages, seasonal campaigns.

Agree before launch

Backups and uptime

Who restores the site, and how quickly, when something breaks.

Most studios offer this as a retainer or as separately quoted work

Ask which model applies

Timelines in practice

A small corporate site typically runs six to twelve weeks. An e-commerce store with custom design often takes three to five months. A custom web app can run six months or more, depending on integrations and complexity.

These are ranges, not promises. The biggest variables are content readiness, decision speed, and how much custom logic you actually need.

Small corporate site

Six to twelve weeks

Content readiness and how many approvals are needed.

Store with custom design

Three to five months

Product data volume, shipping and tax rules, payment setup.

Custom web app

Six months or more

Number of integrations, user roles, and testing depth.

Ranges reflect common studio practice; your scope decides the final number

Meeting table with closed laptops and an open notebook, two pairs of hands gesturing during a project discussion

The scoping conversation, before anything is quoted

What to have ready before the first meeting

A short brief moves the first meeting from introductions to real numbers. Nothing on this list needs to be polished — it needs to exist.

The pages you already know you need

Home, services, contact, and anything that carries legal or policy text.

The tasks visitors must complete

Enquire, book, buy, download, log in — each one changes the build.

Existing content and brand assets

Even rough text and photos help; missing ones are the delay described above.

Who decides, and how fast

One approver with authority shortens every stage that follows.

Questions people ask before starting

Three answers that come up in almost every first conversation about a new site.

Can a website be built in two weeks?

A very small site on a template can be, if content is ready and requirements are simple. Anything with custom design, integrations, or a store needs more time.

Do I need to write the content myself?

Usually yes, or you hire a copywriter. Some agencies offer content support, but it should be agreed in the scope rather than assumed.

What happens if I want changes after launch?

Most studios handle post-launch changes either as a support retainer or as separate quoted work. Ask which model applies before you sign.

Where to go next with this

You now have the shape of a project and the questions worth asking. The next useful step is comparing how different studios in Singapore work, and understanding which platform your site should sit on before anyone quotes a number.

If something here does not match your situation, write to us with a short description of the site you have in mind. We answer during working hours, Monday to Friday, 9:00 AM to 6:00 PM.

Compare Singapore studios Read about platform choices Send a question
A studio window in the late afternoon with haze and low sun, a desk edge and closed laptop in the foreground

ViewQuantum Digital · Avenida Bernardo O'Higgins 2100, 8320000 Santiago, Región Metropolitana, Chile

+65 6732 9104 · [email protected]

Monday to Friday, 9:00 AM to 6:00 PM