A ten page website is a design problem. A three hundred page website fails on decision-making long before it fails on design. Most disappointment with corporate website design services traces back to that confusion: the organisation bought a beautiful redesign, launched it, and then watched it degrade over eighteen months as six departments added pages that nobody had designed for.
Nothing dramatic happens. The marketing team publishes a campaign page with a slightly different button. HR adds a careers section using a template someone downloaded. A regional office builds a product page with its own colour accent because the approved palette did not have a warning state. Two years later the site has four button styles, three type scales and eleven variations of the same call to action, and someone in a meeting says the site looks tired and proposes a redesign. The redesign will produce exactly the same outcome unless the governance layer is fixed.
This piece is about the layer underneath the visual work: how to build a site that many people can add to without it falling apart, and how to get a large group of stakeholders to sign off without the project stalling for a quarter.
The real deliverable is a system, not a set of pages
When we scope website design for an organisation with multiple departments, the thing we are actually building is a constrained authoring environment. The pages are an output of it.
That distinction changes everything about how the project runs. A page-based project asks "what should the About page look like". A system-based project asks "what are the twenty five blocks that every page in this organisation will ever need, and what rules govern how they combine".
The second question is harder to answer and produces a far more durable asset. Once a set of components exists and is enforced in the content management system, a marketing executive who has never opened a design tool can build a perfectly on-brand page in forty minutes by choosing from blocks. They cannot choose a wrong colour, because the wrong colour is not in the list. They cannot break the spacing, because the spacing is a property of the block.
A common mistake we see is organisations treating the design system as an internal nicety that can be trimmed from scope when the budget tightens. In reality it is the only part of the project that determines what the site looks like in year three, and cutting it guarantees the degradation described above. If something has to be trimmed, trim the number of unique page designs, not the system that governs them.
What a component library actually needs to contain
A component library that holds up in a corporate environment is not a colour palette and a logo file. It is a set of assembled, tested blocks with rules attached.
| Layer | What it contains | What goes wrong without it |
|---|---|---|
| Foundations | Type scale, spacing scale, colour roles including states, grid, breakpoints | Every new page invents its own spacing; the site feels inconsistent without anyone being able to say why |
| Components | Hero, card, table, form, accordion, testimonial, CTA band, team member, document download | Departments build one-off blocks that break on mobile and are never maintained |
| Patterns | Approved combinations, such as which hero pairs with which intro block | Pages are technically on-brand but structurally chaotic |
| Templates | Full page skeletons for service, case study, article, landing, careers, legal | Every new page is a bespoke build and therefore a bespoke cost |
| Content rules | Headline length limits, image aspect ratios, minimum and maximum items per block | Real content breaks the layout the moment it exceeds the dummy text length |
| Governance | Who can publish, who approves, what requires design review | Anyone can ship anything; the system erodes quietly |
| Accessibility rules | Contrast minimums, focus states, heading order, alt text requirement | Legal and usability risk, plus poor performance in search |
The row people skip is content rules, and it is the one that causes the most visible damage. A card component that looks superb with a four word heading will look broken with a fourteen word heading, and someone in a regional office will absolutely write a fourteen word heading. Either the component has to handle it gracefully or the CMS has to prevent it. Hoping is not a strategy.
The accessibility row is worth treating as a design constraint rather than a compliance checkbox. Contrast minimums and proper heading order are decisions made at foundation stage. Retrofitting them across three hundred pages after launch is genuinely expensive, and heading structure has direct consequences for how well pages are understood, which is why we bring on-page SEO into the template stage rather than treating it as a post-launch pass.
Brand governance across a large site
Governance sounds bureaucratic and mostly is not. It comes down to three decisions.
Who can publish without review? In most organisations the right answer is: anyone, provided they are using approved templates and components only. If the system is constrained, review is unnecessary for routine pages, and requiring review for everything creates a bottleneck that people route around by building pages badly in a hurry.
What triggers a design review? Anything that requests a new component, a new template, or an exception to a content rule. This should be a lightweight request with a short turnaround, not a committee. The critical part is that it is logged, because the log is how you discover that four departments all needed the same thing and the system has a genuine gap.
Who owns the system? One named person or team. Not a committee. Their job is to say no to one-off requests and yes to genuine gaps, and to release updated components on a regular cycle. Without an owner, the system is a document that was true on launch day.
We recommend a quarterly system review in the first year and a half-yearly one after that. The agenda is short: what exceptions were requested, which of them recur, what should be promoted into the library, and what has stopped being used and can be retired. Sites accumulate dead components the way cupboards accumulate cables.
Performance belongs in the same review. Every component carries a weight, and a library that has grown by accretion will slowly make every page heavier. We fold this into website speed optimisation checks rather than treating speed as a one-time launch task, and it pairs naturally with ongoing website maintenance, because an unmaintained corporate site degrades on security and performance well before it degrades on looks.
Sign-off by committee is where the budget goes
Large website projects do not usually fail on design quality. They fail on decision latency. The work is fine; it just takes seven months to approve, by which time the market has moved, two stakeholders have changed roles, and the new arrivals want to reopen settled questions.
Consulting more people produces worse websites, not better ones, and organisations do it anyway because consultation feels like risk reduction. It is the opposite. Every additional approver adds a veto without adding accountability, and the design converges on whatever offends nobody, which is the definition of forgettable.
What actually reduces risk is a clear separation between three roles, agreed in writing before the project starts.
Decider. One person. Usually the marketing lead or a director. They approve direction, templates and launch. If your organisation cannot appoint one, that is information about how the project will go, and it should change the timeline and budget you plan for.
Contributors. Department heads who own content and requirements for their section. They specify what their pages must do. They do not approve visual direction, and they should be told this at the start rather than discovering it in round three.
Consulted. Legal, compliance, IT, regional offices. They review for specific risks within their remit and within a stated window. Silence after the window is agreement. This rule has to be stated in the project charter or it does not work.
Sequencing matters as much as roles. Approve in this order and defend it: strategy and site structure, then wireframes and templates, then visual direction on two key templates, then rollout across the remaining templates, then content, then build. The most common project failure we see is presenting full visual designs before the site structure is signed off. It invites everyone to react to colour while the navigation, which is what actually determines whether the site works, sails through unexamined.
Where the content bottleneck hides
Almost every corporate website project we have been involved in has been delayed by content rather than by design or development. The design is approved in week nine. The site launches in week thirty. The intervening twenty one weeks are spent waiting for eleven departments to write their pages.
This is predictable and therefore preventable. Three measures help.
First, decide early which pages are actually new and which are migrations. Most organisations discover that a large share of their existing pages can be retired outright rather than rewritten, and the audit that reveals this is cheap. A page that received no meaningful traffic in twelve months and serves no legal or sales purpose does not need to be migrated, redesigned or written.
Second, write to the template rather than writing freely and then trying to fit it. Give each contributor the template with its field limits, and have them draft into it. Prose written without constraints always overruns, and the resulting negotiation costs more time than the writing did.
Third, sequence content by traffic and commercial value, not by org chart. The pages that earn the site its results should be written first and written properly, usually with professional help, while low-value pages can be migrated as-is. Our content strategy work on these projects usually starts with exactly that prioritisation exercise.
There is a search dimension to the migration question too. A large redesign is the highest-risk moment in a site's search performance, and the risk is almost entirely in URL changes, redirect mapping and lost internal linking rather than in design. A pre-launch SEO audit against the staging build catches most of it. We have seen organisations lose a meaningful share of their organic visibility on launch day for reasons that a two day check would have prevented.
Regional and multilingual sites break systems faster than anything else
If your organisation operates beyond Singapore, or publishes in more than one language, the component library has to be designed for that on day one. Retrofitting is possible and it is miserable.
The reason is that text length is not a constant. The same sentence in a different language can run substantially longer or shorter, and a navigation bar or button that was designed to fit a specific English phrase will wrap, truncate or overflow the moment it carries a translation. Designers who have not worked on multilingual sites tend to design to the string they were given. Designers who have will test every component against its longest plausible content in every language before signing it off.
Regional autonomy is the governance version of the same problem. A regional office will always have something the central template does not accommodate: a local certification, a different product line, a regulator's required disclosure, a market where the standard hero image is culturally wrong. If the system has no legitimate route for those requests, the office will build around it, and the brand fragments.
The workable answer is a small, explicit set of regional variables defined centrally. A slot for local accreditations. A permitted secondary accent colour per market, chosen centrally rather than locally. A localisable contact block. Everything else stays fixed. This gives regional teams a real answer to their real needs without opening the door to freehand page building, and it converts the most common source of exception requests into a standard feature.
Decide this at foundation stage. It costs very little then and it is one of the most expensive things to add later.
A multi-team rollout, and where it stalled
One Singapore professional services firm we worked with ran a site of around two hundred and forty pages across six practice groups, three office locations and a careers section. Each practice group had, over about four years, developed its own way of presenting a service page. Two groups used a long-form narrative style. Two used a bullet-heavy layout. One had commissioned its own illustrations from a different supplier. The sixth had a page that had not been updated since a partner left the firm.
Their initial request was a redesign. What they actually had was an authoring problem: the CMS permitted free-form page building, and six teams had built six dialects of the same brand.
The useful part of the project was the inventory. We catalogued every page and every unique block in use, which produced a list of over seventy distinct block variations. Sorting them by function rather than appearance collapsed that to nineteen genuine components. Nineteen was a system. Seventy was chaos with a logo on it.
Governance was the harder conversation. The firm's culture gave practice group heads a lot of autonomy, and a single decider was not politically simple. What was agreed instead was narrower and worked: practice groups retained full authority over what their pages said and which components they used, and surrendered authority over how components looked and whether new ones could be created. That split held, because it did not ask anyone to give up the thing they actually cared about.
The measurable outcome was not aesthetic. It was that a new service page went from a two to three week process involving a designer and a developer to something a practice group executive could publish in an afternoon, and the firm stopped paying for bespoke page builds entirely.
Choosing a partner for this kind of work
The questions that separate suppliers on a corporate project are different from the ones that matter on a small site.
- Ask to see a component library they built, ideally two years after launch, and ask how many exceptions were requested since.
- Ask how they handle content that exceeds the design's assumptions. If the answer does not involve constraints in the CMS, they are designing for the demo, not for your staff.
- Ask what their redirect and migration process is, in detail. Vagueness here is the most expensive kind.
- Ask who trains your team and what documentation is handed over. A system nobody knows how to use is not a system.
- Ask how they will handle the stakeholder group you actually have, not the one you wish you had. A supplier who has run multi-department sign-off before will have opinions about it immediately.
- Ask what the site costs to run, not just to build. Hosting, maintenance, component updates and content support are real annual numbers and should be quoted.
If lead capture is a genuine objective rather than a stated one, that also needs to be specified up front, because the templates that serve a credibility-led corporate site are not the same as the ones that serve lead generation, and a site trying to be both without saying so ends up doing neither.
Field Notes
Across the corporate site projects we have audited or rebuilt in the past two years, the component inventory number has been remarkably consistent. Sites between one hundred and four hundred pages typically show somewhere between fifty and ninety distinct visual block variations in use. After functional consolidation, the number of components actually required has landed between sixteen and twenty four every single time.
That gap is the cost. Every surplus variation was designed, built, tested and is now maintained, and none of it adds anything a user can perceive. On an ongoing maintenance retainer, we have seen the consolidation alone reduce quoted monthly effort by roughly a fifth, because there is simply less surface to keep working across browsers and devices.
On budgets, a governed corporate rebuild in this market, with a component library, template set, CMS constraints and migration handling, has typically been quoted by us in the SGD 35,000 to SGD 90,000 range depending on page count, integrations and how many languages are involved. The variable that moves that number most is not design complexity. It is the number of stakeholder groups with veto rights, because every one of them adds review cycles, and we now size project management against that count explicitly rather than against page count.
The sequence that works
Inventory the current site. Consolidate to a real component set. Agree decision rights in writing. Approve structure before visuals. Constrain the CMS so the system cannot be broken casually. Prioritise content by value, not by department. Check the migration before launch, not after. Review the system quarterly and retire what has died.
None of that is glamorous and all of it compounds. The organisations whose sites still look deliberate three years after launch are almost never the ones who bought the most impressive design. They are the ones who bought the strictest system.
If you are planning a rebuild and want a view on your current component sprawl before you brief anyone, our web design team runs that inventory as a standalone piece of work. You may also find our breakdown of what SEO work costs in Singapore useful when budgeting the search side of a migration, and you are welcome to get in touch with your current sitemap for an initial read.
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.
