How I Work
Process‑Driven.
Not Process‑Obsessed.
Good process exists to remove uncertainty — not to create meetings. Here's exactly how every engagement runs, from first call to final handover.
The five steps
-
01
Deep Listen
Most engineering problems are stated problems, not real ones. A client once came to me asking for a faster search feature. After 25 minutes of conversation it was clear their search was already fast enough — their users just couldn't find the search bar. The real problem was information architecture, not engineering. We saved three weeks of build time and the product improved more than a new search algorithm ever would have.
Every engagement starts with a call where I'm not selling and I'm not scoping — I'm listening. I want to understand what you're trying to achieve, what you've already tried, what constraints you're working inside (budget, timeline, existing tech, team capacity), and who actually uses the product. I ask questions that sound irrelevant until they're not.
At the end of this step I write back what I heard — a short summary of the problem as I understand it. If I got it wrong, we fix it now rather than six weeks from now.
-
02
Architecture First
Writing code before the architecture is decided is the engineering equivalent of building a house before the blueprints. You end up tearing walls down later. Before any implementation begins, I produce a simple architecture document — not a 40‑page spec, but a clear map of what the system does, how data flows through it, where the external dependencies are, and where the risk lives.
This is where tech selection happens. I choose tools based on the problem, not on what's trending. For most web products the right answer is still boring: proven databases, well‑supported frameworks, hosted infrastructure that doesn't require a devops team to run. For AI features I think carefully about latency, cost, and what happens when the model returns a bad answer — because it will.
You get the architecture document to review before any code is written. Changes at this stage cost one conversation. Changes at week four cost a week of rework.
-
03
Iterative Delivery
I don't disappear for three months and emerge with a finished product. I work in short cycles — typically one‑week sprints — and you see working software at the end of each one. Not mockups. Not screenshots. A deployed build you can click through and give feedback on.
This matters because clients always know things they don't know they know until they see the product. "Actually, our users do this in a completely different order" is a perfectly normal thing to discover in week two — and if we're working iteratively, it costs one sprint to adjust. If we're working waterfall, it costs a renegotiation.
Each sprint ends with a brief written update: what was built, what's next, any decisions that need your input. If something is taking longer than expected, you hear about it before it becomes a problem, not after.
-
04
Communication as Code
Every technical decision I make during a project gets documented the moment I make it — not reconstructed at the end from memory. If I choose one database indexing strategy over another, I write down why. If I reject a library because of its maintenance status, that's in the notes. This creates an audit trail that's useful when you bring in a new developer six months later and they ask "why did they do it this way?"
Beyond technical documentation, I have a consistent communication cadence: a brief async update at the start of each week outlining what I'm working on, and a summary at the end of the week with what's done. Any blocker or decision that requires your input gets escalated immediately rather than waiting for the weekly summary. I don't believe in surprises.
I use whatever tools you're already using — Slack, Linear, Notion, email. The best communication system is the one you'll actually read.
-
05
Ownership & Handover
The end of a project is not the end of my responsibility to it. A completed engagement includes: a final code review pass to clean up anything that accumulated during delivery, a README and architecture summary written for a developer who has never seen the codebase, a walkthrough session where I explain the system and answer questions, and a 30‑day window where I'm available for questions at no extra charge.
I take the handover seriously because I've been on the receiving end of bad ones. Inheriting a codebase with no documentation, mysterious patterns, and an absent original developer is a genuinely demoralising experience. I won't do that to your team or your next hire.
After the 30‑day window, I'm still reachable. I don't ghost clients after invoicing. If something is broken and it's clearly my fault, I fix it — full stop.
Common Questions
Things People Ask.
-
Both, and I'll tell you which I'd recommend for your specific situation. Fixed price works best when the scope is well‑defined — you know what you want built, we've agreed on the requirements, and surprises are unlikely. It's lower‑risk for you and lets me work efficiently without tracking every hour.
Hourly works better for exploratory work — an audit, a proof‑of‑concept, or a project where the direction might change as you learn more. Committing to a fixed price on an undefined scope is how both parties end up frustrated. I'd rather charge hourly honestly than pad a fixed quote to cover uncertainty I can't price.
-
With a written change order process that's agreed upfront, before any work starts. If a new requirement comes in mid‑project — which it will, because that's normal — I document it, estimate the additional time and cost, and get written approval before implementing it. No surprises on the final invoice.
I also try to distinguish between scope creep and legitimate evolution. If we discover in week two that what you asked for won't actually solve your problem, pivoting isn't scope creep — it's doing the job properly. I'll flag it, explain the tradeoff, and we'll decide together. The change order process exists for additions, not for corrections.
-
Yes — visit the portfolio page for public project write‑ups, or book a call and I'll walk you through case studies live. The live walkthrough is usually more useful: you can ask questions about the decisions I made, what went wrong, and what I'd do differently.
Some of my best work is under NDA and won't appear in a portfolio. If you're evaluating me for a project that's similar to something I've done privately, tell me — I can often share sanitised details or connect you with a client who's willing to take a reference call.