The Tarmac 10, explained: how we de-risk delivery
Quality isn't a promise you make on a sales call. It's a process you can point to. Here's the set of engineering practices behind every Tarmac engagement.
Ask ten software firms about quality and you’ll get ten variations of “we care a lot.” That’s not a process. It’s a feeling. The Tarmac 10 is our attempt to make quality concrete: ten engineering practices that de-risk the delivery lifecycle, applied on every project, that a client can actually inspect.
Quality as a system, not a virtue
The practices cluster around a few ideas:
- Small, single-purpose changes. Tiny, reviewable pull requests catch problems early and make releases boring. Boring releases are good releases.
- Automated tests as a gate, not an afterthought. Tests are mandatory, not optional, and they run in CI on every change.
- Peer review at every stage. Nothing merges on one person’s say-so. Shared code ownership keeps the bus factor high and the surprises low.
- CI/CD that supports many releases a day. Speed and quality aren’t a trade-off when the pipeline enforces the standard for you.
- Repository hygiene. A clean, well-documented codebase is the difference between onboarding in days and onboarding in months.
Why it compounds
Any one of these is common sense. The value is in doing all of them, consistently, so that velocity and quality reinforce each other instead of competing. A team that ships small, tested, reviewed changes through a solid pipeline moves faster over time, not slower, because it isn’t paying down a mountain of avoidable defects.
The point is transparency
The Tarmac 10 also gives clients something to hold us to. It’s paired with honest reporting, fast issue resolution, and contracts you can cancel on 30 days’ notice. When the process is legible, trust doesn’t depend on a good feeling. It depends on evidence.
That evidence is a big part of why 85% of our new work comes from referrals.