Hey, I’m W. I build software that gets found, gets used, and holds up.

What I do best

Real results, real systems. This is the work I’m hired for — and the work I love doing.

• Growth through discoverability — 10× adoption

  I turn “we built it, why isn’t anyone using it?” into growth. I made one launch properly discoverable instead of burying it behind menus, and 10× more people tried it — the best result of its kind there. Another team later adopted the same pattern for their own launch. Placement is product, and I design for it from the start.

• Observability that finds the truth fast

  I make systems explain themselves. I’ve spotted traffic misrouted across three regions by reading traces end to end — before any dashboard admitted something was wrong — and I build the tracing and metrics that let any team answer “what just happened?” without a war room.

• Platform tools that unblock everyone

  I build the ground other teams stand on: instant previews instead of publish queues, release and debugging dashboards that shape how teams ship, feature flags and gradual rollouts that make releases calm and reversible. If it saves every team an afternoon a week, that’s leverage.

• Prototypes and AI workflows that end debates

  I replace arguments with something real people can click. I’ve gotten designers prototyping in the actual codebase — one co-built prototype ended a debate stuck for seven months — and I do the same with AI today: reusable workflows, shared recipes, and hands-on sessions on real work.

• Measure, decide, automate

  That’s my operating system in every role: measure first, decide with evidence, then automate the annoying part so nobody has to do it twice. It worked in the field checking installations, over data from thousands of buildings, and it works now at platform scale.

Writing

Short, practical notes on building, observability, and AI workflows — the lessons behind the results above.

• All
• Building
• Observability
• AI & learning
• Life

• Oct 2026·Building·3 min read

  If people can’t find it, it doesn’t exist

  The most valuable change I shipped recently wasn’t a feature. It was moving a feature.

  Read note

  Teams hide new work for understandable reasons: it’s not finished, support might get questions, someone important might see a rough edge. So the new thing goes behind a menu, a setting, a flag nobody flips.

  Then the data comes back “meh” and everyone concludes the idea was weak. It wasn’t weak — it was invisible. When I made one launch properly discoverable instead, usage went up 10×, and the lesson stuck: placement is product.

  Now my default question for any launch is: how many clicks, hunts, and acts of faith stand between a person and the value? Shrink that number first.

• Oct 2026·Observability·4 min read

  Traces don’t lie (dashboards sometimes do)

  A dashboard tells you the average story. A trace tells you what actually happened to one real request — including the detour to the wrong continent.

  Read note

  Aggregates are comforting and misleading in equal measure. Averages hide the one weird path; totals hide which region, which service, which flag.

  The catch I’m proudest of came from reading individual traces and noticing requests landing in places they had no business being. No alert fired. The graphs looked… fine-ish. The traces just patiently showed the truth, span by span.

  My rule since then: when something feels off and the dashboards shrug, go read ten real traces end to end. It’s slower than glancing at a chart and faster than guessing for a week.

• Oct 2026·AI & learning·3 min read

  Teach the workflow, not just the tool

  Handing people an AI tool changes little. Handing them a reusable workflow changes how a whole team operates.

  Read note

  Every new tool arrives with the same failure mode: a launch announcement, a few enthusiasts, and everyone else quietly going back to their old habits.

  What actually spreads is a workflow: a named, reusable recipe someone can copy on a tired Tuesday. I’ve had the most success packaging AI help as small shared skills and step-by-step flows, then running sessions where people use them on their real work — including designers prototyping in the actual codebase instead of mockups.

  People don’t adopt tools. They adopt shortcuts that demonstrably work once. Give them the one win, packaged.

• Oct 2026·Building·3 min read

  Make releases boring

  A good release should feel like flipping a light switch, not defusing something.

  Read note

  Scary releases are a design choice. If shipping means one giant change, no off-switch, and a prayer, of course everyone dreads Fridays.

  The boring-release recipe I keep coming back to: ship behind a flag, roll out gradually, watch real traces and metrics while it ramps, and keep rollback to one flip you’re confident in because you’ve practised it.

  Boring is underrated. Boring releases mean you can ship small, ship often, and spend your courage on the product instead of the deploy.

• Oct 2026·Life·2 min read

  Why I’m writing this stuff down

  I kept solving the same problems twice because the lesson lived in a closed doc or my own unreliable memory. So: notes, in public, from now on.

  Read note

  Engineers are magpies for hard-won lessons and terrible at keeping them. Mine were scattered across private docs and chat threads that search couldn’t find and future-me couldn’t remember writing.

  This page is the fix: one public notebook. Short notes, real numbers where I have them, no polish required. If a note helps someone else skip a week of confusion, that’s a bonus — the main audience is me, six months from now, wondering “haven’t I seen this bug before?”

  Yes. Yes I have. It’s written down now.

No notes in this topic yet.

Adding a note is just copying a <li class="post"> block above and picking a category. No build step, no CMS.

The plot so far

Field work, data, code, platforms — every chapter added a skill I still use. That mix is the point.

1. 01

   Outdoors & energy

   Started in renewable energy — out in the field making sure things were built right, then crunching numbers so managers knew what things cost and what to fix first.

2. 02

   Data for big decisions

   Taught myself to script my way out of spreadsheet hell. Analysing equipment across thousands of locations to help prioritise upgrades worth serious money — and discovering I liked the code more than the reports.

3. 03

   The pivot to building

   A bootcamp, then a run of small companies across health, finance, and data products. New domain every time, same habit: ship something real, watch how people use it, make it faster.

4. 04

   Platforms & unblocking people

   Graduated from building features to building the ground features stand on — release tools, flags, tracing, metrics — and became the person other teams ping when something’s slow, scary, or stuck.

5. 05

   Now: family, building, notes

   Still building, still measuring — plus raising two kids, contributing a little open source, and writing field notes in public instead of hoarding them in private docs.

Right now