- Home
- Method
Four stages. Each one ends with something you keep.
The order is fixed. The cost of each stage is agreed before it starts. Nothing waits for a launch.
The stages
In this order
Survey
We read the code, the data, and the support tickets. Then we tell you what is broken.
- What we do
- We read the metadata, the data, the integrations, and the last year of tickets. We interview the people who do the work, not only the people who manage it. We look for what runs, what is dead, and what people route around. Then we write it all down as a keep, kill, and rebuild list, with the reason next to each line. The first cycle is proposed at the end, with a number.
- What you get
- A written read of the org: what runs, what is dead, what is risky.
- A keep, kill, and rebuild list, with a reason on every line.
- A map of the integrations and automations, including the ones nobody owns.
- The first cycle, scoped and priced.
- Done when
- You can argue with the read, because every line in it is specific enough to be wrong.
Route
We agree on the shortest path to value. You approve the plan and the cost before we build.
- What we do
- We agree the order. The shortest path to something your team can use goes first. Each cycle gets a scope, a number, and a result you can use when it ends. No later cycle is required for an earlier one to be worth doing. You can stop after any cycle and keep everything.
- What you get
- A sequence of cycles, each with a scope, a cost, and a usable result.
- A written scope for the first cycle, with what is out as well as what is in.
- A fixed price for the first cycle.
- The right to stop after any cycle and keep everything delivered.
- Done when
- You have approved the first cycle in writing.
Build
We ship in short cycles. You use each part as it is done. Nothing waits for a big launch.
- What we do
- We ship in short cycles. Everything goes in source control from the first day. We work in a sandbox or a scratch org, never straight in production. Every change has a test. At the end of each cycle we demo on your real data with your team in the room, and your team uses the result from that day. Nothing waits for a launch.
- What you get
- Working software in production at the end of each cycle.
- A repository with every change and the reason for it.
- Tests that run before anything deploys.
- A recorded demo on real data at the end of each cycle.
- Done when
- Your users use the result of the cycle.
Hand over
We give you the code, the documents, and the training. Your team owns the system.
- What we do
- We give your team the repository, the runbook, the data dictionary, and the automation map. We record the training so the next hire can watch it. Then we run a final cycle where your team ships the change and we watch. We answer questions. We do not touch the keyboard.
- What you get
- The repository, with the deploy process written down.
- A runbook, a data dictionary, and an automation map.
- Recorded training your team can replay.
- A final cycle shipped by your team, with us watching.
- Done when
- Your team has shipped a change without us.
What we will not do
So you know
- Big-bang launches. Nothing waits months for a release day.
- Scope without a number. Every cycle has a cost before it starts.
- A system your team cannot read. If we cannot explain it, we do not ship it.
- A dependency on us to keep it running.
- Credentials in our names. Access is yours, granted and revoked by you.
- A document we promise to write later. The documents ship with the cycle.
- Talk about other clients' systems. We do not discuss theirs, and we will not discuss yours.
How we price
Plainly
The survey is a fixed, small engagement. Its price is agreed before it starts and does not move.
After the survey, each cycle is scoped and priced before it starts. You approve it in writing. No cycle begins on a verbal yes.
No retainer is required. You can stop after any cycle and keep everything delivered: the code, the documents, the training.
There is no figure on this page because we have not read your system yet. The survey is where the number comes from.
Questions we get
Answered plainly
Can we start with a Survey only?
Yes, and many do. The survey stands on its own. You get a written read of your org with a keep, kill, and rebuild list, and you can act on it with your own team or another vendor.
If you want to go further, the first cycle is already scoped and priced at the end of it.
Do you work alongside another vendor?
Yes. The survey reads what they built too, and we say what we find. We do not soften the read because someone else did the work, and we do not pad it either.
Where the other vendor keeps running part of the system, we write down the boundary so both sides know who owns what.
What size of organization?
The method fits a single large org or a federal program. What matters is that someone on your side can own the result. If nobody can, we say so in the survey, and we would rather help you find that person than build something with no owner.
Remote or on site?
Remote by default. On site when the survey needs it, usually to sit with the people who do the work and watch where they route around the system.
What do you need from us to start?
Three things. Read access to the system. The last year of support tickets. An hour with the people who do the work, not only the people who manage it.
With those, the survey can start. Anything else we need, we ask for as we find it.
Stage one
Start with a survey.
A small engagement with a fixed price, agreed before it starts. You keep the read whatever you decide next.