How should this be built, before anyone builds it?
The design itself, written for one system, service, API, or controller: the approach, the interfaces, the failure modes, and what to build first. Then one round of argument in writing.
$3,500 · written, within ten business days, one revision
The question
The second opinion judges a decision you have made. This one makes it.
For one system, service, API, or controller that should be designed properly before it is written. You know what needs to exist and not how it should be built. There is nothing yet to review.
What you get
Back comes the design itself:
- The approach, and why it beats the alternatives.
- The interfaces.
- The failure modes it handles and the ones it does not.
- What I would build first, and what I would leave until you know more.
How it runs
- You send the problem. The problem, the constraints, and what exists today.
- The design comes back, in writing.
- One round of argument, in writing. You push back on what you disagree with and I answer it. That round is the point.
No call and no scheduling.
Price and timing
- Fee
- $3,500.
- Delivery
- Written, within ten business days.
- Revision
- One round of argument, in writing.
- If it becomes a build
- The fee comes off it, and the build gets priced against something I have designed rather than something I imagined.
What this is not
It is not implementation, not more than one system, and not standing availability afterward. It is not a review of a proposal you already have, which is the second opinion. If the answer is that this should not be built, you get that instead, and it is still the whole deliverable.
Where the line sits against the $950
- Send the second opinion a thing. A design document, a pull request, a single service, or the decision you are arguing about. You have a proposal and want it judged.
- Send this one a problem. You know what needs to exist and not how it should be built. There is nothing yet to review.
- Out of scope: implementation, more than one system, anything that needs access to your infrastructure, and standing availability afterward. If the answer is that this should not be built, you get that instead, and it is still the whole deliverable.
Who does the work
Douglas Adolph. I designed and built the deployment system behind a fleet of thousands of production Kubernetes clusters at a Fortune 50 company, and took deployments to that fleet from weeks down to seconds, and I still maintain it today. Around it I have written the controllers that keep a fleet honest, the authentication path teams use to reach clusters at all, the secrets tooling, and the post-deploy verification that catches a release which reconciled cleanly and is quietly unhealthy.
The engineer who scopes your work is the engineer who does it.
Longer background, and the public code I own, at douglasadolph.com. Read the source before you talk to me.
Send me the problem
Tell me what you are trying to find out and I will tell you whether I can help, including when the answer is that you do not need me.
- What is stuck, or what you are trying to measure.
- What you have already tried, and what happened.
- Any date you are working against.
A short note beats a long form. What comes back is a reply from me rather than a scheduling link, which engagement fits or that none of them does, and for a build, a scope and a number before you owe anything.