Approach
Small teams, short increments, nothing hidden.
Most federal software trouble is not technical. It is a scope problem discovered too late, by a customer who was shown slides instead of software. Our delivery model exists to make that impossible.
Delivery model
Three commitments we make in writing.
The people who scope it, build it
No pyramid staffing. We do not win work with principals and then hand it to a bench. If you meet an engineer during capture, that engineer is on the team.
Working software every two weeks
Every increment ends with something running in an environment you can log into. Progress you can click on is the only kind that cannot be overstated.
Handover is a deliverable
Architecture decision records, runbooks, and environment builds are contract deliverables, not favors. You should be able to re-compete the work and lose us without a rebuild.
First ninety days
What actually happens, in order.
This sequence is deliberate. Each step exists to retire a specific risk before the next one gets expensive.
-
01
Week 1 — Read before writing
We read the code, the tickets, and the incident history before proposing anything. Most inherited systems are better than their reputation and worse than their documentation, and we would rather find out which on our time than yours.
-
02
Weeks 2–3 — Environment and pipeline first
Before feature work begins, we stand up a reproducible environment and a pipeline that builds, tests, scans, and deploys. Teams that skip this step pay for it every sprint afterward.
-
03
Weeks 4–6 — The riskiest thing first
The first real increment targets whatever is most likely to invalidate the plan — the integration nobody has tested, the data quality assumption, the performance ceiling. Good news early is pleasant; bad news early is valuable.
-
04
Weeks 7–12 — Cadence
Two-week increments, each ending in a demonstration against the running system and a written summary of what changed, what it cost, and what we learned that changes the plan.
-
05
Ongoing — Handover kept current
Documentation is updated in the same pull request as the code, so it is never a separate project at the end. At any point in the engagement, a new team could pick the system up.
Fit
Work we turn down.
Saying this publicly costs us some inquiries and saves everyone the wrong engagement.
- Pure staff augmentation. If the need is bodies against a seat count rather than outcomes against a system, another firm will serve you better and cheaper.
- Fixed scope, fixed price, fixed date, unclear requirements. Any two of those we can work with. All four is a dispute with a start date.
- Work we cannot staff with senior people. If we cannot put experienced engineers on it, we would rather decline than dilute the thing we are selling.
- Rewrites proposed before anyone has read the existing system. Sometimes a rewrite is right. It is never right as an opening position.
Next
Registration details and codes.
Everything a contracting officer or a prime's teaming lead needs, on one page.