How I work
My first job isn't to write code - it's to understand the business well enough that the technology decisions are obviously right. Here's what that looks like in practice, and what I'll expect from you in return.
Business outcomes first
Every technical choice has to earn its place in business terms - what it makes possible, what it protects, what it saves. If I can't explain a decision to you without jargon, I don't yet understand it well enough to be making it. Technology that can't be tied back to an outcome is usually technology that's there for its own sake.
Ownership, not hand-off
Software isn't "done" when v1 ships - that's roughly when the real work starts. I stay accountable for operations, the roadmap and the decisions that come after launch, rather than handing you a codebase and a goodbye. That gap - the one a fixed-scope agency leaves you standing in - is exactly what this practice exists to close.
The engagement, step by step
- 01Understand the business
We start with the business, not the build: what you're trying to achieve, where the constraints really are, and what success would actually look like. I'd rather spend the first conversations here than rush to a solution that solves the wrong problem neatly. Nothing technical gets decided until this is clear.
- 02Shape strategy & roadmap
From there I shape a technical strategy and a roadmap - but expressed in outcomes and trade-offs you can weigh, not a Gantt chart you have to take on faith. You'll know what we're doing first, what we're deliberately not doing yet, and why. The plan is something we steer together, not something handed down.
- 03Build & lead the team
I bring in the right specialists for the work - development, design, QA, whatever it needs - and run delivery day to day, so you never have to manage a roster of vendors. You get one point of accountability: me. The team scales up and down as the work changes, without you renegotiating it each time.
- 04Ship & keep owning it
We ship - and then keep going. Operations, iteration and the roadmap stay owned, rather than quietly handed back to you the moment it's live. As the business changes the technology gets steered to match, so you're never left holding something you can't maintain or explain.
What working together asks of you
This works best as a partnership, not a hand-off in the other direction. I'll need a bit of your time on a regular cadence - enough to keep the technical decisions anchored to where the business is actually heading - and honesty about the things that are easy to gloss over: real constraints, real budget, what's genuinely working and what isn't.
You don't need to understand the code; that really is my job. But you do need to stay engaged with the trade-offs, because the best ones are business calls wearing technical clothing. You stay firmly in control of the business; I take the technical weight off you - that's the deal.