--- type: Leaf title: Platform Engineering Anti Patterns description: Common platform engineering anti-patterns Australian teams hit, and how to build internal platforms engineers actually adopt. Book a review. resource: https://nationaldigital.com.au/platform-engineering/real-time-systems/platform-engineering-anti-patterns/ tags: - platform-engineering - Platform Engineering - Cloud Engineering - DevOps and SRE Practice - System Integration - platform engineering anti-patterns - internal developer platform - devops vs platform engineering - platform engineering vs sre - legacy system modernisation - api development - application modernisation timestamp: '2026-09-01T08:25:48.864Z' language: en-AU publisher: National Digital author: Cameron Young authorRole: CEO readingTimeMinutes: 9 wordCount: 1719 datePublished: '2026-09-01' dateModified: '2026-09-01' pillar: platform_engineering canonical: https://nationaldigital.com.au/platform-engineering/real-time-systems/platform-engineering-anti-patterns/ --- _Home — Platform Engineering — Real-time systems — Platform Engineering Anti Patterns_ # Platform Engineering Anti Patterns Common platform engineering anti-patterns Australian teams hit, and how to build internal platforms engineers actually adopt. Book a review. **Quick answer:** Platform engineering fails most often through tool-first builds, isolated platform teams and infrastructure sized for scale not yet reached; treat it as a product with proven demand. ## About this page - Written by Cameron Young, CEO - 9 min read - Updated 1 September 2026 _Platform Engineering — Cloud Engineering — DevOps and SRE Practice — System Integration_ ## What are the most common platform engineering anti-patterns? The recurring failures are building platform tooling before proving developer demand, running an isolated platform team with no feedback loop, and over-engineering infrastructure for scale the business hasn't reached yet. **Additional Context** These patterns show up repeatedly in internal developer platform initiatives regardless of company size, and each one is preventable with a product-led, demand-driven approach to platform work. _High confidence · Verified 31 Aug 2026_ *Platform Engineering Fundamentals* ## What platform engineering actually means Platform engineering is the discipline of building an internal developer platform: a self-service layer of infrastructure, tooling and golden paths that lets application teams provision environments, deploy services and observe production without raising a ticket for every step. Done well, it reduces cognitive load on product teams and gives a small platform group leverage across many applications. Done badly, it becomes an expensive layer nobody actually uses. The term is often used loosely. DevOps describes a culture of shared responsibility between development and operations; site reliability engineering (SRE) applies software engineering discipline to operational reliability targets; platform engineering is the productisation of both, packaged as an internal platform with its own users, roadmap and adoption metrics. Confusing the three is itself an early anti-pattern: a platform team that behaves like a ticket-taking operations function, rather than a product team serving internal customers, rarely gets adopted voluntarily. ## The anti-patterns worth avoiding The following patterns show up repeatedly across growing Australian businesses building their first internal platform, regardless of industry or team size. ### Building the tooling before proving the demand The most common failure mode starts with a tool rather than a problem: a team stands up a new CI/CD platform, service mesh or internal PaaS because it appeared on a conference agenda, not because engineers asked for it. A related version of this shows up in real-time infrastructure decisions, where teams reach for [Message queuing best practices for Australian timezone synchronisation](/platform-engineering/real-time-systems/message-queuing) or build custom [How to implement socket connections for Australian timezone synchronisation](/platform-engineering/real-time-systems/socket-connections) before confirming the business actually needs sub-second delivery rather than a periodic sync job. ### Running an ivory-tower platform team Platform teams that sit apart from the engineers they serve, with no shared roadmap review or usage feedback, tend to build for their own assumptions rather than observed friction. The fix is structural: treat application teams as customers, measure adoption, and let unused capability get deprecated rather than defended. ### Over-engineering for scale that hasn't arrived Architecture sized for the traffic a business hopes to have in five years adds real operating cost and cognitive load today. Multi-region failover, complex service meshes and elaborate autoscaling policies are appropriate once load genuinely demands them, not before. The right-sized approach is to build for the scale the organisation is actually approaching, with a credible path beyond it. *Platform Strategy* ## Avoiding Platform Engineering Anti-Patterns **Problem:** Many platform engineering initiatives stall because teams build infrastructure before validating developer demand, run platform work as an isolated operations function, or size systems for growth the business hasn't reached, leaving expensive tooling with low adoption and duplicated effort. **Business Impact** - Time Wasted: Engineering time spent maintaining platform capability few teams actually use - Cost Implication: Ongoing cloud and tooling spend that outpaces the value the platform delivers - Opportunity Cost: Developer time diverted from product work to route around a platform that doesn't fit how teams actually build software **Solution:** Treat the platform as a product: validate demand with real engineering teams, ship a small usable core before broad rollout, and expand capability only as usage and scale genuinely require it. **Our Approach** 1. **Audit current developer pain points** _(Typically the first few weeks)_: Interview the application teams who would use the platform to confirm which manual steps actually cost them time, rather than assuming 2. **Ship a minimal, adopted core** _(Following phase, iterative)_: Build the smallest self-service capability that removes a real bottleneck, then measure voluntary adoption before adding further scope **Expected Outcome:** A platform that engineering teams choose to use because it removes real friction, rather than one mandated from above with low uptake. *Key Takeaways* ## What to Get Right in Platform Engineering Platform engineering succeeds when it is run as an internal product with proven demand, clear ownership separate from DevOps and SRE, and infrastructure scaled to real, not imagined, growth. - **Treat the platform as a product with real users, not a mandate** Platform teams that measure adoption and gather feedback from application engineers build capability people actually choose to use, rather than tooling that gets bypassed. _Critical_ - **Separate platform engineering from DevOps culture and SRE reliability targets** DevOps is a way of working, SRE sets reliability objectives, and platform engineering packages both into a usable internal product; conflating the three creates confused ownership. _Important_ - **Match infrastructure investment to the scale the business is actually approaching** Building for hypothetical future load before it exists adds ongoing operating cost and complexity that the current team then has to maintain indefinitely. _Important_ - **Keep legacy systems in the architecture where they still do the job** Integrating existing platforms is usually faster and less risky than a full rebuild, and it preserves institutional knowledge the business depends on. _Important_ ## Why Platform Foundations Matter Platform engineering decisions sit on top of broader shifts in how Australian businesses use cloud infrastructure and manage operational risk, which shape what a sensible internal platform actually needs to cover. - **Cloud computing adoption among Australian businesses: 55%** _Significance: medium_ — More than half of Australian businesses reported using paid cloud computing services, meaning most platform engineering work now sits on top of existing cloud footprint rather than a greenfield environment. _(Source: ABS Characteristics of Australian Business 2019-20 (https://www.abs.gov.au/statistics/industry/technology-and-innovation/characteristics-australian-business/2019-20))_ - **Business-reported internet service adequacy: over 91%** _Significance: low_ — Most Australian businesses report their internet connection meets most or all of their needs, meaning platform reliability work should focus on internal system design rather than assuming connectivity is the bottleneck. _(Source: ABS Characteristics of Australian Business 2024-25 (https://www.abs.gov.au/statistics/industry/technology-and-innovation/characteristics-australian-business/latest-release))_ - **Data breaches caused by human error: 37%** _Significance: high_ — More than a third of notified Australian data breaches stem from human error rather than external attack, underscoring why self-service platform guardrails matter as much as raw automation. _(Source: OAIC Notifiable Data Breaches Report January-June 2025 (https://www.oaic.gov.au/news/blog/latest-notifiable-data-breach-statistics-for-january-to-june-2025))_ **Methodology:** Figures are drawn from published Australian Bureau of Statistics business technology surveys and the Office of the Australian Information Commissioner's Notifiable Data Breaches series, cited to their original releases. *Beyond the Platform Team* ## Where platform work fits alongside integration and modernisation Internal platform engineering is one part of a wider systems layer that most growing Australian businesses eventually need attention on: integration between Xero, Shopify, HubSpot and bespoke line-of-business software, API development that exposes internal capability safely, and cloud engineering that keeps infrastructure operable by the team that owns it. A platform initiative that ignores these connections tends to solve the wrong problem first. Real-time capability is a common trigger for this wider work. A business that has outgrown polling-based integrations often needs [Server-sent events strategies for Australian timezone synchronisation](/platform-engineering/real-time-systems/server-sent-events) or a properly designed [Complete guide to notification systems in Australia](/platform-engineering/real-time-systems/notification-systems), but only once the underlying platform and API layer can support it reliably across states and time zones. ## Staged modernisation over big-bang rebuilds Existing systems are assets where they still serve the business, so a rip-and-replace of core platforms is a last resort rather than a default recommendation. Legacy system modernisation and application modernisation work best staged: decompose one bounded piece of functionality behind an API, prove it in production alongside the system it's replacing, then move to the next piece. This keeps the business trading while the underlying architecture changes. Infrastructure should also live in accounts and environments the client controls, rather than creating unnecessary lock-in to any single delivery partner. Combined with a maintainable architecture the internal team can actually operate day to day, that staged approach is what separates platform engineering that compounds in value from platform engineering that becomes another system to modernise in a few years. ## Ready to Pressure-Test Your Platform Engineering Roadmap? Book a working session to review current tooling, integration points and where a self-service platform would genuinely save engineering time, before committing further budget. - [Book a Platform Review](https://calendly.com/cameron-at-national-digital/discovery) - [Email Our Team](mailto:enquiries@nationaldigital.com.au) - Email: enquiries@nationaldigital.com.au - Phone: 1300 800 855 ## Platform Engineering Anti-Patterns: Common Questions ### What does platform engineering actually mean? Platform engineering is the practice of building an internal developer platform, a self-service layer of infrastructure, tooling and deployment paths that lets application teams provision, deploy and observe their own services without raising a ticket for every change. It borrows from DevOps culture and SRE reliability practice but packages both as a product with its own users and adoption metrics, rather than a purely operational function. ### How is platform engineering different from DevOps? DevOps describes a culture of shared responsibility between development and operations teams, focused on collaboration and continuous delivery. Platform engineering is more concrete: a dedicated team builds and operates a self-service platform that makes DevOps practices easy to follow by default, through templates, golden paths and automated guardrails, rather than relying on every team learning operations skills from scratch. ### Where does site reliability engineering fit alongside platform engineering? SRE applies software engineering discipline to operational reliability, setting error budgets and service-level objectives and treating operations problems as engineering problems. Platform engineering often implements the guardrails SRE recommends, such as safe deployment defaults and observability baked into the platform, so reliability targets are met by default rather than enforced team by team. ### What's the clearest sign a platform engineering initiative is going wrong? Low voluntary adoption is the clearest signal. If application teams route around the platform, keep maintaining shadow infrastructure, or complain that self-service capability doesn't match how they actually build software, the underlying cause is usually that the platform was built for an assumed need rather than a validated one. ### How do we know if our business is ready to invest in platform engineering? Readiness usually shows up as recurring friction across multiple application teams: repeated manual environment setup, inconsistent deployment practices, or growing cloud costs nobody fully owns. If only one team has the problem, a shared library or better documentation is often enough; a dedicated internal platform tends to earn its cost once several teams hit the same wall independently. ### Which tools do platform engineering teams typically rely on, and do we need all of them? Common categories include infrastructure-as-code, container orchestration, CI/CD pipelines, service catalogues and observability platforms. Few growing businesses need every category from day one; the requirements-led approach is to identify the specific bottleneck an application team faces, choose the smallest tool that resolves it, and expand tooling only as genuine usage and scale justify the added operating complexity. ## Related reading - [How to implement socket connections for Australian timezone synchronisation](/platform-engineering/real-time-systems/socket-connections/) - [Server-sent events strategies for Australian timezone synchronisation](/platform-engineering/real-time-systems/server-sent-events/) - [Message queuing best practices for Australian timezone synchronisation](/platform-engineering/real-time-systems/message-queuing/) - [Real-time dashboards strategies for Australian timezone synchronisation](/platform-engineering/real-time-systems/real-time-dashboards/) - [Complete guide to notification systems in Australia](/platform-engineering/real-time-systems/notification-systems/) - [Legacy Application Modernisation](/platform-engineering/real-time-systems/legacy-application-modernisation/) ## Related **Parent:** - [Real-time systems](/okf/platform-engineering/real-time-systems.md) **Related:** - [How to implement socket connections for Australian timezone synchronisation](/okf/platform-engineering/real-time-systems/socket-connections.md) - [Server-sent events strategies for Australian timezone synchronisation](/okf/platform-engineering/real-time-systems/server-sent-events.md) - [Message queuing best practices for Australian timezone synchronisation](/okf/platform-engineering/real-time-systems/message-queuing.md) - [Real-time dashboards strategies for Australian timezone synchronisation](/okf/platform-engineering/real-time-systems/real-time-dashboards.md) - [Complete guide to notification systems in Australia](/okf/platform-engineering/real-time-systems/notification-systems.md) - [Legacy Application Modernisation](/okf/platform-engineering/real-time-systems/legacy-application-modernisation.md) - [Golden Path Platform Engineering](/okf/platform-engineering/real-time-systems/golden-path-platform-engineering.md) # Citations - [ABS Characteristics of Australian Business](https://www.abs.gov.au/statistics/industry/technology-and-innovation/characteristics-australian-business/2019-20) — Reports on cloud computing adoption among Australian businesses, relevant context for platform decisions built on top of existing cloud footprint. - [OAIC Notifiable Data Breaches Report January-June 2025](https://www.oaic.gov.au/news/blog/latest-notifiable-data-breach-statistics-for-january-to-june-2025) — Details the share of Australian data breaches caused by human error, relevant to why platform guardrails matter alongside automation.