80 hours, one priority list: how a fixed first month works
After an audit, the question is who does the work and what it costs. Our answer is one fixed price for 80 hours of engineering, spent on your issues in priority order. What happens in those hours, and what you hold at the end.
An audit leaves you with a list. Then comes the harder part: someone has to do the work, and you have to approve a number before you know how the work will go.
Our answer is a first month with three things fixed and one thing ordered. The price is fixed. The hours are fixed: 80, of forward deployed engineering. The way of working is fixed. And the issues from your deep audit are in one priority list, which we work through from the top, as far as the time allows.
How the 80 hours go
- Access. You give us read access to your code and your data. We don’t ask for your database or your admin passwords.
- Reading. We study your code and your setup before proposing any change. A fix that ignores how the site is built creates the next problem.
- Fixes. We work down the list. Each fix is handed over as code and exact settings, ready for your team to apply.
- Wrap-up and reports. Every task is reported, done or not done, with what we found along the way.
- Handoff. We go through all of it with your team, so nothing depends on us to keep running.
What you hold at the end
- The fixes, as code and settings your team has applied or can apply.
- A full report of every task: what was done, and what wasn’t.
- The list of pending items, still in priority order, with everything we learned about each one.
- A Growth opportunities report: what changed, and what to do next.
If you stop there, all of it is yours to use with your own team or with anyone else.
Why we don’t quote hours per task
Because the numbers would be invented. Until someone opens the code, an estimate for a single fix is wrong in both directions: the “two-hour” change that takes two days, and the “big” one that turns out to be a setting. A table of hours per task looks precise and mostly produces arguments.
What can be known in advance is the order. If the most valuable issues are at the top and we work from the top, the hours go where they pay, whatever each task ends up taking. That is also why we don’t promise to fix everything.
Why a month, and why 80 hours
It is enough to fix the things that matter most on a typical site, and small enough to approve without a committee. It is also a fair test in both directions: you see how we work on your own site, and we learn your code and your numbers. If there is more worth doing afterwards, the work continues month by month.
Before a first month, have ready
- Who on your side will apply the fixes, and how much time they have.
- Read access to your repository for one address.
- Who decides when two priorities compete.
- A date for the handoff meeting.
Written from our engineers’ work on production systems. Want a second opinion on your project? Talk to an engineer.
See the work →