Case Studies

Execution narratives

The first four are the shape of work I want more of, across both tracks I work in: a founder with an idea, a prototype, or an AI-built MVP (embedded/fractional), and a small business that needs something fast and fixed-price. Same discipline I've run at enterprise scale, sized down. The rest is proof that discipline holds up when the stakes get much bigger. Situation, constraint, the decisions and trade-offs I owned, and the measured result. Numbers are real; deeper architecture walkthroughs, and the code itself for the open-source tools, available on request.

@Star and Stream

2026Founder-stage, AI-built

I used to be the junior dev writing auth code alone under deadline. Now I’m the reviewer catching what a fast AI harness gets wrong.

Technical lead: architecture, review, and verification (build execution via Claude Code)

real defects caught by asking whether it actually worked, not by trusting that it built

live account-duplication bugs found only by asking the one identity question nobody had asked yet

of the 7 catches a linter, type-checker, or green test suite would have surfaced on its own

1 session

from first build to a fully verified, self-contained test harness

SituationI’ve built auth for almost every company I’ve worked for commercially. It’s usually one of the first things a small team has to stand up under time pressure, so it tends to fall to whoever’s available, not necessarily whoever’s most senior. Early in my career, I was that person: self-taught, no CS degree, building production auth for a real business because someone had to and I was in the room. Functionally I was the outsourced resource, even though I wasn’t geographically outsourced: the founder owned the idea, I owned the execution, and the gap between "it works" and "it’s actually safe" was mine to close whether or not I knew to look for it at the time. Star and Stream needed a new auth service (password login, OAuth, magic links, its own storage layer, built to be reused rather than rebuilt each time), and I built it with Claude Code doing the actual typing.

ConstraintI’ve been on the other end of exactly this setup before, and I know firsthand what gets missed when nobody with the full picture checks the work against the real requirement instead of the stated one. An AI harness changes who’s typing. It doesn’t change that someone still has to own the outcome, not just sign off on the output. Adversarial review isn’t something I picked up from an AI blog post. I’ve run it with human engineers for fifteen years. Watching the Bun team describe running that same discipline against Claude Code while rewriting their runtime’s internals from Zig to Rust (corroborated separately by ThePrimeagen and by Boris Cherny, who leads Claude Code at Anthropic) was a reminder the discipline still applies, not where I learned it. It’s easy to get lazy about review when the output looks clean and arrives in seconds. That’s exactly when it matters most.

Decisions & Trade-offs

01Ran the same adversarial-review discipline I’d use on a human engineer’s pull request: didn’t relax it because the "engineer" this time was a harness.
02Never accepted "done" from the harness’s own self-assessment: brought in a structured review pass before treating any stage as finished.
03Asked the questions the original requirement actually implied, not just the ones the code visibly answered: does "reusable" mean reusable yet, does this feature actually deliver what it claims to, does one person stay one account across three different ways of logging in, are these tests proving anything or just not currently failing.
04Verified every fix against a real, running instance before calling it closed. "Should work now" was never the end of a conversation.

ResultSeven real defects caught, none of them visible to a linter or a passing test suite: a security assumption that only held under a deployment condition about to stop being true; a "reusable" claim the architecture didn’t actually back yet; a feature with endpoints and tests but no real delivery mechanism behind it; an infrastructure choice inherited from an earlier project without checking whether the reason for it still applied; and, the one that mattered most, two live, silent account-duplication bugs that only surfaced when I asked the identity question directly. The seventh catch was about the tests themselves: they’d only ever passed by accident, against state left over from manual runs. A genuinely clean run, the way it would actually happen in CI, would have failed immediately.

BunTypeScriptPostgreSQLClaude CodePodman

Technical take

The two account-duplication bugs: (1) the OAuth callback wasn’t lowercasing the provider’s email before the account lookup, so a provider returning different casing than an existing password/magic-link account would silently create a second account instead of linking to the first. Every other entry point already normalized case, this one didn’t. (2) findOrCreateForMagicLink/findOrCreateForOAuth used find-then-insert, a real TOCTOU race: two concurrent requests for a brand-new email could both pass the find check before either insert committed. Fixed with ON CONFLICT DO NOTHING plus a fallback read, verified by firing both requests concurrently in a test and asserting they resolve to the same row. The test-isolation catch: the integration test suite had only ever been run against containers I was managing by hand across the session. When I built a real spin-up/migrate/test/teardown script, it immediately failed, because the store-level test file never called its own migration and had only "passed" against schema left over from earlier manual runs.

@insights (personal R&D, code-insights)

2026Founder-stage, AI-built

Caught my own tool wasting money, fixed it the same day I found it

Sole architect/builder

hidden cost left after the fix, was quietly spending extra on every single run

Same day

from finding the problem to a verified fix

checked: confirmed the fix actually worked, not just assumed it

Minutes

later, the fixed tool caught a real security issue on a client-style codebase

SituationI built a tool that reviews a codebase the way I would: scanning for real problems (security holes, hidden costs, technical debt) before they become someone else’s emergency. While going through its own build, I found something I’d missed: the tool itself was quietly spending extra money behind the scenes on every single run, money it never needed to spend.

ConstraintThe whole point of what I build is that it should be provably leaner and more disciplined than the alternative. A tool that secretly overspends on itself undercuts that promise, and it’s exactly the kind of thing that hides in plain sight unless someone actually goes looking.

Decisions & Trade-offs

01Didn’t just patch it quietly: wrote down exactly what was wrong and why, the same way I document a finding for a client.
02Fixed the actual cause the same day, not a workaround.
03Checked my own work twice before calling it done: confirmed the extra cost was genuinely gone, then ran the fixed tool for real to make sure nothing broke.

ResultZero hidden cost, found and fixed in one sitting. I then put the fixed tool straight to work on a real, aging codebase and it flagged a genuine security issue, exposed passwords, within minutes. Same standard I hold for a $250 build or a $30M platform: find it, fix it, prove it.

RustClaude CodeCargoADR-driven designView repo →

Technical take

The tool’s synthesis step was calling Gemini/Anthropic directly with its own API keys, duplicating model access the calling agent (Claude Code) already had via subscription. Wrote it up as ADR-0006, replaced the owned API calls with a handover pattern (binary stages structured findings + a render request; the calling agent writes the prose), and verified the dependency tree actually shrank: Cargo.lock -575 lines, -1,210 net lines workspace-wide, two owned API keys and two CLI flags eliminated. Re-verified by running the fixed tool end-to-end against a ~4,000-file OSS repo (Zed) and a 9-year-old legacy Node codebase, confirming the cost fix cost nothing in capability.

@Cedar & Sage

2026Fast, flat-fee build

Live yoga-studio site, built and deployed in under a day

Sole builder: design, build, deploy

< 1 day

from brief to a live, deployed site

$250

flat fee: no hourly billing, no scope creep

round of revisions included, no endless back-and-forth

SituationA small yoga studio needed a real, working website, not a template dump, and not a redesign project with the budget or timeline of one.

ConstraintA fixed budget, a fast timeline, and one owner with no time for a multi-week back-and-forth over drafts.

Decisions & Trade-offs

01Built on Astro and Tailwind for a fast, lean static site rather than a heavier CMS stack the studio would never need to touch.
02Scoped to one page, built to convert, with the contact form wired straight to the owner’s inbox.
03Deployed live within the same engagement, not handed over as files for someone else to launch.

Resultcedarandsage.com.au live and deployed in under a day, the proof point behind the $250 flat-fee offer, not just a claim.

AstroTailwind CSS

@foodii (Star and Stream)

2026Founder-stage, fast build

Built a dignity-first recipe and ingredient-box pilot for a community paying 3x for food

Sole architect/builder: product, data model, build (Claude Code)

100

recipes curated from a 1,625-recipe corpus, nutrition fully recomputed

654

distinct source recipes triaged down to the curated wave-1 set

legacy nutrition numbers trusted: every value recomputed from USDA data

~300

households: the ingredient-box pilot’s target scale

SituationStar Valley Food Solutions, a community group in Star Valley, Wyoming facing food prices roughly 3x normal, needed a practical tool, not another recipe blog with no path to real savings.

ConstraintA dignity-first brief set up front: no shame language ("budget"/"cheap"/"guilt-free"), no body-shame tooling (no body-fat %, no ideal-weight calculators), permissive-license-only data, and legacy nutrition numbers from the source corpus that couldn’t be trusted as-is. The eventual ingredient-box model also had to map real Costco SKUs, including multi-packs, down to a per-household split.

Decisions & Trade-offs

01Recomputed nutrition for every recipe from structured ingredients via USDA FoodData Central instead of trusting inherited numbers.
02Set curation-acceptance criteria (budget-friendly, shelf-stable, nutritious) as a scoring-rubric gate, not a nice-to-have, before any recipe shipped.
03Designed a Costco SKU → FDC id → pack-size data model with a sub-unit concept, so one bulk purchase unit can split across multiple households’ orders instead of forcing one household to take the whole multi-pack.

ResultShipped a curated wave-1 set of 100 recipes from the 1,625-recipe corpus with fully recomputed nutrition; pilot committed at ~300 households. Cost-per-serve and Costco-makeable filtering became the actual differentiator over "another recipe site."

Next.jsDrizzlePostgreSQLBunUSDA FoodData Central APIClaude Code

Technical take

Serving-size math follows the FSANZ per-100g convention rather than trusting declared per-serve numbers, since serve sizes are manufacturer-arbitrary. The Costco SKU model needed a subunit_count/subunit_grams pair, not one pack_grams field, because Costco packs are frequently multi-packs of smaller divisible units (e.g. broccoli sold as one purchase unit containing four 1lb bags). Without that split, the hub couldn’t divide a single bulk purchase across multiple households.

@Keyin College

May 2023 - Jan 2025Zero-to-one build

Replaced fragmented manual ops with a platform: ~90% faster deploys

Project & Engineering Lead, Digital Operations

~90%

reduction in deployment cycle time

< 5 min

recovery time objective (RTO)

environment drift after standardisation

SituationAcademic and operational teams ran on fragmented, manual processes, with enrollment and admin work spread across disconnected tools. Every release risked environment drift, and there was no reliable recovery path if something broke.

ConstraintLive academic and operational teams that could not tolerate downtime during term, a graduate-heavy delivery team new to modern DevOps, and no existing CI/CD or backup discipline to build on.

Decisions & Trade-offs

01Consolidated onto a single centralised platform (Node.js, PostgreSQL, React) instead of patching the existing tool sprawl.
02Standardised on Docker and CI/CD to make environments reproducible: eliminating drift as a class of problem rather than fixing it case by case.
03Engineered automated backup and recovery to a < 5-minute RTO, treating recoverability as a first-class requirement, not an afterthought.

ResultCut deployment cycle time ~90% and eliminated environment drift. Automated backup/recovery brought RTO under 5 minutes. Reliability, performance, and delivery velocity improved across academic and operational teams.

Node.jsPostgreSQLReactDockerCI/CD

@Mobecom / LifeIQ

Oct 2016 - Jun 2018Enterprise scale, proven

Rescued a 200K-client platform under a 14-day shutdown deadline, then helped scale the group to 6M+ users

Technical PM → CTO (LifeIQ) → Group Head of Technology (Mobecom)

downtime relaunching the 200K-client platform under a 14-day deadline

~90%

infra cost cut (~$5.5K → ~$500/mo) at 5M-user scale

6M+

users across the group

~$30M

group revenue; acquired

SituationI joined LifeIQ as Technical Product Manager and was promoted to CTO within six weeks. An outsourced overseas vendor (billing US$30K/month) had built and hosted the Ruby-on-Rails platform serving 200K clients and, amid a commercial dispute, gave notice it would shut the platform down within 14 days. The business was weighing whether to close entirely.

ConstraintA hard 14-day deadline to stand up a replacement, 200K active clients who could not be disrupted, and the company’s content and operational data locked inside the vendor’s system.

Decisions & Trade-offs

01Made the call to rebuild rather than wind the business down, securing the company’s content and data ahead of the deadline so a rebuild was even viable.
02Hired and led a small team and personally owned architecture, code review, and technical oversight of a fast Node.js rebuild.
03As Group Head of Technology, re-architected the group’s AWS infrastructure (Endless Rewards, 5M users) to demand-based auto-scaling: capacity on demand, not always-on 24/7.

ResultRelaunched the platform with zero downtime as the old system went dark. Cut infrastructure spend ~90% (~$5.5K → ~$500/month) at 5M-user scale, then expanded into multiple product lines on a shared backend. The group (Mobecom) grew to 6M+ users and ~$30M revenue and was acquired.

Node.jsAngularPostgreSQLMongoDBAWS EC2Auto-scaling

@Secure Code Warrior

Aug 2019 - Jul 2020Enterprise scale, proven

Recovered a global program 6 weeks behind, then 3x’d QA throughput

Senior Software Engineer / Senior Cloud Architect

6 wks

behind schedule → delivered on time

~300%

QA throughput increase

~50

engineers aligned across 10 locations

ISO 27001

certified: final technical authority

SituationBrought in as technical 2IC to the VP Engineering. Two coupled programs, ISO 27001 certification and the "Future Ready Platform" (ephemeral QA environments), were 6 weeks behind schedule, with ~50 engineers across 10 global locations building against divergent standards.

ConstraintA slipping certification deadline with external auditors, no shared architecture baseline across sites, and QA bottlenecked on shared, long-lived test environments that serialised every team’s work.

Decisions & Trade-offs

01Chaired an Enterprise Architecture Board to standardise architecture and tooling first (alignment before acceleration) rather than throwing hours at a moving target.
02Introduced ephemeral, per-branch QA environments so testing ran in parallel instead of queuing on shared infra.
03Architected zero-downtime CI/CD on Azure DevOps + AWS and drove the transition toward a monorepo to kill environment drift.

ResultRecovered the program and delivered on time. Ephemeral environments lifted QA throughput ~300%. Served as final technical authority during the ISO 27001 audit, which passed.

TypeScriptAngularMongoDBAWSAzure DevOpsMonorepo

Open to work, available now

Have an idea, a prototype, or an AI-built MVP that needs to hold up?

Open to embedded, fractional, and contract work, Sydney-based, remote worldwide, with work rights in Australia and Canada. Happy to walk through any of these systems: decisions, diagrams, and all.

Get in touch