How the work is run
This is the cadence every engagement runs on, whatever the practice. It is written down because a client should be able to tell, in week three, whether they are getting it.
Lifecycle
It loops, it does not end
The loop closes because Eorbitt operates what it builds. Review feeds the next build rather than ending the engagement, and the operate stage is where most of an application's cost is actually incurred.
Practice
What happens, and what you get from it
| Practice | Cadence | What happens | What you receive |
|---|---|---|---|
| Discovery | Once, 1 to 2 weeks | We observe the process as it runs, read the code and the ticket history, and interview the people who hold the exceptions in their heads. | A process map, a risk register, and an estimate with its assumptions listed separately from its numbers. |
| Architecture review | Once, then at any major change | Options are compared in writing against the constraints, and the chosen one is recorded with the reasoning and the alternatives that were rejected. | Architecture decision records in your repository, in a format your own engineers can add to. |
| Sprint cadence | Every two weeks | Work is planned against a single prioritised list, and every sprint ends with software running in a staging environment you can open. | A staging link, a written summary of what changed, and the list of what was deliberately not done. |
| Code review | Every change | No change reaches the main branch without a second engineer's approval. Review comments address correctness and the cost of maintaining the code, not formatting, which is automated. | A full pull request history, readable long after we are gone. |
| Test standards | Every change | Paths that move money, grant access or touch regulated data are covered by integration tests against a real database. Coverage percentage is not treated as a goal in itself. | A test suite that runs in your pipeline, and a written statement of what is deliberately untested and why. |
| Continuous integration and delivery | Every merge | Type checking, linting, tests and a build run on every merge. Deployment to production is a single reviewed action, and rolling back is the same action in reverse. | Pipeline configuration in your repository, with no step that only works on our machines. |
| Observability | Continuous, reviewed monthly | Structured logs, traces and error reporting are configured before launch, with alerts tuned so that a page at 3am means something is genuinely broken. | Dashboards in your own accounts, and an alert routing table naming who is called and when. |
| Documentation and handover | Continuous, formalised at close | Runbooks are written as the system is built, not reconstructed at the end, and they are tested by having someone outside the project follow them. | A runbook, an architecture note, a credential transfer record, and a working session with your engineers. |
Audit
What you can inspect, at any point
Nothing in that list requires a request. It lives in your repositories and your accounts from the first week, so an engagement can be inspected while it is running rather than reconstructed afterwards.
- Every pull request, its review comments and its approvals
- Architecture decision records, including the options that were rejected
- Pipeline configuration and the full deployment history
- Test results for every release, and the list of what is untested
- Alert routing, escalation paths and the incident record
- Credential inventory and the transfer record at handover