Hands-On Development

Code First

Most of my work involves writing code. That might seem obvious for a software engineer, but it's worth stating because the consulting industry has a habit of drifting towards advisory roles where the consultant talks about code without actually producing any. My focus is the opposite: I join your team, pick up tickets, write features, fix bugs, review pull requests, and ship working software. The advisory perspective comes as a byproduct of being close to the codebase, not as a separate engagement.

This matters because the best technical decisions come from people who understand the reality of the system they're working with. It's one thing to recommend an architectural change from a whiteboard; it's another to recommend it having spent a fortnight inside the codebase understanding why things are the way they are. I've found that the most useful insights tend to emerge while doing the work, not while reviewing it from a distance.

What I Bring

I've been writing production software since 2008, working with PHP and Laravel since version 3, and across a range of front-end technologies including TypeScript, Vue.js, Livewire, and HTMX. On the infrastructure side, I work with AWS, Cloudflare Workers, Docker, and manage my own Linux servers. At SUMAC I implemented infrastructure as code using Ansible to manage provisioning and deployment across environments, and I carry that same discipline into my current work - infrastructure should be reproducible and documented, not held together by manual processes and tribal knowledge.

What distinguishes this from a typical contractor engagement is the breadth of experience I bring to the work. Having spent over six years as a CTO, I naturally think about the wider implications of the code I'm writing - how it affects the team, the architecture, the product roadmap. I'll flag a concern about a database schema that will cause problems at scale, or suggest a pattern that will make the next developer's life easier, because I've been the person who inherited those decisions and dealt with the consequences.

That said, I'm not there to impose my preferences on your codebase. I follow your conventions, use your tools, and work within your processes. The goal is to strengthen the team's output, not to create a dependency on my way of doing things.

How I Differ From a Typical Contractor

I've written about the contractor problem in some detail. The structural risk with short-term contractors is that they're measured on delivery speed, which incentivises decisions that optimise for the short term at the expense of long-term maintainability. Framework choices that the permanent team don't understand, database schemas designed without knowledge of future requirements, patterns that work but can't be extended.

I'm conscious of this because I've been the CTO who inherited contractor code and had to deal with the consequences. When I write code for your team, I write it as though I'll be the one maintaining it in six months - because that's the standard your permanent team deserves. Tests are included, patterns are consistent with the rest of the codebase, and anything non-obvious is documented.

What This Looks Like in Practice

The Housekeeping package is a good example of how I approach development. I identified a problem - developer time being wasted on context switching between the terminal and GitHub - scoped a tight MVP, chose sensible dependencies rather than reinventing the wheel, and built it with clear specifications and testing throughout. It's open source, it's on GitHub, and it reflects the standards I apply to all my work.

Bidh, the Gaelic language tutor, demonstrates a different kind of challenge: integrating multiple AI services, real-time voice processing, and edge computing into a cohesive product. The technical complexity is high, but the approach is the same - clear specifications, incremental delivery, and pragmatic decisions about where to invest effort.

Both projects, and the client work I do, share the same principle: write clean, maintainable code that solves the actual problem, and leave the codebase in a better state than you found it.

---

If you need a senior engineer who can contribute meaningfully from day one without needing hand-holding, get in touch.