Oliveasia.com Pte Ltd · Singapore
How we plan, build, and launch a website
Discovery, design, development, launch, and the maintenance that follows. Here is what happens in each phase, what we need from you, and where you can still change direction.
Why the order matters
Most of the risk sits in the first two weeks
A website project is a sequence of decisions, and the expensive ones are made early. Discovery decides what the site has to do. Structure decides how people move through it. Once design is locked and development starts, changing direction costs real time.
So this page is written as a walkthrough rather than a sales pitch. Each phase below explains what we do, what you need to supply, and the point at which your sign-off moves the project forward. Where a decision is still cheap to reverse, we say so.
-
A written scope before work begins, including the assumptions it rests on
-
One named decision-maker on your side for design and scope approvals
-
Content and product data scheduled alongside the build, not after it
-
Staging access so you can watch progress without touching the live site
Phase one: discovery and scoping
Discovery is where we find out what the site has to do and what it has to connect to. We look at your current site, your content situation, the systems the new site must talk to, and any deadline you are working toward. If you run a store, that includes how orders, stock, and shipping are handled today.
You get a written scope covering pages, features, integrations, and assumptions. Assumptions matter, because most scope disputes are really undiscovered assumptions. For a straightforward corporate website this phase usually takes days rather than weeks. For an ecommerce build with several integrations, allow longer.
What comes out of it
- Page list, feature list, and the integrations the site depends on
- Named assumptions about content, hosting, and third-party systems
- A target date and the dependencies that could move it
Phase two: structure and content
Before any visual design, we map the page hierarchy and the user paths through it. For a corporate website that means deciding what a visitor sees first, how they find proof, and how they contact you. For an online store it means catalogue structure, category logic, and the checkout steps.
Content is drafted or reviewed here, because real copy changes layout decisions. A headline that looks tidy as placeholder text can fall apart once it carries a product name and a delivery promise. If you have existing content, we inventory it and decide what carries over, what gets rewritten, and what gets retired.
This is also where the two page types diverge most. Corporate builds lean on clarity of message and a short path to contact. Store builds lean on category depth, filtering, and a checkout that does not lose people halfway.
Phase three: design in Figma
Design happens in Figma, which gives you something clickable to review rather than a description of a layout. You can open it, tap through it, and argue with it before a single line of the build exists.
We work mobile-first, deciding what survives at small sizes before using larger screens for supporting detail. Prototypes let you test a navigation pattern or a checkout step while changes are still cheap. If you have an in-house designer, we can work inside your file structure; if not, design is part of the build. Expect one or two review rounds built into the schedule.
-
Mobile-first by default
Small screens decide what content earns its place. Wider screens get the detail, not the other way around.
-
Clickable, not described
Prototypes let you test a navigation pattern or a checkout step while changing it is still inexpensive.
-
Your file structure, or ours
If your team works in Figma we collaborate inside it. If design is incomplete, we flag the gaps before development starts.
Phase four: development and integration
Development follows the approved design and scope. Integrations get built here, including payment, shipping, CRM, and any back-office connections. We work in a staging environment so you can see progress without touching the live site, and payment or CRM integrations go through sandbox testing before they touch real data. Where a third-party system has no usable API, we raise it here rather than after launch.
| Integration | How it is handled |
|---|---|
| Payments | Built and exercised in a test environment before live orders are accepted. Settlement is by invoice or bank transfer where that is what you already use. |
| Shipping and stock | Connected to whatever currently holds your stock levels, with fallback rules agreed for items that run out. |
| CRM and back office | Form and order data pushed into the system your team already works in, with the field mapping written down. |
| No usable API | Raised at this stage as a change, with the work it needs spelled out, rather than discovered after launch. |
A checkout step is where an online store is won or lost
Phase five: content loading and QA
Once the build is stable, real content goes in: text, images, product data, and any documents. Quality assurance covers the unglamorous parts that decide whether a launch is calm. Forms that actually send. Emails that actually arrive. Checkout steps that complete. Layouts that hold at unusual screen widths.
We test on real devices, not just a desktop browser resized to look narrow. Accessibility checks happen here too, including keyboard navigation and contrast, because a page that only works with a mouse excludes real customers.
- Forms tested end to end, including the message that lands in your inbox
- Checkout and payment steps run in a test environment before going live
- Real phones and tablets, not only a resized desktop window
- Keyboard navigation and contrast checked across the main templates
- Redirects and search visibility reviewed before the switch
Phase six: launch and handover
Launch day involves more than switching DNS. We check redirects from the old site, confirm search visibility is preserved, and verify that analytics and tracking work as intended. Nothing about that is dramatic, and that is the point.
After launch you get a walkthrough of how to manage content, plus documentation for anything custom. If your team will publish regularly, we make sure the editing workflow is one you can actually use without calling us for every change.
Redirects and search
Old addresses pointed at their new equivalents so links people already saved keep working, and search visibility is checked rather than assumed.
Analytics and tracking
Measurement configured and confirmed on the live site, so the numbers you look at in month two mean something.
Content walkthrough
A session on how to publish, edit, and unpublish, using your own pages rather than a demo.
Documentation
Written notes for anything custom, so a future developer is not left guessing how it was built.
What we need from you
Every project needs a named decision-maker on the client side who can approve design and scope. Content and product data need to arrive on a schedule, because late content is the most common cause of a slipped launch. Access to relevant systems needs to be arranged early: hosting, domain, CRM, and payment accounts.
None of that is unusual. Projects where these are missing take noticeably longer, and the delay rarely comes from the build itself.
Provided by you
One decision-maker who can sign off design and scope without convening a committee.
Provided by us
A phase plan with dates, a written scope, and a heads-up the moment something slips.
Provided by you
Content and product data on the agreed schedule, with a contact for the questions it raises.
Provided by us
Staging access from the first working build, so you are never reviewing screenshots of progress.
Timelines and what affects them
A focused corporate website typically runs several weeks from kickoff to launch. Ecommerce builds with integrations take longer, and the variable is usually integration complexity and content readiness rather than development speed.
We give you a phase plan with dates before work starts, and we flag slippage as it happens rather than at the deadline. If a fixed date matters to you, tell us at the start so we can plan around it instead of negotiating later.
Where projects go wrong
The recurring failure modes are predictable, and naming them up front is how they get avoided.
-
Scope that grows quietly without a change conversation
A handful of small additions can add up to a different project. We raise it as a change with a time and cost implication, and you decide.
-
Content that arrives after design is locked
Real copy changes layout decisions, so late content usually means rework rather than a quick paste.
-
Integrations assumed to be simple
Some systems have no usable API. Finding that in week two is far cheaper than finding it in week eight.
-
One approver turning into a committee late in the build
Approvals that suddenly need five people take longer than the work they are approving. Clear communication is the main thing we ask for.
After launch
Launch is a milestone, not the end. Plugins need updating, platform versions move, and security patches matter more for stores handling customer data. We offer support arrangements covering updates, monitoring, backups, and small changes. Larger additions are quoted separately.
We will also tell you honestly when a request is really a new project rather than a maintenance task, because quoting it as a small change helps nobody.
Support arrangements can cover
- Updates for the platform and its plugins
- Monitoring and backups
- Small content and layout changes
- Security patches, especially for stores
Questions we get before a project starts
If something here is unclear, ask it early. It is cheaper to answer now than to discover the answer during a build.
How involved do I need to be during the build?
You need one decision-maker available for design reviews and scope questions. Day-to-day involvement is light, but late approvals slow everything down. We schedule review points so you know when your input is needed.
Can you work with our existing design files?
Yes. If your team works in Figma, we can build from your files or collaborate inside them. If the design is incomplete, we will flag what is missing before development starts.
What happens if the scope changes mid-project?
We raise it as a change with a time and cost implication, and you decide. Small adjustments are absorbed; anything that affects the schedule gets a written update. This is how projects avoid the slow drift that blows deadlines.
Who handles content once the site is live?
You do, normally. The handover walkthrough uses your own pages so your team can publish without calling us. If you would rather we handle routine updates, that fits into a support arrangement.
Start with the phase that decides the rest
Most conversations about a new website are really conversations about scope, and scope is what discovery settles. Bring what you have, even if it is a rough idea and a deadline, and we will tell you what the build involves and where the unknowns are.
Oliveasia.com Pte Ltd
- 336 Smith Street, #06-302, New Bridge Centre, Singapore 050336
- Call 4753961158
- [email protected]
- Monday to Friday, 9:00 AM – 6:00 PM
For corporate websites, online stores, and adaptive web design across Singapore.