Approach · Software engineering
A passing build is not a finished product.
When the answer is custom software, we build it: internal tools, integrations, websites, and the applications our own practice runs on. It counts as done when the change is seen working where people use it, on the live site or on a phone.
How we approach it
- 01
Build where the evidence supports it.
Software gets written when the investigation shows it's needed, and it is scoped to that need.
- 02
Test it the way people use it.
Rendered checks at real phone widths run alongside unit tests. In our own work, green tests and a green build have missed defects a phone found.
- 03
Verify on the live system.
A commit, a build or an HTTP 200 doesn't count. The change has to be seen where the customer will see it.
- 04
Fail closed.
When the target or the authority is ambiguous, the software stops instead of guessing. On someone else's live business, stopping is the safer error.
Questions it answers
- Does this need custom software, or a change to something that already exists?
- How will we know it works for the people who use it?
- What should the software refuse to do?
- Who maintains it after launch?
In practice
Where this shows up in our own work, with each item's current status.
Tell us what you're trying to accomplish.
We'll talk through the problem, whether Lehvel is a good fit, and a sensible next step. The scope comes from the problem, not a package.