Project stages
Discovery, design, build, launch, maintenance
What each stage produces, what it needs from you, and how to tell whether a stage was skipped or quietly merged into another one.
ViewMatrix Digital — Singapore
ViewMatrix Digital publishes plain-language explanations of how websites and mobile apps are planned, built, and maintained, with a focus on Singapore businesses. The site is informational.
Published by ViewMatrix Digital
It exists to help readers understand the vocabulary and stages involved in a development project, so they can evaluate proposals and ask useful questions. If a vendor describes a discovery phase, a design system, or a content model, you should be able to say what that means for your budget, your timeline, and your team.
We don't publish income claims, performance guarantees, or client testimonials. That's a deliberate choice rather than an oversight. A page that promises an outcome can't tell you how the work is scoped, who reviews it, or what happens when the first version of a design doesn't fit. Those details are the useful part.
Everything here is written to be read once and acted on: how a project is planned, which platforms suit which job, and what maintenance looks like after launch.
Our editorial standard
We describe how things are usually done rather than what's best in every case. Frameworks and platforms have trade-offs, and a page that claims one tool wins for everyone isn't useful.
Where a choice depends on your situation, we say so and explain what the deciding factors are — team size, content volume, how often the product changes, and who will look after it in year two.
Our material sits in three areas. Each page is written to stand on its own, so readers arriving from a search engine shouldn't have to work through the whole site to get an answer.
Project stages
What each stage produces, what it needs from you, and how to tell whether a stage was skipped or quietly merged into another one.
Platforms and frameworks
Where each tool tends to fit, which kinds of sites it suits, and the maintenance habits it asks for once the project is live.
Project types
How scope, review cycles, and launch planning differ between a four-page business site and a custom application that people log into daily.
The pages are written and maintained by people who work with web and mobile projects and who read a lot of agency proposals. The goal is to translate the language of those proposals into something a business owner or operations manager can act on.
How a page gets written
We don't name clients or quote project outcomes, because we can't verify those details to a standard we'd be comfortable presenting as fact.
Reviews and case studies are common on agency sites, and readers often find them useful. We've chosen not to include them here, because verifying a quote or a result takes context that a short page can't carry, and unverified praise is worse than none.
If you want to assess a development team, we suggest asking for references directly and speaking to them. Ask what the team would do differently, how they handled a change of scope, and who was actually doing the work week to week. That's more reliable than anything a marketing page can offer.
Read how projects are runPlatforms change. Frameworks release new versions, CMS projects shift their focus, and tooling evolves. A description that was accurate two years ago can quietly become misleading, which is worse than being obviously out of date.
We review pages periodically and update descriptions when something material changes — a tool losing the feature a page leans on, a platform changing how it is licensed, or a stage of work being handled differently in practice. Where facts come from a platform's own published background, we keep to them. WordPress, for example, is described as open source and first released in 2003, because that's documented. We don't add figures we can't support.
If you spot something that looks out of date or unclear, tell us. Corrections are welcome, and the contact page lists how to reach us.
Where to start depends on what you already have. Three common entry points, and where each one leads.
We keep these answers short on purpose. Longer explanations live on the pages they belong to.
Start with the home page and work through the stages in order. Discovery, design, build, launch, and maintenance are covered as a sequence, so the vocabulary builds up instead of arriving all at once.
The platforms and frameworks page and the maintenance and support page answer most of the common ones. Each describes what a tool is used for and where it tends to stop being the right fit, rather than ranking tools against each other.
The how-we-work page describes what each stage should include, so you can check whether a proposal names deliverables, review points, and who is responsible for each part. That is usually where proposals differ most.
Yes. Questions about how something is described, or about a term that isn't explained clearly enough, are as useful as corrections. The contact page lists the email address and working hours.
If you're planning a website or a mobile app for a Singapore business, the stage pages will tell you what to expect at each point. If you're already holding a proposal, the platforms page and the how-we-work page are the fastest way to check it.
Questions about this page or the material it describes can go to the contact page.