What I Stand For

Non‑Negotiables.

These aren't aspirational values from a slide deck. They're patterns from 12+ years of client work — things I got right, things I got wrong, and the rules I developed as a result.

The principles

No Overpromising

Early in my career I said yes to a client timeline I privately knew was unrealistic. I thought I could make it work by pushing harder. I couldn't. We missed the date, the client was blindsided, and I spent three weeks recovering a relationship that had been fine until I tried to manage it instead of being honest about it.

I never do that anymore. If a timeline is too tight, I say so in the first conversation — with the numbers to explain why. If a feature is riskier than the brief implies, I flag it before scoping, not after. If I genuinely don't know how long something will take, I say "I don't know yet — here's how I'll find out."

Some clients don't like hearing this. That's fine. The alternative — telling people what they want to hear and then underdelivering — is worse for everyone, and it's not a business I want to run.

Deadlines Are Commitments

A deadline I agree to is a commitment, not an estimate. I've hit 96% of agreed delivery dates across 60+ client projects. The 4% I missed, I flagged early — never on the day.

What this looks like in practice: I build buffer into my timeline estimates (and I tell you I'm doing it). I track progress against the plan weekly. The moment I can see a deadline is at risk — even if it's still two weeks away — I raise it immediately with options: descope, add time, or increase pace. What I don't do is stay quiet and hope.

Client businesses make decisions based on delivery dates. A product launch is scheduled. A sales demo is booked. An investor meeting is set. Treating a deadline as a guideline is not respecting that your work connects to mine in ways I might not even know about. I take that seriously.

Code Leaves a Legacy

The code I write will be read by people who weren't in the original conversations, who don't know why certain decisions were made, and who will form opinions about the original developer based entirely on what they find. I try to make those opinions fair.

This means: naming things clearly even when a shortcut is tempting. Writing comments that explain why, not what. Not leaving console.log statements and TODO comments in production. Not building something clever when something boring would work. Clever code impresses developers who will never maintain it. Boring code is a gift to the developer who inherits it at 11pm on a Friday.

My personal test: before I consider a piece of work done, I ask whether I'd be comfortable receiving this codebase from someone else. If the answer is no, it's not done yet.

Client‑First Thinking

I once recommended a $200/month open‑source tool to a client who had come to me to build a custom solution that would have taken eight weeks and cost significantly more. The open‑source tool did 95% of what they needed. The remaining 5% turned out not to matter. I lost the build contract and they got a working product in a week.

I do this regularly and I'd do it again. My long‑term interest is in being the engineer clients come back to and refer to others — and that only happens if I'm the person who solves their problem, not the person who maximises their invoice. Short‑term thinking about billing is how you build a mediocre freelance practice.

If the right answer for your problem is a tool, a template, or a different developer with a specialisation I don't have — I'll tell you. That recommendation might cost me a project. It will probably earn me a referral.