one moment
one moment
Approach
An honest write-up of how we run engagements — the cadence, the principles, what to expect, and the work we say no to.
Most consulting work in our corner of the world is theatre — a kickoff deck, a landscape chart, a maturity quadrant, a five-year vision that nobody on the receiving team could defend to a board member without sweating. The work that actually changes things looks different. It looks like a small team that knows your business better at the end of week two than at the start, that ships software before the second invoice, and that names the boring failure modes before they happen instead of after.
We’ve organized this practice around that smaller, less photogenic version of consulting. The cadence below is what an engagement actually feels like — not the org chart we put on a proposal.
Cadence
Week 1
Phase 01
Listen, instrument, read the system.
We sit with your team. We read the existing code, the runbooks, the support history, the contracts. We instrument what we can — sometimes that means shipping observability before we ship anything else. By Friday we have a working hypothesis we'd defend in a room with your CFO. We share it the same week.
Weeks 2–3
Phase 02
Prototype against real data.
Something runs. Not a slide of what it might do — actual software, against actual data, that you can break in front of us. We expect early prototypes to be wrong in interesting ways; that's the whole point. We learn faster from broken software than we do from intact slides.
Month 1
Phase 03
Shippable, sustainable, observed.
End of month one, there's something running that earned its place. We've removed the things that didn't work. We've documented the things that did. Your team has been in the codebase with us. We've named the next two months of work, in priority order, with budget bands.
End of engagement
Phase 04
Leave the team better than we found them.
Knowledge transfer is part of the deliverable, not the cleanup at the end. Your engineers should be able to extend what we built without us. Your leadership should be able to defend the architectural calls in a board meeting. If we've done it right, the last week of the engagement is the slowest, because there's nothing left that requires our specific judgment.
Principles
Outcomes first
Every engagement names the thing we're trying to change in the business — revenue per FTE, time to resolution, contribution margin per cohort, accuracy at the bottom of the funnel. Models, vendors, and architecture flow from there.
Falsifiable claims, short loops
We work in claims we can test in a week, not theses we defend for a quarter. If we're wrong, you find out at the cost of a sprint, not a vendor contract.
Boring software, carefully placed AI
Most of what we ship is plain, deterministic, observable software. AI lives in narrow surfaces where its non-determinism is acceptable and the upside is large. We resist the gravitational pull to put the model everywhere.
Receipts, always
Evaluations, traces, logs, versioned prompts, before-and-after numbers. If we make a claim, we can show our work.
No vendor allegiance
We don't take referral fees from infrastructure or model providers. The shortlist we recommend is the one we'd pick if our money were on the line.
Quiet about clients
NDAs by default. We won't share your name as a logo without asking. The case studies on this site are sanitized to the point that the original engagements wouldn't be identifiable to their own competitors.
Honest section
Start here
The first conversation is free, takes about thirty minutes, and goes wherever it needs to. If we’re not the right fit, we’ll say so and point you somewhere that is.
Hambone
HB Services AI assistant
Hi — I’m Hambone.
Ask me about the practice, what AI could do for your business, or how engagements work. I keep answers short.