A scalable platform is one that can absorb useful change without becoming fragile. That depends on more than server capacity: clear boundaries, maintainable content, dependable integrations and an operating model all matter.
The clearest way to judge a platform is not how it performs under load. It is how much a modest change costs. If adding a new product category, a new region or a new integration takes three months and makes everyone nervous, the platform has stopped being an asset — regardless of how well it handles traffic.
DORA's research programme has been measuring that cost for over a decade. In its 2025 study, only around 16% of organisations deployed on demand, roughly 24% deployed less than once a month, and about 44% took more than a week to move a commit into production (DORA / Google Cloud, 2025). Those numbers describe the real ceiling on how fast most organisations can learn.
This article sets out the choices that keep that cost low. They inform how we approach custom development and platform work.
Separate capabilities cleanly
Structure the platform around stable business capabilities rather than temporary campaign requirements. Clear boundaries reduce unintended side effects and make ownership easier to understand.
The test for a good boundary is durability. "Customer identity", "pricing", "order fulfilment" and "content publishing" are things your business will still be doing in five years. "Spring campaign landing pages" is not. When temporary requirements get baked into the structure, every subsequent change has to navigate around them.
Two symptoms suggest boundaries have gone wrong:
- Changes cluster. A change in one area routinely requires coordinated changes in three others.
- Nobody owns anything cleanly. Asking "who is responsible for this behaviour?" produces a meeting rather than a name.
Clean boundaries are also what make incremental replacement possible. Platforms rarely get rebuilt wholesale on a sensible budget; they get replaced a capability at a time. That only works if the capabilities are separable in the first place.
Choose boring technology where it helps
Proven tools often deliver more value than fashionable complexity. Select technology according to team capability, support needs, integration constraints and the pace of expected change.
Dan McKinley's essay on this remains the most useful framing available. His argument is that every organisation has a small, fixed budget of what he calls innovation tokens. Each unfamiliar technology you adopt spends one. Established tools are valuable not because they are better in the abstract but because their capabilities and their failure modes are well understood — with newer technology, the scale of the unknown unknowns is much larger (Dan McKinley, *Choose Boring Technology*).
The practical version of this: spend your innovation tokens on the thing that differentiates your business, and be deliberately unadventurous everywhere else. A logistics company should be innovating in routing and scheduling, not in its choice of database.
This is why we do not default to a single stack. Content-led sites are often best served by WordPress and a well-structured editorial setup; complex applications may warrant React, Node.js or something else entirely. The right question is not which technology is most capable, but which one your team — and the people who will maintain it in three years — can operate confidently.
Treat content and data as products
Define models, ownership and quality rules early. Consistent structured content improves reuse and search, while clear data contracts make integrations more reliable.
A content model is a design artefact, not a CMS configuration detail. It determines whether a product description can be reused across the website, a mobile app, a marketplace feed and a PDF datasheet — or whether each of those requires someone to copy and paste, with predictable drift.
The same discipline applies to data crossing system boundaries. An explicit contract — what fields, what types, what happens when a value is missing, what changes are allowed without notice — converts a fragile integration into a maintainable one. Integrations most often break not because a system went down but because someone changed a field's meaning without telling anyone.
Structured content has become more valuable, not less, as search and AI-assisted retrieval have changed. Well-modelled content is easier for machines to interpret accurately. Content held as unstructured blobs of formatted text is not, and it degrades as soon as anyone needs it in a second context. This is a core part of how we approach web development.
Automate quality and delivery
Testing, code review, monitoring and repeatable deployment reduce the cost of every future release. Performance, security and accessibility should be continuously visible rather than checked once before launch.
The case for this has strengthened considerably. DORA's 2025 research, drawn from nearly 5,000 technology professionals, found that AI adoption raised throughput but also correlated with higher instability, more rework and slower recovery — the pattern of a tool that amplifies whatever system it lands in. Teams with solid testing, review and feedback loops got faster; teams without them accumulated problems faster (DORA / Google Cloud, 2025).
If code is being generated more quickly than before, the downstream capacity to verify it becomes the binding constraint. Automation of quality is no longer a maturity nicety.
Making non-functional qualities continuously visible matters for the same reason. Performance is a commercial variable: case studies published through Google's web.dev programme link Core Web Vitals improvements to measurable revenue outcomes — Rakuten 24 reported a 33% conversion increase and 53% higher revenue per visitor, Vodafone around 8% more sales after a 31% LCP improvement, redBus a 7% sales increase from responsiveness work. Accessibility behaves the same way: WebAIM's 2026 scan found detectable WCAG failures on 95.9% of the top million home pages, with error counts rising 10% year on year as pages grew more complex (WebAIM Million, 2026). Both are regressions that happen quietly unless something is watching.
A workable baseline:
- Automated tests covering the journeys that generate revenue
- Performance budgets enforced in the pipeline, not reviewed after launch
- Accessibility checks in CI, plus manual keyboard and screen reader testing on key flows
- Dependency and vulnerability scanning on a schedule
- Alerting on real-user metrics, not just server health
Plan for the people operating it
Documentation, permissions, editorial workflows and support processes are part of architecture. A technically elegant platform still fails if teams cannot confidently run it.
This is the most frequently skipped item on the list and the most common cause of expensive platforms quietly reverting to manual processes. If publishing a new page requires a developer, the marketing team will find a workaround — usually a third-party tool that sits outside your design system, your analytics and your security model.
Questions worth answering before launch:
- Can a non-technical colleague make a routine change unsupervised? If not, what is the plan for the hundred routine changes a year?
- Do permissions match how the organisation actually works, including contractors, agencies and staff who change roles?
- What is the recovery procedure, and has anyone tested restoring from a backup rather than assuming it works?
- Who is on the other end of an alert at 2am, and do they have the access to act?
Documentation should be written for the person who joins in eighteen months, not for the team that already knows. That person is the actual test of whether the platform is maintainable.
What this looks like in practice
For Software Imaging, a global enterprise imaging and healthcare workflow specialist, the platform had to carry a substantial and growing body of case studies, technical content and sales collateral — which made the content model and editorial workflow the architectural decisions that mattered most. For Bridge Engineering, a large and specialised product catalogue meant the priority was giving the client direct, dependable control over products, stock and content without developer involvement.
Where to go next
- For platform architecture, integrations and bespoke systems, see custom development.
- For content models, performance and publishing workflow, see web development.
- If AI is on the roadmap, the foundations here largely determine the outcome — see where AI automation creates real value.
- For deciding what the platform is for in the first place, read from idea to scalable digital product.
Sources
- DORA / Google Cloud, State of AI-assisted Software Development (2025) — https://dora.dev/
- Dan McKinley, Choose Boring Technology — https://mcfunley.com/choose-boring-technology
- WebAIM, The WebAIM Million (2026) — https://webaim.org/projects/million/
- Google web.dev Core Web Vitals case studies — https://web.dev/case-studies
Useful digital work is a continuous loop: understand, design, build, learn and improve.