Engineering velocity is the product of what you own, what you automate, and where you borrow leverage. Together, these three levers let you peel away the hidden drags in your system; the parts you build by hand, maintain endlessly, or reinvent for every spike.
But drag looks different in every team.
Sometimes it shows up as coordination overhead. Other times, it’s operational load, slow infra sprawl, or tools that require constant babysitting. Before teams feel the pain through missed deadlines or budget pressure, it’s already baked into the way they work.
So, how do we handle different kinds of internal drag? Let’s take a closer look.
ClearBank: scaling payments by reducing coordination overhead
What was getting in the way?
As ClearBank’s transaction volume grew from 8,000 to 20 million per month, its delivery pipeline risked becoming the bottleneck. Compliance and uptime expectations were non-negotiable, but too much of the system required tight coordination between teams to evolve safely.
What they changed
ClearBank focused on simplifying how teams shipped software. They broke the system into smaller pieces that could be worked on independently, and each team had more control over its service’s lifecycle, from development to deployment.
They also standardized how infrastructure was deployed and monitored so changes could be made safely without requiring cross-team handoffs. Managed cloud tools handled routing, databases, and system health, so the core team didn’t have to.
Together, these shifts reduced delays between teams and made releases faster, more frequent, and less risky.
How to apply this
- Spot your coordination bottlenecks: Look where delivery slows down; cross-team changes, high-risk releases, or shared infrastructure. These are the places where autonomy will create the most momentum.
- Automate where mistakes happen: If you’ve had to fix the same manual deployment or rollback more than once, it’s worth automating even if it’s just a script and a checklist.
- Pick one monitoring view that matters: Aim for consistent visibility instead of perfect observability. One shared dashboard is better than five disjointed tools.
Stay updated with Simform’s weekly insights.
SparePartsNow: A 3 person team and a growing marketplace
What was getting in the way?
SparePartsNow is a B2B platform for industrial parts. They had a catalog growing from thousands to tens of thousands of SKUs and a growing supplier network. But the engineering team stayed at three people. Integrations were becoming more complex, and operational overhead risked overtaking delivery.
What they changed
SparePartsNow intentionally kept its architecture simple. Instead of building out a traditional backend, it set up each workflow, from catalog updates to order processing, as a small, self-contained function that ran only when needed.
Their web platform could automatically scale to handle demand without anyone manually managing servers. Onboarding a new supplier was as easy as updating a shared configuration; no system redeployments were required.
For search and other standard capabilities, they plugged in off-the-shelf tools in their cloud platform, avoiding the complexity of custom builds.
How to apply this
- Design for not being there: Ask, “Could this system run for a week without us touching it?” Build towards that, especially for repeatable workflows like onboarding or syncing.
- Start with a lightweight integration template: Use the same basic intake process for every new partner or dataset. What fields matter? What breaks often? Standardize that before you scale it.
- Test the easy option first: Try the managed service version before building something new. Before thinking about locking-in, learn what not to build.
Gorgias: Staying lean while preparing for 10X growth
Most teams reduce complexity by breaking things apart. But sometimes, like in Gorgias’s case, the smarter move is to consolidate.
When infrastructure sprawl and tool overhead are the issues, pulling systems together can make them easier to operate.
What was getting in the way?
Gorgias was serving more ecommerce brands than ever, but infrastructure costs were climbing fast, particularly around database services. Their architecture couldn’t scale usage without scaling cost.
What they changed
Gorgias simplified the way it ran its platform. Instead of managing separate systems and infrastructure components, it brought everything into a single environment that scaled with its needs.
They streamlined the release of new features and the monitoring of infrastructure, reducing setup time and support load.
By relying on their cloud provider’s managed services, the team avoided the need to build and maintain dedicated internal tools and stayed focused on building their product.
How to apply this
- Simplify before you optimize: If infra feels complicated, it probably is. Reduce moving parts before you start tuning performance or cost.
- Limit your maintenance overhead by asking, “Do we still need this?” every quarter for environments, tools, and processes.
- Write things down while they still work: If a system has been stable for months, that’s the perfect time to document how it runs, so you won’t have to rebuild it during an outage.
In every case, they scaled by needing to do less.
When systems are designed to stay out of the way, teams don’t have to scale just to keep up. They get to scale by building momentum.
PS: If you missed the edition on architectural decisions that most affect velocity, cost, and coordination overhead, check it out here.
