How I Work

Direct access. Practical delivery. Clear communication.

I keep this simple. When you work with me, you work with me — not a delivery team, an account manager, or a layer of consultancy sitting between the conversation about your problem and the work itself.

The goal is straightforward: understand the problem, reduce uncertainty, and leave you with technology you can actually trust, understand and support.

I look at the whole problem first

Before I talk about a fix, I want to understand the system — what it does, who depends on it, what's already been tried, and what a good outcome actually looks like from your side. Then I fix one thing at a time, so we don't break something else along the way.

I prefer evidence to assumptions

Old systems carry decisions nobody wrote down. What someone tells you a system does, and what it actually does, aren't always the same thing — so I'd rather check than guess. A client once asked me to delete a blank page from a document. The real problem was that the page held content the system still needed — deleting it would have lost data, not fixed anything. I checked first.

Practical work, not theatre

I'm not here to write a large strategy document. I'm here to understand operational systems, fix what's broken, improve what's fragile, and leave things better than I found them — using C# and .NET where that's the job, and a plain conversation where that's the job.

Documentation means someone else can run it after I'm gone

If a system matters enough to fix, it matters enough to document — not documentation for its own sake, but enough that someone else can actually support it once I've left.

No unnecessary process

I don't force every engagement through the same template. Some problems need investigation. Some need delivery. Some just need someone experienced enough to say this isn't actually the real issue.

Finishing the work isn't the same as leaving you better off

I measure an engagement by whether you're genuinely in a better position afterwards, not just whether a requirement got implemented. That's not always about money. Sometimes it's less operational risk, less stress on the team supporting a system, fewer things that only one person understands, or just being able to see what's actually going on inside something that used to be a black box. It's part of why I care about understanding the operational reality first, documenting things properly, and asking awkward questions when something doesn't add up — a system I hand back that nobody can maintain isn't actually finished, whatever the ticket said.

How delivery actually works

Six stages. Moved here from the Consultancy page in slice 3 of the site rewrite, because delivery mechanics are the same whichever route you arrive by, and repeating them on three journey pages meant three copies drifting apart.

1. Discovery. Understand your goals, current systems, constraints, and what success looks like. You get a scoped plan with realistic estimates, architectural direction and quick wins. The same accountable contact stays with you throughout.
2. High-level design. A chargeable engagement producing a detailed design proposal: technology stack, architecture diagram, database schema, API contracts and delivery timeline. You review and approve before development begins.
3. Agreement. Review the findings together. Scope, deliverables, fees and timeline agreed in writing. Everything documented before code starts.
4. Build and iterate. Code delivered in small, testable increments, with regular checkpoints rather than a reveal at the end.
5. Solution sign-off. You confirm the work does what the scope said it would, against the scope written down before it started.
6. Handover and support. Documentation in the repository, not in an email, and a defect window after sign-off.

What you can expect

• Direct access to me, not a delivery team
• A practical, evidence-led approach
• Clear communication, including when the answer isn't what you hoped to hear
• I'll say up front if something's outside my stack or I can't help
• Documentation that means the system can be supported after I'm gone
• 100% remote delivery

Explore related areas

Remote delivery · Is this a fit? · Knowledge transfer

Let's talk

If you'd like to talk about how this would work for your organisation, a short conversation is the best place to start. Prefer to see evidence first? See real project examples or read what people say about working with me.