The boring parts of software development we won't let our clients skip
Most software ships. Not all of it runs.
The gap between those two things is where we spend most of our time — not writing features, but making sure what gets written is still working three years from now without anyone having to call us at midnight to find out why it isn't.
There are parts of this work that clients consistently want to skip. Not because they don't understand why they matter, but because they cost time, they're invisible when they're working, and every vendor who isn't doing them will happily quote a lower price and a faster delivery.
These are the parts we won't skip.
Documentation that exists while the code is being written
Not after. Not in a cleanup sprint at the end of the project. While the code is being written.
This isn't about generating docs for the sake of compliance. It's about whether the person who has to modify this code in two years — who may not be on your team, may not be the person who wrote it, may be working from a different codebase entirely — can understand what the code is doing and why the decisions were made the way they were. Systems that don't have that are systems that get rewritten instead of extended. Rewrites are expensive.
We treat documentation as part of delivery. If it isn't there, the work isn't done.
Test coverage that covers the edges, not just the happy path
Unit tests are easy to write for the case where everything goes right. The work is writing them for the cases where it doesn't — the malformed input, the timed-out request, the database that's temporarily unavailable, the third-party API that returns a 200 with an error inside the body.
Those cases are where software breaks in production. They're also the cases that are hardest to reproduce after the fact, which means if the tests don't catch them before deployment, debugging them will cost more time than writing the tests would have.
We don't negotiate on coverage thresholds. We'll explain the reasoning behind what we're testing and why, but the coverage itself isn't optional.
Dependency auditing before and after
Every piece of software has dependencies. Libraries, frameworks, external APIs, authentication providers. Each one of those is a maintenance surface. Each one of them will, at some point, release a breaking change, deprecate a function, or become a security liability.
We audit dependencies at the start of a project — not just for licenses and versions, but for maintenance health. Is this library actively maintained? Is the maintainer a single person with no succession plan? Is there a migration path if it stops being supported?
We audit them again at handoff. Not every project runs into dependency problems, but the ones that do tend to run into them at the worst time, and a project that went into production with a clear dependency inventory is significantly easier to maintain than one that didn't.
The boring truth about speed
The fastest way to deliver software that lasts is to not take shortcuts during the build. That's not a paradox. It's arithmetic. Time spent on tests and documentation during the build is a fraction of the time spent debugging and re-architecting a system that shipped without them.
We're slower than vendors who skip this work. We know that. That's the trade-off, and we'd rather name it up front than have a client discover it after they've signed a contract with someone who didn't.