How one team at HEINEKEN is scaling app development worldwide
Your first OutSystems apps delivered real business value, and now the portfolio is growing. More teams, more apps and AI agents, more ambition. That's exactly where you want to be.
But at a certain point, something counterintuitive happens. The more people you add, the slower things seem to move. Decisions take longer. Work gets duplicated. Standards start to drift. This is what happens when organizational complexity outgrows the structure supporting it. The good news is it's entirely solvable. Here's how.
The problem: Why "more" usually means "slower"
When the backlog grows, the natural instinct is to add another team. But adding headcount without changing the structure multiplies your coordination cost without multiplying your output.
Think about what this looks like in practice. Three teams each build their own connector to the organization's CRM because there's no shared catalogue and no one to ask. A senior developer spends two weeks on an integration that another team finished last quarter. A new app ships with a completely different UX pattern because there was no style guide to reference. And without guidelines on how teams should integrate across boundaries, the default tends to be tight coupling. There are direct dependencies that feel convenient to build but are expensive to maintain. When one team changes an internal service, they have no way of knowing how many other teams just broke. This might appear to be a communication issue, but it’s actually an architectural one.
Each of these is a symptom of the same problem. You're scaling people without scaling the system those people work in.
Build a factory, not a crowd
The structural shift you must make to change everything is simpler than it sounds. You create a collection of teams to manage and a center of excellence (CoE) and start running a software factory. That means drawing a clear line between two types of work.
Your delivery teams focus on building and maintaining the apps the business needs. They're aligned to domains like finance, operations, customer experience, and their job is to ship. Your CoE, by contrast, doesn't own a product roadmap. It owns the foundation that makes shipping fast and consistent for everyone else. This includes reusable components, shared standards, pipeline, and the guardrails including the Agent Guardrails.
Without this separation, your best engineers end up as full-time firefighters. They’re pulled into every hard problem across every team, never able to create the kind of leverage that actually scales an organization.
A clean diagram showing a central CoE "Engine" providing tools, components and standards to multiple surrounding Delivery Teams.
Turn your experts into force multipliers
It's tempting to assign your best architect to your hardest project. Resist that instinct. Embedding a senior expert in one delivery team locks their knowledge in one place; however, it’s far more valuable when it reaches all your teams.
When you move that person into the CoE, their role changes fundamentally. They're no longer measured by the code they write but by the capability they build across the organization. In practice, that means:
- Owning a centralized UI style guide that teams reference
- Defining a shared services core for common integrations like authentication, notifications, and audit logging
- Running architectural reviews before problems ship to production
- Maintaining a CI/CD pipeline where quality gates run automatically.
One great architect multiplied across ten teams consistently outperforms one great architect on one team.
Pick the model that fits your organization
There's no single right way to structure a CoE. That’s because the model has to fit how your organization makes decisions. Three patterns come up consistently in practice.
A centralized CoE works well in regulated industries where consistency isn't optional, such as financial services, healthcare, and the public sector. The CoE sets the standards and the teams operate within them. A decentralized model suits smaller or highly autonomous organizations, where the CoE functions more as an internal consultancy and coordination layer than a governing body.
For most enterprises, the federated model, or hub and spoke, tends to hit the right balance. Governance and architecture standards live at the center, and domain expertise is embedded within the business units. The hub defines the guardrails, and the spokes adapt to them. If you're not sure where to start, this is usually the right option.
A capability framework to guide the journey
Standing up a CoE is a journey, not a project. The organizations that do it well tend to focus on four capability areas, treating them as a maturity progression rather than a checklist to complete in sequence.
Development productivity comes first: establishing the shared components, coding standards, and pipeline automation that let teams move quickly without accumulating technical debt. From there, the focus shifts to time to value, compressing the distance between a business idea and a working feature in production. As the factory matures, reliability becomes the priority: ensuring that growth doesn't come at the cost of security, resilience, or compliance. And running through all of it is adoption experience because the tools and patterns the CoE provides need to be good enough for teams to want to use them. If they work around them, you should go back to the drawing board.
A "Maturity Map" graphic showing a progression from initial CoE setup through to automated and optimized governance.
The takeaway: Scale the system, not just the headcount
Organizations that scale invest early in the system those people work within, including the standards, shared components, governance model, and culture of reuse.
A CoE is how you make that investment concrete. Stop asking "how many more developers do we need?" and start asking "how do we build a system where any number of developers can succeed?" Recast your experts as coaches, choose the model that fits your organization, and build toward it deliberately. That's how a collection of teams becomes a software factory.
Ready to see these principles in action? Don't miss this exclusive session where an OutSystems customer reveals the tangible impact of their CoE journey. Watch the session here.
