I build with Claude. Here's what that actually looks like.

If you read the Ghostbase code, you'll find commits that make it obvious I built a chunk of it working with Claude. I'm not hiding that, and I'm not going to — it's part of how I work now, and pretending otherwise on a personal project would be a strange thing to fake on the one piece of software where I answer to no one but myself.

What "built with Claude" doesn't mean

It doesn't mean I described a feature and copy-pasted whatever came back. On Ghostbase, most of the interesting engineering decisions — the ones I'd actually put in a portfolio — came from a back-and-forth: I'd describe the problem, Claude would propose an approach, and I'd push back on the parts that didn't fit how the rest of the system worked, or that I just disagreed with.

The Simkl cache layer is a good example. Simkl's API guidelines ask integrators to cache responses and poll sparingly rather than hit the endpoint on every page load — reasonable, since it's a free API serving a lot of projects like mine. The first pass cached responses and called it done. I pushed back: a cache that goes stale silently is worse than no cache, because now I don't even know something's wrong. What we landed on together — a SQLite cache with a full-library fallback snapshot and a background refresh every 24 hours — was better than either of our starting points, and it means Ghostbase stays a well-behaved consumer of Simkl's API instead of a noisy one.

What it's actually good for

• Getting from idea to working code fast, especially for the parts of a project that are necessary but not the interesting part — schema boilerplate, a first pass at an import script, wiring up a new API client
• A second opinion, on demand, at 11pm — when I'm stuck between two approaches to a caching problem and, working alone, there's no one else to ask
• Catching the boring bugs — the off-by-one in a migration check, the edge case in a webhook handler — so I spend my attention on the decisions that actually require judgment

What it's not good for, in my experience

Claude doesn't know Simkl's specific rate-limit and caching guidelines until I tell it. It doesn't know which parts of Ghostbase I'm precious about and which parts I don't care about. It doesn't know that I'd rather ship an idempotent ALTER TABLE at startup than pull in a migration framework for a single-developer SQLite project — that's a taste call, and taste is still mine to bring.

The work that actually took judgment on Ghostbase — deciding what the product even should be, which trade-offs matter for a project only I maintain, when "good enough" really is good enough — that part didn't move. It couldn't. Nobody else has to live with this codebase, so nobody else gets to make those calls.

Why this matters for how I'll build for you

This is the same workflow I bring to any project I take on: AI-assisted for the boilerplate and the second opinions, my judgment for the architecture and the trade-offs that determine whether the thing still makes sense in a year. Ghostbase is just the place I can show you that honestly, because there's no confidentiality in the way — you can go read the commits yourself.

If that's not how you want your software built, that's a completely fair position, and worth telling me upfront. If it's not a dealbreaker, it's part of why I expect projects with me to move faster than a quote built around old assumptions about AI-assisted development would suggest.

Want to know exactly how a project of yours would get built? Ask me directly — I'll tell you straight.