A twelve page site for a twelve person company is a design and copy exercise. Corporate website development at 300 pages, across four business units, with legal review, a regional head office, an IT security questionnaire and two systems that must exchange data, is a different discipline wearing the same job title. The technical work is not fundamentally harder. The coordination is an order of magnitude harder, and that is where these projects fail.
The failure is rarely spectacular. Enterprise web projects do not usually collapse. They slide. Eight weeks becomes twenty. The scope that was approved in March is quietly renegotiated in July because a stakeholder who was never consulted has a position. Nobody is at fault in any way that could be written down, which is precisely the problem.
What follows is about the machinery: who decides, how approvals work, what compliance and security actually demand, how integrations behave at scale, and what to do about the fact that large organisations are structurally bad at approving things.
The stakeholder map is the first deliverable
Before a sitemap, before a wireframe, produce a stakeholder map. It is a table with four columns: name, role in the project, what they can approve, and what they can only advise on.
The distinction between approve and advise is the entire document. In most large organisations it is genuinely ambiguous, and the ambiguity is what produces late stage reversals. The head of legal may not have design authority, but does have veto authority over specific claims. The regional marketing director may have brand authority and no authority over information architecture. The IT director has authority over hosting and security and none over messaging. Write it down. Circulate it. Get it acknowledged.
Typical roles on a corporate build, and what they actually own:
Executive sponsor. Owns the business case and the budget. Should approve the strategy and almost nothing else. If your sponsor is reviewing button colours, escalate, because the project has lost its shape.
Project owner. The person whose job this is day to day. Single point of contact, holds the decision log, chases approvals. On projects where this role is split across two people, we consistently see longer timelines, because every ambiguous decision costs a conversation before it costs a decision.
Brand owner. Approves visual direction, tone, logo usage, photography style. Frequently sits in a regional office in a different time zone, which needs to be planned around rather than discovered.
Legal and compliance. Approves claims, disclaimers, privacy notices, cookie behaviour, terms. Should be engaged at content stage, not at pre launch review, where their changes are structurally the most expensive.
IT and security. Approves hosting, access control, data flows, any third party script. Will issue a security questionnaire. Budget two to four weeks for this and ask for the questionnaire in week one.
Business unit leads. Own their own sections' content. Usually the slowest contributors, because the website is nobody's primary job.
If that list runs beyond seven or eight people with approval rights, the project needs a different structure: a small steering group that decides and a wider group that is consulted on a fixed schedule rather than continuously.
Approval mechanics that survive a large organisation
The default approval model on most projects is circulate and wait for comments. At corporate scale this fails, for a specific and predictable reason: silence is ambiguous. Nobody knows whether no response means approval, absence, or an objection being formulated.
What works instead:
Timeboxed approval with a stated default. Deliverable circulates Monday, comments close Thursday at 5pm, no response is recorded as approval. This feels aggressive the first time and becomes normal by the third gate. It has to be agreed by the sponsor in advance to carry weight.
Consolidated feedback through one channel. Feedback arrives to the project owner, who reconciles conflicts before anything reaches the build team. Contradictory instructions reaching a designer directly is how two weeks disappear. In our experience this single rule is worth more than any project management tool.
A decision log with dates. One document, append only, recording what was decided, by whom and when. Its real function is not record keeping, it is stopping the reopening of settled questions. When someone reverses a decision in week fourteen, the log turns it from a disagreement into a change request with a cost attached.
Sign off that is a signature, not an email thread. On regulated or high value builds, each phase gate ends with a named person confirming approval in a form that can be produced later.
Where this goes wrong most often is the escalation path. If a business unit lead will not approve their own section, who decides. Answer that in week one, name the person, and you will need it about half the time.
Compliance and legal considerations in a Singapore corporate build
Corporate sites carry obligations that small business sites frequently ignore without consequence. At corporate scale the consequence is real.
Personal data handling under the PDPA is the main one. Any form that collects personal data needs a clear purpose statement, a consent mechanism that is meaningful rather than pre ticked, a named data protection officer contact, and a retention position. Where the data flows onward matters too: a form that posts into a CRM hosted overseas is a cross border transfer and needs to be handled deliberately. The web team cannot answer these questions. The organisation has to, and the web team has to ask early enough that the answers arrive before the forms are built.
Cookie and tracking consent is the second. If you operate in or market to the EU or UK, or simply want to be defensible, the consent banner has to actually gate the scripts rather than decorate the page. This has a real analytics consequence that marketing teams should understand before launch rather than after: measured traffic will fall when consent is implemented properly, and the fall is measurement, not performance. We have watched more than one team panic at a 15 per cent drop in recorded sessions that was entirely a consent artefact.
Accessibility is the third and the most commonly deferred. For government linked entities and increasingly for large corporates with procurement requirements, WCAG level AA is the working standard. Retrofitting accessibility is expensive; building to it is nearly free if it is specified at design stage. Colour contrast, keyboard navigation, focus states, alt text discipline and form labelling are all design decisions, not development ones.
Claims substantiation is the fourth and the one that eats timeline. Every superlative on a corporate site is a potential problem. Market leading, fastest, number one, award winning. Legal will ask for the basis. If the basis is a slide from 2019, the claim changes. Run a claims pass over draft copy before design lock, not after.
Integration reality at corporate scale
Small sites have a contact form. Corporate sites have a data architecture.
| Integration | What it actually involves | Common underestimate |
|---|---|---|
| CRM handoff | Field mapping, lead assignment rules, deduplication, failure handling | Treating it as a form redirect rather than a data contract |
| Single sign on for a client portal | Identity provider config, role mapping, session handling, IT security review | Assuming the identity team has capacity this quarter |
| ERP or inventory feed | Scheduled export, transformation, caching, stale data handling | Expecting a real time API where only a nightly CSV exists |
| Multi language content | Translation workflow, URL structure, hreflang, per market governance | Budgeting translation but not the ongoing review process |
| Careers and applicant tracking | Embedded or API driven listings, application flow, candidate data handling | Iframe embeds that break responsive layout and are not indexable |
| Marketing automation | Tracking scripts, consent gating, form sync, campaign attribution | Consent requirements breaking the tracking that was scoped |
| Document and resource library | Gating logic, access control, file management, versioning | Nobody owns the files after launch |
Two structural points about this table.
First, every row involves a team outside the web project. The CRM row needs the sales operations owner. The SSO row needs identity management. The ERP row needs whoever owns that system, who is typically the busiest person in the building. Your timeline is now dependent on people who have not been told they are on your timeline. Identify them in discovery and get their availability confirmed in writing.
Second, each row needs a failure behaviour specified. What does the site do when the CRM is down. What does the product page show when the nightly feed did not run. These are not edge cases at corporate volume, they are Tuesday. A build that has not specified failure behaviour has specified it implicitly, and the implicit answer is usually an error page.
Where enterprise projects actually stall
Conventional wisdom says that bigger organisations need more process, more documentation and more formal sign off. The uncomfortable truth is that most corporate web projects are already over governed and under decided.
There is a specific pattern we see repeatedly. Twelve people attend every review. The workshop deck runs to 60 slides. There is a RACI matrix, a risk register and a fortnightly steering meeting. And the project is four months late, because with twelve people in the room nobody is individually accountable for saying yes, and saying yes is the only act that moves a web project forward.
Process is not the same as decisiveness. Very often it is a substitute for it. The meeting is where the decision gets deferred to the next meeting with a request for more options, and the request for more options is how a stakeholder avoids being the person who chose.
In reality the corporate builds that run to time tend to have unfashionably small decision structures. One accountable owner with genuine delegated authority. A steering group of three that meets monthly to hear status rather than to decide details. A consult list that is informed on a schedule and does not hold a veto. That is less governance in headcount terms and more governance in the sense that matters, which is clarity about who decides what.
The second piece of received wisdom worth pushing on: that enterprise projects need enterprise technology. Very often they do not. We have seen organisations specify a heavyweight platform with a six figure annual licence, in SGD terms well past SGD 100,000 a year, for a marketing site whose actual requirements were 200 pages, three languages and a CRM connection. The platform decision was driven by procurement's comfort with vendor size rather than by requirements. The result was a longer build, a smaller pool of people able to work on it, and a marketing team that still could not publish a page without a ticket. The requirement was never platform scale. It was workflow, permissions and governance, which are configuration questions.
Choose the platform after the requirements are written, and make the person who has to publish content weekly part of that decision. The cost of a platform your team cannot use is not the licence. It is three years of every change being a project.
A regional rollout with four approvers
One Singapore headquartered regional services group we worked with ran a corporate rebuild across five markets. The site had to carry a group narrative and five local market propositions, in three languages, with a shared investor relations section and a careers portal feeding an applicant tracking system.
The first attempt stalled. Each market wanted control over its own homepage. Group brand wanted consistency. The steering committee had nine members with no stated approval hierarchy, and four consecutive meetings ended with an action to explore options.
The intervention was not technical. We restructured the decision model. Group owned the template system, the component library, the navigation structure and the brand layer, with a single named approver. Markets owned content within the templates, with local approval and no template modification rights. Anything a market wanted that the templates did not support became a formal request to group, assessed once per quarter, with any approved change built into the shared component library so every market got it.
That one boundary resolved roughly 80 per cent of the outstanding disputes, because most of them had been arguments about who decides rather than about what was right.
Two other things mattered. We front loaded the IT security review by requesting the questionnaire in the first week rather than at pre launch, which turned out to be the correct call: it surfaced a hosting region requirement that would have forced a migration three days before go live. And we split the launch, shipping the group site and two markets first, then the remaining three at six week intervals, which meant the translation and local content workload was sequential rather than simultaneous.
The build ran fourteen weeks for the first release against an original sixteen week estimate for everything. The remaining markets went live over the following four months. Post launch, the group marketing team published 47 pages in the first quarter without agency involvement, which was the actual objective all along and the one nobody had written into the original brief.
What corporate buyers should specify that SMEs do not need
A few requirements are worth stating explicitly in a corporate brief because they will not be assumed.
Role based permissions. Who can draft, who can publish, who can edit navigation, who can touch templates. Specify the roles, not just the number of users.
An approval workflow inside the CMS. Draft, review, publish, with an audit trail. If compliance has to see content before it goes live, that has to be a system behaviour, not a habit.
Environment separation. Development, staging and production, with a documented promotion path. Editing production directly is how corporate sites break at inconvenient moments.
Uptime, backup and recovery expectations, written as numbers. Backup frequency, retention period, restore time objective. Agree them or you have implicitly agreed to whatever the host does by default.
Content governance after launch. Who reviews what, how often, and what happens to pages nobody owns. Corporate sites do not suffer from too little content, they suffer from orphaned content that is three years stale and still ranking. An ongoing website maintenance arrangement should cover content review cycles, not only patching.
A documented design system handover. Not a PDF of screenshots. A living component library the next agency or internal team can build against without reverse engineering.
Where search, brand and lead generation fit
A corporate rebuild is the largest single risk event in a site's organic history, and it is also the largest single opportunity. Template level metadata, structured heading hierarchy, internal link patterns and a clean URL taxonomy are cheap to build in and expensive to retrofit across 300 pages. Getting an SEO consultant involved at the architecture stage rather than the pre launch stage is the difference between a migration that recovers in three weeks and one that takes six months.
Equally, corporate sites tend to be measured on brand credibility and neglected as lead generation assets. Both are legitimate goals and they pull the design in different directions. Decide the ratio explicitly. A site that is 90 per cent brand and 10 per cent conversion is a valid choice; a site where nobody decided is usually 100 per cent brand by accident.
The third consideration is where the traffic comes from once you launch. Corporate audiences in Singapore are reachable through LinkedIn marketing and through a content engine that most corporate sites never build. If you are investing six figures in SGD terms in a site, the distribution plan deserves more than a launch announcement. Our overview of how a performance marketing agency in Singapore approaches measurement is a reasonable starting point for framing that.
Field Notes
Across the enterprise and multi market builds we have been involved with, the number that surprises clients most is this: on projects with more than six approvers, waiting for approval accounted for between 30 and 40 per cent of total elapsed project time. Not doing work. Waiting for someone to say yes.
Second number: IT security review took an average of just under three weeks from questionnaire issued to clearance, and in every case where it was requested in the final month it became the critical path.
Third: of the corporate sites we have audited with more than 200 pages, the proportion of pages receiving fewer than ten organic visits in a year has typically sat above half. Large corporate sites are not usually under built. They are over built and under maintained.
Getting the structure right before the build starts
If you take one thing from this, make it the sequence. Stakeholder map, then approval model, then requirements, then platform, then design. Most corporate projects run that list backwards, choosing a platform and an agency before anyone has written down who decides.
The organisations that get this right are not the ones with the biggest budgets. They are the ones where a single person has genuine authority and a calendar cleared enough to use it.
We handle corporate builds through our website design practice, with the interface layer and design system work sitting under UI and UX design and the surrounding strategy under digital marketing and content marketing. If you want to know how we work before you talk scope, our about page is the honest version. When you are ready to map the stakeholders properly, start a conversation.
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.
