What I'm building, and how
Stripe is genuinely one of the best companies I've ever been around. The people, the standards, the pace, the ambition. I learned a lot and have nothing but respect for the place.
But I've had an itch to build something on my own for a long time. So I'm taking a few months to do it.
No immediate next role lined up. No grand master plan. Just a deliberate experiment: sprint to build a portfolio of small software businesses.
The thesis
People lose money, waste time, and make avoidable mistakes all the time. Not because answers are impossible to find, but because they're scattered across PDFs, websites, phone calls, tribal knowledge, and tools nobody really likes.
Eventually, everyone just accepts it. "That's just how it works."
I've started thinking of this as the "it's always been this way" tax.
AI makes these problems more interesting to go after. Not because AI is magically the product, but because it lets one motivated person build a more complete, polished, useful product than would have been realistic a few years ago.
What I'm looking for
Before I build anything, it has to clear a pretty simple filter:
- Is it a real problem people need to solve, not casually browse?
- Is there a clear financial or operational payoff?
- Does the answer already exist, but in a form that's hard to find, trust, or act on?
- Are the current tools fragmented, outdated, or built for experts?
- Does AI make the experience meaningfully better?
- Can I build and validate it in 4 to 8 weeks?
The first product: LabLookup
My wife had the idea several months back and I helped her prototype a solution and now we're turning it into a real product.
She's a nurse practitioner and lives this problem every day.
When a medical office draws blood, there's a surprising amount to get right: which tube, how much blood, what order to draw in, how to store the sample, which lab order code to use. Get one thing wrong and the lab can reject the specimen.
So we're building LabLookup.com.
The stack
I'm not an engineer but I've built and managed a lot of digital products over the years.I've worked around product and engineering teams for a long time, but I've never been the person writing and shipping the code myself.
That changed.
LabLookup is built on Next.js, React, TypeScript, @supabase , @clerk , @stripe , @resend , @posthog , and @vercel. It has auth, billing, health monitoring, automated tests, admin tooling, and production alerts.
Claude helps with.... everything.
The /wrap ritual
The hardest part of building solo with AI is not writing code.
It's continuity.
A real team has code review, standups, shared memory, and other people around to catch sloppy thinking. Working alone, those rails disappear. And they disappear exactly when you're most likely to cut corners: late in a session, when you're tired, the thing mostly works, and you just want to close the laptop.
So I created a skill to run the end of every session: /wrap
It forces the boring-but-important stuff to happen every time.
- Commit the work.
- Push the branch.
- Open the PR. Run the build.
- Run the tests.
- Update docs.
- Save project memory.
- Summarize what shipped, what was verified, and what's still open.
- Then generate the starting prompt for the next session and suggest which model to use.
The self-improving loop
This is probably the part I'm most excited by.
Most products don't fail because founders lack ideas. They fail because the improvement loop is exhausting or too time consuming. Collect feedback. Interpret it. Prioritize it. Turn it into a spec. Build it. Test it. Ship it. Repeat forever.
That loop is especially hard when you're one person.
So I'm building the loop into the product for agents to handle.
Users can flag issues or ideas directly in LabLookup: a data correction, a confusing screen, a bug, a feature request. Claude triages the feedback, categorizes it, scores priority, and drafts a structured implementation spec with acceptance criteria.
I get a ranked queue. My job is not to do all the labor. My job is to apply judgment and taste. If I approve something, the spec is already written and ready to hand to the coding agent.
Real user signal goes in one end. A shipped improvement comes out the other.
That feels like the shape of a lot of future software companies: humans doing the judgment and taste work, AI doing more of the mechanical translation from signal to shipped change.
Building for reuse
One decision I'm glad I made early: separate the platform from the product.
The platform is the reusable machinery every software business needs: accounts, auth, billing, email, analytics, AI plumbing, health monitoring, admin tools. The product is the LabLookup-specific layer: lab catalogs, collection requirements, lookup flows, rejection-risk logic.
Those two layers stay separate.
That took more effort up front, but it means the next product does not start from zero. The boring infrastructure is already there. The next product gets to be a much thinner layer on top.
What's next
A few more weeks focused on LabLookup prior to kicking off my next product likely focused on property tax appeals.
The rough idea: help homeowners understand whether their home is overassessed, find comparable properties, and prepare a cleaner appeal without needing to become an expert or hire a consultant.
It fits the same pattern. The answer often exists, but it's scattered across county websites, property records, PDFs, rules, deadlines, and local process quirks. Most people don't appeal because the process feels annoying, confusing, and not worth the effort.Classic "it's always been this way" tax.
I'm open to conversations
For now, I'm sprinting and enjoying the experiment.But I'm keeping a window open.
If you're building something interesting and want to talk, collaborate, or something more formal, I'm open to it. Same if you're at a company working on something that sits near strategy, product, operations, fintech, AI, and have a potentially interesting role in mind for me eventually.