Project stages explained
What a project looks like from start to finish
Most web and app projects follow a similar path, even when the details differ. This page walks through the stages in the order they usually happen, written for clients rather than developers — so you know what you will be asked for and what you should expect to receive at each point.
The same stages, different lengths
Not every project needs every stage at full depth. A small brochure site might move from discovery to launch in a few weeks. A custom platform with integrations will spend much longer in discovery and testing. The stages stay the same; the time inside them changes — and so does how much of your team's attention each one needs.
Two shapes of the same path
-
A small marketing site
Discovery is short and focused on your services and pages. Design is a handful of templates. Launch arrives quickly, with content often the deciding factor.
-
A custom platform
Discovery covers data, integrations, and user roles. Design involves prototypes of real flows. Build and testing run in longer cycles before launch.
Discovery
Discovery: defining the problem
Discovery is where the team works out what the project actually needs to do. That means talking to the people who will use it, reviewing any existing systems, and writing down the requirements in a form both sides can check. Expect questions about your current tools, your data, and the tasks that take up the most staff time.
A good discovery phase ends with a written scope: what is included, what is not, and what assumptions the estimate rests on. If a proposal arrives without a scope document, ask for one. It is the single most useful thing you will get before work begins, because it becomes the reference point for every later change.
What you should leave discovery with
- A written scope with inclusions, exclusions, and assumptions
- A short list of the people who will use the finished product
- Notes on current tools, data sources, and recurring manual work
- An agreed order for what gets built first if time is tight
Changes cost least before a line of code is written. That is why the review points exist.
Design
Design: wireframes and prototypes
Design usually starts with wireframes, which are simple layouts showing where content and controls sit. Wireframes are deliberately plain. They let you comment on structure without getting distracted by styling. Once the structure is agreed, the team moves to visual design and, often, a clickable prototype in a tool such as Figma.
A prototype lets you walk through a flow, like a booking or a checkout, before any code exists. Changes at this stage are cheap. Changes after the build starts are not, which is why clients are asked to review carefully and sign off. The review points are not there to slow the project down — they are the cheapest place to change your mind.
Wireframes
Plain layouts that show where content and controls sit, so the structure can be agreed before styling begins.
Visual design
Typography, colour, and spacing applied to the agreed layout, usually across a small set of representative screens.
Clickable prototype
A walkable version of a real flow, so you can test a booking or checkout before development starts.
Build
Build: writing and testing the code
The build phase turns approved designs into working software. Work is usually split into short cycles, with something demonstrable at the end of each. You should see progress rather than waiting months for a single reveal.
Testing runs alongside development, not after it: forms, logins, payment or booking flows, and how the site behaves on different screen sizes. If you want the wider picture of platforms, the platforms and frameworks page compares common choices, and websites and web apps covers how the two differ in scope.
Short build cycles
Something demonstrable at the end of each cycle, so you can review real progress instead of a status update.
Testing in parallel
Forms, logins, booking flows, and screen-size checks are tested as features are built, not saved for the end.
Content
Content and data migration
If you are replacing an existing site or system, content and data have to move. That means exporting pages, images, user records, or product data, cleaning them up, and importing them into the new structure. This step is often underestimated. Old content frequently contains broken links, duplicate pages, and images that are too large for the web.
Decide early who owns the content. Some clients write it themselves; others ask the team to migrate and tidy what exists. Either way, the launch date depends on content being ready, not just code.
Common jobs in this stage
- Exporting and cleaning existing pages, images, and product or user records
- Rewriting or editing copy so the new structure reads consistently
- Deciding who writes the content that does not exist yet, and by when
Launch
Launch: going live
Launch covers more than switching a domain. It includes setting up hosting, configuring SSL, checking redirects from old URLs, submitting a sitemap, and confirming that analytics and any required consent notices work. A staging environment, where the site runs privately before it goes public, is standard practice on anything beyond a very small site.
Plan the launch for a low-traffic period if your business has one. Have a rollback plan. And check the site on real devices, not just a desktop browser.
First weeks
After launch: the first weeks
The weeks after launch are for observation. Watch how visitors actually use the site, check error logs, and fix small issues that only appear with real traffic. If you moved an existing site, monitor search console data for redirect problems or pages that dropped out of the index.
This is also when staff training happens. If your team edits content through a CMS, they need access and a short walkthrough. Documentation, even a one-page guide, saves time later.
Watch, then fix
Real traffic surfaces issues that testing misses. Keep the first weeks light so small fixes can be made quickly.
Train the people who will edit
Access plus a short walkthrough means your team can update content without waiting on the studio.
Maintenance
Ongoing maintenance
After the initial period, the work settles into a routine: software updates, backups, monitoring, and occasional improvements. Frameworks and CMS platforms release security and feature updates continuously, and a site that is not updated accumulates risk. The maintenance and support page covers what a support arrangement usually includes.
Updates
Platform and framework releases applied on a regular schedule rather than in one annual push.
Backups and monitoring
Regular copies of your data plus alerting so problems are noticed before your visitors report them.
Improvements
Small changes and new pages handled inside the same routine as fixes, without a new project each time.
Two things that cause most project friction
Requirements shift, and teams are sometimes mixed. Both are normal. What decides whether they cause trouble is how they are handled in writing.
How changes are handled mid-project
Requirements shift. That is normal. The question is how changes are recorded and priced. Most teams work from the signed scope and treat anything outside it as a change request, with its own estimate. This is not bureaucracy; it is how both sides avoid disagreeing later about what was included.
Ask upfront how changes are documented, who approves them, and whether there is a threshold below which small tweaks are absorbed without extra cost. Getting those three answers before the build starts saves the awkward conversation later.
Working with an in-house team
Some Singapore businesses run projects with a mix of internal staff and an external studio. That can work well, but it needs clear boundaries. Decide who owns the code repository, who has production access, and who is responsible for maintenance once the external team steps back.
Write it down. Handover is easier when the expectations are explicit from the start, and it gives new team members something to read.
Questions
Common questions about the process
Do I need a full discovery phase for a small site?
For a brochure site, discovery can be a single conversation and a short written scope. The value is the same: both sides agree on what is included before anyone starts building. Skipping it entirely is what turns a small job into a drawn-out one.
How long does a project usually take?
It depends on scope, not on the stage names. A simple site can move from discovery to launch in a few weeks; a platform with integrations and multiple user roles spends much longer in discovery, build, and testing. The honest answer comes from the scope document, not from a generic timeline.
Who should write the content?
Either can work. Clients who know their business often write the first draft; the studio then edits and migrates it. If the studio is writing from scratch, that work needs to be in the scope and the schedule. What matters is that someone owns it and the launch date reflects that.
What happens if the project needs to change direction?
Most changes are workable if they are recorded. The team writes the change against the scope, estimates it, and you approve it before the work starts. The alternative — absorbing changes quietly — is what pushes timelines out and makes costs hard to explain afterwards.
Can we run the project with our own team as well?
Yes, and it is common in Singapore. The practical requirement is a written split of responsibilities: who owns the repository, who holds production access, who maintains the site after launch, and who makes the final call on design decisions. Set that out at the start and the handover is straightforward.
Where to go next
If you are planning a project, the useful next step is a conversation about scope. Bring your current tools, your data sources, and the tasks that take up the most staff time — that is what discovery starts from. You can reach the studio Monday to Friday, 9:00 AM to 6:00 PM, at +65 6210 8789 or [email protected].
ViewMatrix Digital, Calle Esmeralda 1025, 2340000 Valparaíso, Región Metropolitana, Chile.