A Web Agency Singapore Contract You Can Walk Away From

The best test of a web agency Singapore SMEs are considering is not the portfolio. It is a single question asked before signing: if we stopped working together in six months, what exactly would we have, and could another developer pick it up on a Monday morning without calling you? Agencies that answer that question clearly tend to be good at the rest of the job too. Agencies that get vague about it are usually protecting something, and what they are protecting is almost always your ability to leave.

This post is about the commercial architecture of a website engagement rather than the design of the site itself. Retainer versus project. How scope goes wrong and what to do about it. What a real handover contains. And the ownership questions around code, hosting and domain that decide whether your website is an asset on your balance sheet or a rental you keep paying for.

Retainer Versus Project: They Solve Different Problems

Most enquiries arrive framed as a project. Build us a website, here is roughly what we want, how much and how long. That framing is fine for a genuine one-off build and actively harmful for everything else, because a website is not a thing you finish. It is a thing you operate.

A project engagement has a defined scope, a fixed or capped price, a delivery date and an end. It is the right shape when you are replacing an old site, launching a new brand, or building something with clear boundaries such as a campaign microsite. It gives you budget certainty and it gives the agency a reason to be efficient.

A retainer buys a recurring block of capacity: some hours, some response commitment, some ongoing responsibility for the thing continuing to work. It is the right shape when the site is commercially important, changes often, or depends on performance that degrades without attention.

The mistake is not choosing one over the other. It is choosing one and pretending the other is not needed. A project-only engagement leaves a live business-critical asset with nobody responsible for it the day after launch. A retainer-only engagement with no project scope tends to drift into small tasks forever, with the substantial improvements always next quarter.

The structure we recommend to most clients is a project for the build with a defined acceptance point, followed by a deliberately small retainer for the first six months, sized to cover website maintenance, security updates and a modest allowance for changes. Small is the operative word. A SGD 1,200 monthly retainer that is genuinely used is worth more than a SGD 3,500 one that quietly banks unused hours and gets cancelled in month four.

The Hours Question

If you are on a retainer with an hours allocation, ask for the hours report monthly and read it. Not because you distrust the agency, but because the report is the single best diagnostic of whether the relationship is working. Hours going into small content edits every month means you need a better content management setup, not more agency time. Hours going into recurring bug fixes on the same component means the build has a defect nobody has been asked to fix properly. Hours going into performance means either the site was built badly or your content team is uploading 4MB images, and both are solvable.

In our experience the retainers that deliver value are the ones with a written monthly priority, agreed in advance, rather than a queue of whatever came up. One substantial improvement a month beats fifteen small ones, and it compounds.

Scoping: Where Most Website Projects Go Wrong

Scope disputes are the most common reason a website engagement turns sour, and they are almost always caused by the same thing. The proposal described pages. The work involved templates, states, content and integrations.

A proposal that says "12 pages" is not a scope. Twelve pages could mean four templates reused three times each, or twelve bespoke layouts, which is a difference of several weeks. It says nothing about how many states each template needs, whether the blog listing has filtering, what happens on an empty search result, how forms behave when validation fails, or who writes the content.

A usable scope document specifies, at minimum:

• Templates, counted as templates, with a note of which pages use each.
• Every form, with its fields, validation behaviour, success state and where the submission goes.
• Integrations by name, with who holds the account and who does the setup.
• Content responsibility per page, with a date by which client-supplied content is due.
• Browser and device support, stated explicitly.
• Performance targets, stated as numbers rather than as "fast".
• Accessibility level, if it matters to you, stated as a standard.
• What happens to the old site and its URLs.

That last one is the quiet budget killer. Redirect mapping from an old site to a new one is real work, it is unglamorous, and if nobody scopes it you will either pay for it as a change request or lose rankings. When we audit post-launch traffic drops, broken redirect mapping is the most frequent cause, ahead of anything to do with design or content. It belongs in the scope alongside the on-page SEO requirements for the new templates, because both need to be built in rather than retrofitted.

Content Is the Schedule Risk, Not the Design

Across the builds we have run, the item that most often slips a timeline is client content. Not approvals, not development. Copy, images, product data and legal text that were assumed to exist and did not.

The honest fix is to decide at scoping time whether content is in scope or out. If it is out, put the due dates in the contract and agree what happens if they slip, because "we will launch when content arrives" means a project that is 90 per cent complete and 100 per cent unbillable sitting on a staging server for four months. If it is in, price it properly. A copywriting workstream for a twelve-template site is a real piece of work and pretending it is a free extra helps nobody.

Stop asking to see the portfolio first

Conventional advice for choosing an agency is to review the portfolio. Look at their past work, check they have done something in your sector, judge the quality.

In reality, the portfolio tells you very little that matters. It shows you the launch-day screenshot of the best five projects out of perhaps sixty, often designed by someone who has since left, frequently with client content that has been replaced since, and always without the constraints that shaped it. A beautiful portfolio piece may have had a SGD 90,000 budget, an in-house brand team and a nine-month timeline. Yours will not.

What we would look at instead, in order:

First, visit three of their client sites that are two or more years old. Not the new ones. Check whether they still load quickly, whether the layout still holds, whether anything is visibly broken. A site that is still solid after two years tells you something about build quality that a launch screenshot cannot.

Second, ask to see a scope document from a comparable past project, redacted. The clarity of that document predicts the experience of working with them better than any visual.

Third, ask who specifically will do the work and whether you can speak to them. Agencies where the person in the pitch is not the person who builds are common and not automatically bad, but you should know which arrangement you are in.

Fourth, ask the walk-away question from the top of this article and listen to how quickly and specifically they answer.

A common mistake we see is a business selecting on aesthetics and then discovering eighteen months later that the site is a custom build on a bespoke framework nobody else understands, hosted on the agency's server, with the domain registered under the agency's account. The design was lovely. The exit cost was SGD 14,000 and four months.

Ownership: Code, Hosting, Domain, Analytics

This is the section to read twice. Four things determine whether you own your web presence or merely use it.

The domain. It should be registered to your company, in an account your company controls, with your billing details. Not the agency's registrar account with your name in a field. Test it by logging in yourself. If you cannot log in, you do not control it. This is the most common lock-in we encounter and the easiest to fix before it becomes a problem.

The hosting. Agency-managed hosting is not inherently wrong, and for many SMEs it is the sensible choice because somebody competent is watching it. What matters is whether the account is in your name with the agency given access, or in the agency's name with you given none. The first is a service. The second is a hostage situation with a monthly invoice. Ask directly: if we leave, do we take the hosting account or do we migrate? Both answers can be fine. Only one of them is fine unplanned.

The code and the CMS. Ask what the site is built on and whether a competent developer outside the agency could work on it. A standard platform with conventional structure is worth a great deal at handover time. A proprietary page builder, a bespoke admin panel, or a framework the agency wrote themselves may produce a better site today and a much worse position in three years. If there is a repository, you should have access to it during the project, not after it.

Analytics and tag management. Same principle. Properties created under your organisation, agency added as a user. When an agency creates an analytics property under their own account, you lose your historical data the day the relationship ends, and historical data is the only thing that lets you tell whether the next agency is doing better.

A single clause in the contract covers most of this: on termination or completion, all accounts, credentials, source code and assets transfer to the client, and the agency provides reasonable transition support. Get it in writing. Any web design partner worth engaging will agree to it without a discussion, because they intend to keep you by being good rather than by holding the keys.

What a Real Handover Contains

Handover is a deliverable, not an email. When we complete a build, the handover package is specified in the scope and includes:

• Admin credentials for every system, transferred to client-owned accounts.
• Repository access and a written note of the hosting architecture.
• A short recorded walkthrough of how to edit each template and publish content.
• The redirect map, as an actual file.
• Known issues and deliberate decisions, written down, including things that were descoped.
• Licence details for every paid plugin or theme, with renewal dates and who is paying.
• Performance baseline numbers at launch, so future degradation is measurable.

That last one matters more than it sounds. Without a launch baseline you cannot tell whether the site got slower or whether it was always slow, and that argument tends to happen eight months later when nobody remembers. Recording load times at handover costs ten minutes and settles the question permanently. If speed is commercially important to you, treat website speed optimisation as a measured target in the scope rather than an aspiration in the proposal.

The plugin licence list is the second underrated item. Sites quietly break two years after launch because a premium plugin licence expired, nobody renewed it, and the update stopped arriving. It is a SGD 79 problem that presents as a catastrophe.

The handover that never happened

One Singapore B2B equipment supplier we worked with came to us after their previous arrangement ended badly. They had a site built four years earlier for around SGD 22,000, which had been a reasonable price for what they got. The problem was everything around it.

The domain was in their former developer's registrar account. Hosting was on a reseller plan in the developer's name. The site ran on a heavily customised theme with a bespoke product module. Analytics had been set up under the developer's personal account. When the developer wound down the business and stopped replying, the client had a live website they could add products to and change nothing else about.

The recovery took eleven weeks. Domain transfer required a registrar dispute process and roughly three weeks of waiting. Hosting migration was straightforward once we had a database export, which took a further two weeks to obtain. The bespoke product module could not be economically maintained, so we rebuilt the catalogue on a standard structure. The analytics history was unrecoverable, which meant they went into the rebuild with no reliable before-picture, and that is the loss that still annoys them.

Total cost of the recovery was roughly SGD 19,000, most of which was rebuilding functionality that already existed and worked. Nothing about the original site was badly made. The failure was entirely in the commercial structure: no ownership clause, no handover, no documentation, and a single point of dependency nobody had thought about while things were going well.

What they do now is simple and worth copying. Every account is in the company name. A named internal person holds the credentials. Any external partner is added as a user and removed when the engagement ends. They ask the walk-away question at every pitch. They kept us on a modest retainer, and the first thing that retainer paid for was documentation rather than features, which took some persuading and has since saved them twice.

Reading a Proposal Properly

Three habits make proposal comparison much less painful.

Normalise the scope before comparing prices. Two proposals at SGD 16,000 and SGD 31,000 are usually not the same work. Write down what each actually includes across templates, content, integrations, redirects, testing, training and post-launch support, and the gap often turns out to be mostly explicable. Sometimes it does not, which is also useful to know.

Look at what each proposal assumes you will provide. The cheaper one frequently assumes you supply final copy, final images, a completed sitemap and all third-party account access. That assumption is not dishonest, but it is a cost that has moved to your side of the table, and it usually costs more in your team's time than it would have in the agency's fee.

Check the payment schedule against delivery milestones. A schedule of 50 per cent upfront and 50 per cent on launch gives the agency no reason to be responsive in the final third, which is exactly when you need them. Something like 30 per cent on start, 30 per cent on design acceptance, 30 per cent on launch and 10 per cent thirty days after launch aligns the incentives far better, and a confident agency will not object to the retention.

If commerce is involved, all of this gets sharper because the stakes are higher and the integrations multiply. Our notes on selecting an ecommerce website design company go into the specific traps there, and the ecommerce website design work we do starts from ownership of the store platform and payment accounts for exactly the reasons above.

Field Notes

Of the website engagements we were asked to review or take over in the past year, a little over half arrived with at least one critical account held outside the client's control. The most common was the domain, followed closely by the analytics property. In four of those cases the client believed they held the domain and discovered otherwise only when we asked them to log in and demonstrate it.

A second number from the same set. Where a launch performance baseline existed, arguments about whether the site had degraded were settled in a single meeting. Where it did not, the same argument consumed multiple meetings and usually ended with an audit costing between SGD 1,500 and SGD 3,000 to establish something that would have taken ten minutes to record at handover.

Third: the median time to recover a domain from an unresponsive former supplier, across the cases we handled, was about three weeks. Not a disaster on its own. A serious problem if it happens during a campaign.

Questions to Ask Before You Sign

• Who owns the code, and can we see the repository during the build?
• Whose name is on the hosting account and the domain registrar account?
• Will analytics and tag manager be created under our organisation?
• What exactly is in the handover package, and is it listed in the contract?
• Who specifically is doing the work, and can we meet them?
• What is the redirect strategy for the existing URLs?
• What are the performance targets, as numbers?
• What happens if our content is late?
• What does support cost after launch, and what response time does it carry?
• If we end the engagement in month seven, what do we have?

None of these are hostile questions. Good agencies answer them quickly because they have answered them before, and the speed of the answer is itself the signal. The user experience design and the visual craft matter enormously for how the site performs, but they are not what determines whether you still control your own web presence in three years. The paperwork is.

If you want a straight read on a proposal you have been sent, or a view on what it would take to bring an existing site back under your control, have a look at how we structure website design engagements, read a little about who we are, and then talk to us. We will tell you if the proposal in front of you is fine, which it sometimes is.

Natasha Tan

Natasha Tan is the founder of Digital Marketing Singapore, a full-service SEO and digital marketing agency based in Singapore. With hands-on experience across SEO, paid media, and content strategy, she works directly with Singapore businesses to build organic visibility and generate consistent leads. Natasha specialises in the Singapore market — including local search behaviour, PDPA compliance, and government grant navigation for SMEs.