Architecture & Scaling
System architecture design and implementation for growing organisations. From planning scalable infrastructure to executing migrations that support your business growth.
When Architecture Becomes the Bottleneck
Most software starts simple, and rightly so. A monolithic application, a single database, a straightforward deployment. For the first year or two, this works well. The problems tend to arrive when the business grows faster than the architecture was designed to support - more customers, more data, more concurrent users, more integrations with external systems. The platform that served you well in the early days starts to resist change, and the development team spends more time working around limitations than building new capability.
The symptoms are familiar: slow response times that frustrate users, deployments that require downtime, a codebase where changing one thing breaks something seemingly unrelated, and a growing sense among the development team that they're fighting the architecture rather than building on top of it. These aren't failures of the original design - they're signs that the business has outgrown it, which is a good problem to have if it's addressed properly.
What I Do
My approach starts with understanding what you have and where you need to get to. That means auditing the current architecture - not just the code, but the infrastructure, the data model, the deployment pipeline, and the team's capacity to absorb change. It also means understanding the business context: what growth looks like over the next twelve to twenty-four months, what new capabilities the platform needs to support, and what constraints exist around budget, timeline, and risk tolerance.
From there, I design a target architecture and - critically - the migration path to get there. The target state matters, but the path matters more. A beautifully designed architecture is worthless if the migration plan requires six months of downtime or a complete rewrite that the team can't deliver. The skill is in finding the route that moves you forward without breaking what's already working.
Common Patterns
The specific architectural changes depend on the situation, but there are patterns I work with regularly:
Multi-tenancy is often the first requirement when a platform needs to serve multiple independent organisations. Getting this right at the data layer - secure isolation, per-tenant configuration, shared infrastructure without shared risk - is foundational work that affects everything built on top of it.
Role-based access control becomes essential as platforms mature. Simple authentication gives way to granular permissions, and the access model needs to reflect the real-world relationships between organisations, teams, and individuals using the system.
API design matters increasingly as platforms grow. Internal services need clean interfaces between them, external integrations need stable, versioned APIs, and the authentication model (OAuth2, client credentials, API keys) needs to be consistent and secure.
Queue-based architecture helps decouple time-sensitive operations from background processing. When a user action triggers a chain of events - notifications, data synchronisation, report generation - handling these asynchronously improves both performance and reliability.
I'm pragmatic about these patterns. Not every system needs microservices. Not every platform needs event-driven architecture. The right answer depends on the problem, the team, and the business - not on what's fashionable in conference talks.
Where I've Done This
The clearest example is MedAscend, a healthcare and education platform that had reached the limits of its initial MVP architecture. The core product worked, but it was single-tenant, lacked granular access control, and had no enterprise integration capabilities. Institutional clients - universities and clinical bodies - required all three before they would commit to contracts.
I re-architected the platform for multi-tenancy, implemented OAuth2-based SSO and RBAC, and designed the API layer to support the integrations these clients expected. The work was done while the platform remained live for existing users, which meant careful planning, phased rollout, and a clear rollback path at every stage. The result was a platform that could pursue - and win - the institutional contracts that the business needed to grow.
At SUMAC, I led a complete platform rewrite over several years, modernising the stack from the ground up while maintaining 100% customer retention throughout the transition. That experience taught me that the hardest part of architectural change isn't the design - it's managing the migration without losing the trust of the people who depend on the system every day.
If your platform is showing signs of outgrowing its architecture, I can help you plan and execute the changes needed to support the next stage of growth. Get in touch.