Contents
SwiftCase has been running in production for 15 years. Not a rewrite of something older - the same codebase, evolved continuously, serving real businesses every day.
That's unusual in our industry. Most software either gets rewritten or abandoned within a decade. Here's what we learned about building systems that last.
Boring Technology Wins
In 2011, we chose PHP and MariaDB. Not exciting choices then, not exciting now. They've served us well.
We've processed 11.8 million cases on this foundation. No "we need to rewrite in [hot new language]" conversations. The technology is boring, and that's a feature.
Why Boring Works
- Stability: Boring technology has known failure modes. Exciting technology has unknown failure modes.
- Hiring: More developers know boring technology. Hiring for exotic stacks is hard and expensive.
- Documentation: Boring technology has years of Stack Overflow answers and blog posts.
- Ecosystem: Boring technology has mature libraries for everything you need.
We've added exciting technology where it matters - TypeScript for Switchboard, modern AI providers - but the core remains intentionally boring.
Refactor Continuously, Rewrite Never
Our codebase looks nothing like it did in 2011. Every part has been refactored, often multiple times. But we've never done a ground-up rewrite.
Rewrites are seductive. "If we just started fresh, we could do it right this time." In practice:
- You lose years of bug fixes and edge case handling
- The new system has its own bugs that take years to find
- You're maintaining two systems during the transition
- Rewrites almost always take longer and cost more than expected
Instead, we refactor continuously:
- Replace components one at a time
- Keep the system working throughout
- Spread the risk across many small changes
It's less exciting but far more reliable.
Technical Debt Is Real (And That's OK)
Every codebase has technical debt. Pretending otherwise is delusional.
The question isn't whether to have debt - it's how to manage it:
Intentional vs. Accidental
Intentional debt: "We know this isn't ideal, but we're shipping it this way for good reasons. Here's the ticket to fix it later."
Accidental debt: "Wait, why does this work this way? Who wrote this?"
Intentional debt is fine. Accidental debt is dangerous.
Pay Interest, Not Principal
You don't have to pay off all debt immediately. Sometimes the right move is to pay interest - work around the debt - while focusing on more important things.
What matters is that you're aware of the debt and making conscious decisions about it.
Debt Has a Location
Not all debt is equal. Debt in a core system that's touched daily is expensive. Debt in a rarely-used feature might not matter.
We track where debt lives and prioritise accordingly.
Tests Are Documentation
We have tests. Not because someone mandated coverage metrics, but because tests serve a purpose: documenting behaviour.
When you come to code you haven't touched in two years, the tests tell you:
- What the code is supposed to do
- What edge cases matter
- What will break if you change things
Tests as documentation is more valuable than tests as verification. If your tests just verify that code runs, they're not helping much. If they document behaviour, they're invaluable.
Monitoring Is Not Optional
In year one, monitoring felt like overhead. By year five, it was obvious: you cannot run production systems without observability.
We monitor:
- Application metrics: Request rates, error rates, latency
- Business metrics: Cases processed, workflows completed
- Infrastructure metrics: CPU, memory, database performance
- Synthetic checks: External probes of critical endpoints
When something goes wrong - and things always go wrong - monitoring tells us:
- That something is wrong
- What is wrong
- When it started
- Where in the system the problem is
Without monitoring, you're debugging blind.
Simple Beats Clever
Clever code is hard to understand. Hard-to-understand code is hard to maintain. Hard-to-maintain code becomes nobody's code.
We've learned to favour:
- Explicit over implicit: Clear code over magical frameworks
- Obvious over elegant: Readable over impressive
- Standard over custom: Use existing solutions before building your own
The cleverness that felt satisfying to write becomes a burden six months later when someone else (or you, having forgotten) needs to modify it.
People Matter More Than Process
We've tried various processes over the years. Scrum, Kanban, various hybrids. What we've learned: the specific process matters less than:
- Clear ownership: Someone is responsible for each thing
- Fast feedback: Know quickly when something is wrong
- Psychological safety: People can admit mistakes and ask questions
- Sustainable pace: Sprints that don't burn people out
A mediocre process with good people works. A perfect process with burned-out people doesn't.
The System Includes Humans
Software doesn't exist in isolation. It's part of a system that includes:
- Users who need to understand it
- Support staff who need to troubleshoot it
- Operators who need to deploy it
- Developers who need to maintain it
Design for all of them, not just end users.
This means:
- Good error messages: "Something went wrong" helps no one
- Audit trails: What happened and why
- Operational tools: Easy deployment, rollback, debugging
- Documentation: Not just API docs, but operational runbooks
What We'd Do Differently
Fifteen years of hindsight reveals some things we'd change:
- Start with better data modelling: Early schema decisions haunt you forever
- Invest in CI/CD earlier: We automated deployment later than we should have
- Write more integration tests, fewer unit tests: Unit tests of implementation details broke constantly during refactoring
- Document architecture decisions: Tribal knowledge doesn't scale
But honestly? Most of our major decisions were right. Boring technology, continuous refactoring, sustainable pace, good people - these principles work.
Looking Forward
SwiftCase will keep evolving. We're adding AI capabilities, modernising the frontend, expanding integrations. The codebase in 2030 will look different from today.
But the principles that got us here - boring technology, continuous improvement, sustainable practices - will guide what comes next.
Want to help build the next 15 years?
We're looking for engineers who want to build software that lasts. Not throwaway prototypes - real systems that serve real businesses for years.