Skip to main content

How we define “done”

Most software disputes come down to one thing: nobody wrote down what finished meant. We write it down, in the repository, before the build starts.

What's in the standard

Every project carries an acceptance document covering seven areas.

01 Functional correctness
Each requirement in the specification maps to a check that passes or fails.
02 Test coverage
What must be tested and to what depth, with the tests in the repository.
03 Security
Dependency scanning, secret scanning, authentication and authorization checks against the permission model.
04 Performance
Page and response time budgets, measured under defined conditions, not on a fast laptop.
05 Accessibility
Automated checks plus keyboard and screen-reader review of every primary flow.
06 Data integrity
Migrations that run forward and roll back. Backups that restore.
07 Operational readiness
Monitoring, error reporting, logs, and a runbook for the things that break.

How it gets enforced

Automated gates run on every change and block anything that fails. Multiple independent review passes examine the work against the specification, deliberately looking for where it falls short rather than confirming it looks fine. A final verification pass checks the acceptance document item by item.

Tell us what you need.

Send a paragraph about your organization and the problem in front of you. We'll tell you whether we're the right shop, what we'd build, and what it costs. If we're not the right shop, we'll say so and point you somewhere better.