How we build software that survives its first developer

The real test of software is not launch day. It is the day the person who wrote it is no longer available, and someone new has to change it without breaking anything. Plenty of business software fails that test: it works, but nobody dares to touch it.

These are the principles we apply on every project, including our own products, so that the software stays changeable after we hand it over.

1. Tests come first

We write an automated test before the code that makes it pass. This is test-driven development, and it does three things:

• every behaviour the business depends on is written down as an executable check
• the code ends up designed for testing, which in practice means small, decoupled pieces
• the next developer can change things and know within minutes whether something broke

We test what matters most: business rules, money, permissions and anything that talks to another system. A test suite that runs automatically on every change is the most valuable documentation a project can have, because it cannot go out of date without someone noticing.

2. Business rules live apart from the framework

Frameworks, databases and payment providers change. Business rules change for different reasons. We keep them apart: rules live in plain code that knows nothing about HTTP, SQL or a vendor's SDK. The parts that deal with the outside world sit at the edges and depend on the rules, never the other way round.

This is often called clean architecture. The practical benefit is simple. When you switch payment provider, upgrade the framework or move the database, the rules and their tests stay untouched.

3. Every API has an explicit contract

Integrations break when one side changes what it sends and the other side finds out in production. So every API we build is described in an OpenAPI specification, requests and responses are validated against it, and automated tests check that the real implementation matches the spec.

When something must change, the contract changes first, visibly, in the same change as the code. Clients and partners see what changed and when.

4. Boring technology

We choose proven tools with large communities: Go, PHP, TypeScript and React, MySQL or PostgreSQL, Docker. New technology is used only where it solves a real problem better. Boring tools are easier to hire for, have answers to their problems online, and are still supported in five years.

The same goes for code style: plain and explicit beats clever. Code is read far more often than it is written.

5. Decisions are written down

Some things cannot be seen in the code: why a design was chosen, which alternative was rejected, what trade-off was accepted. We record important decisions in short notes next to the code. A new developer then understands why the system looks the way it does before trying to "fix" it.

6. Changes are small and automated

Every change goes through version control, code review and an automated pipeline that runs the tests and builds the release. Releases are small and frequent, because a small change is easy to review, easy to test and easy to roll back. Database changes are versioned migrations, never manual edits on a server.

7. Production is observable

Software that runs without anyone knowing what it does is a liability. We log what matters, keep audit trails for important changes, and alert a person when something fails. In our own licence server, for example, every licence lifecycle change writes an audit record, so any question about a customer's licence can be answered from data rather than memory.

What this means for you

These principles cost a little more at the start of a project. They pay back the first time something needs to change quickly, the first time a new developer joins, and the day you decide to move the work to another team. You own the code, and any competent developer can continue it.

If you have software that already fails this test, a technical code audit is the place to start. Our technical consulting service also helps teams adopt these practices on their own projects.