I’ve been building HeyClaps for several months now. Solo, alongside a full-time job as a lead engineer. That’s not a humble brag — it’s context, because the question I get most often is: “How are you doing that?”
The honest answer is that AI tooling made parts of this possible that wouldn’t have been before. But not in the way most people assume. The gains are specific. The limitations are real. And the judgment calls are still mine.
Here’s what actually changed.
What HeyClaps is
HeyClaps is a Slack-native employee recognition product. The core premise: recognition should happen where work happens, not in a separate tool that people have to remember to open.
The recognition patterns I care about are the ones that get missed in most tools. Not the big quarterly awards — those happen anyway. The ones that disappear: the engineer who unblocked three other people during a tough sprint, the customer success person who handled a difficult escalation without anyone noticing, the quiet architectural decision that saved the team six months of work.
HeyClaps captures those moments in Slack, makes them visible to the team, and creates a record that actually gets used in performance reviews and 1-on-1s.
Spec-first development changed how I build
The biggest workflow change wasn’t autocomplete or code generation. It was spec-first development.
Before starting any feature, I write a spec. Not a long one — usually 300–500 words describing what the feature does, what it doesn’t do, what the edge cases are, and what done looks like. Then I use Claude to stress-test the spec before writing a line of code.
The spec review finds things I missed. Not creative things — structural things. “You said the recognition message is required, but you haven’t specified what happens if the Slack event arrives without one.” “You mention team-level visibility, but the data model you described doesn’t have a teams table yet.”
That feedback loop, which used to require a senior peer reviewer and a few hours of calendar coordination, now takes 10 minutes. The spec gets sharper before code starts. Bugs that would have been discovered in integration testing get found at the design stage.
Code generation: where it works and where it doesn’t
I use Claude for code generation, but I’ve stopped expecting it to write production code I don’t touch.
What it does well: scaffolding. Give it a spec and a file structure and it produces a reasonable starting point in seconds. That starting point is almost never right — there are always missing imports, incorrect assumptions about the ORM, type errors — but it’s much faster to fix than to write from scratch.
What it does less well: anything that requires understanding how the existing system actually behaves at runtime. The model sees what you show it. If you don’t show it the Slack event shape that comes in from a specific workspace configuration, it will invent something plausible that’s wrong.
The fix: I paste real data from logs and Slack’s API explorer into every request that involves external events. The quality of the generated code improves dramatically when the model is working with actual shapes, not assumed ones.
Architecture decisions: still mine
This is where I expected AI tooling to help the most, and where it helps the least.
When I was deciding whether to build HeyClaps on Supabase or PlanetScale, I asked Claude. It gave me a balanced comparison that would have been appropriate for a blog post but was useless for my specific situation. It didn’t know that I’d be building on a free tier for the first six months. It didn’t know that the Supabase Realtime feature was the one that made the Slack integration design work. It didn’t know how much I cared about the local development experience.
Architecture decisions aren’t about evaluating options in the abstract. They’re about understanding the constraints of your specific situation and making a bet. The model can surface tradeoffs I haven’t thought of. It can’t make the bet for me.
Debugging complex state: also still mine
The hardest bugs in HeyClaps are the ones that live at the intersection of Slack’s event delivery guarantees, my Supabase RLS policies, and the order of operations in my edge functions.
AI tooling helps me write the code that investigates these bugs. It helps me translate stack traces into hypotheses. But the moment of insight — “the event is being delivered twice because Slack retries on any non-200 response, and my edge function is returning 200 before the database write succeeds” — comes from reasoning about the system as a whole, not from autocomplete.
I’ve found that the best use of the model for debugging is to describe the bug, the system architecture, and what you’ve already ruled out. Then ask for hypotheses. It generates more hypotheses faster than I can. Some of them are wrong. Some of them send me down the right path.
Stakeholder communication: unchanged
The one area where I expected no change and got none: communicating with users and potential customers.
Writing a good email to a beta user who churned requires understanding their context, reading between the lines of what they told you, and knowing what you’re willing to change. That’s judgment, empathy, and product sense. The model can draft an email, but the draft reads like a draft. I rewrite it from scratch.
What solo with AI actually means
I’m not 10x faster. I’m not doing 10x more things.
What I am doing is spending my time differently. Less time on scaffolding and boilerplate. Less time writing specs that no one reads. More time on the things that actually require me: the product decisions, the hard debugging, the conversations with users.
HeyClaps is further along than I expected it to be at this point. That’s real. But the reason isn’t that AI wrote the product. The reason is that AI eliminated the parts of the job that were blocking me from the parts that matter.
If you’re a solo engineer building something, that’s the framing worth holding onto. The tooling buys you time. What you do with that time is still on you.
HeyClaps is currently in private beta. If you want early access, hit the button below.
