Let’s talk about a mire many engineering teams find themselves in: building too much too soon, or fixing just enough to get through the next sprint and then paying for it tenfold later. In the world of software development and SaaS, both over-engineering and technical debt are millstones that cause drag and frustration. Between them lies a pragmatic sweet spot that’s hard to land on, but absolutely worth aiming for, because getting it wrong costs money, agility, and ultimately product viability.
Perfect is the enemy of the good
At The Scale Factory, we talk a lot about pragmatic engineering. It’s one of our values. We know it’s a survival skill in the technical world, trading purity and completeness against delivery. Pragmatism is about effect and impact; delivering value rather than pursuing architectural nirvana for its own sake.
In practice, this means we apply our knowledge and experience appropriately, within cost and time constraints and based on the real tangible needs, problems, and vision of our customers. This is our good.
Good is not a convenient cop-out, an admission of imperfection; it’s a strategic choice. Building the perfect system that never launches helps no one. Spiking and prototyping to learn, failing fast, staying focused on customer outcomes, and minimising yak-shaving are what keep teams moving forward.
As far as the East is from the West
A merism is a rhetorical device where something is described by its contrasting extremes or parts. In this case over-engineering and technical debt are extremes that often cause the same pain.
Both increase development and maintenance costs. The former because of code complexity, the latter because of the decreased quality. These costs come, in part, from a slower development cycle, which in turn reduces your ability to get return on investment. This leads to slower time to market and a general lowering of quality either through bugs and fragility or unnecessary features.
In an organisation with competing pressures and goals, how can you navigate what the pragmatic middle-way is?
All the things
Prioritise Ruthlessly. Use frameworks like an impact versus effort matrix: Ship quick wins fast. Plan for high-impact, high-effort changes. Or frame your backlog through risk-based scoring: What’s affecting your customers, your developers, or your business risk? Use Pareto, MoSCoW or Kano. Choose a rubric that works for you and constantly and consistently view the backlog of work through it.
Ensure that technical debt is scored alongside feature work. Bugs in critical flows matter more than that pet feature someone promised a stakeholder. You could make tech debt part of your definition of done. Perhaps dedicate sprint time to debt reduction or run regular “clean-up” sprints. Do what fits your cadence, but make it part of the process, not a one-off.
Without data, you’re just another person with an opinion
Track both speed and quality. What is your time to market, cycle time, throughput? Can you talk about defect rates, code churn, and complexity to articulate stability and maintainability? How are you measuring whether users actually like what you’re building?
These metrics help translate engineering health into business impact. This becomes crucial when arguing for time to refactor that 2,000-line utilities file.
Culture eats strategy for breakfast
This is the hard bit, but it’s also the crucial bit. It’s about communication, trust, and leadership. Teams measuring and prioritising is worthless without an organisation that supports the outcomes from those actions. Engineers need to feel safe calling out brittle code. Product managers need to value maintenance as much as new features. Leadership needs to back these priorities with time, budget, and clarity.
Pragmatism is intentional compromise. Knowing what that means in both the long and short term, having everyone bought into the decisions and the trade-offs is key. Pragmatism can only really work if it is done in the open, with the choices agreed and held to by all parties and teams.
In addition to this open culture add further positive behaviours. Celebrate big feature releases as well as the small wins: Removing a flaky test, cleaning up a gnarly dependency, simplifying a deploy step. These things matter. Over time, they create the conditions for fast, sustainable delivery. Develop a team of boy scouts that touch legacy code and leave it better than they found it. Foster a culture of belonging.
Relentless progress over perfection
Perfection is expensive. So is a codebase you’re too afraid to touch. Pragmatism lives in the middle. It means building only what you need, when you need it, and staying flexible enough to change course when reality hits.
Whether you’re leading a team or scaling a SaaS platform, the path to long-term success is paved not with theoretical best practices, but with well-informed compromises. Make them consciously. Make them visible. And above all make sure that you’re always moving forward.
We’ve been an AWS SaaS Services Competency Partner since 2020. If you’re building SaaS on AWS, why not book a free health check to find out what the 2023 SaaS SI Partner of the Year can do for you?
This blog is written exclusively by The Scale Factory team. We do not accept external contributions.
