Two Kinds of Making

Four things I've built

Most of what I make lands somewhere between the two paths.

Job Radar

The problem. Searching LinkedIn the way I wanted wasn't possible, job postings were scattered across a dozen dashboards, and I was nervous about missing something.

Made with AI. A friend built a Claude routine that takes a list of companies and emails him matching openings every day. I loved it, but emails pile up, and I wanted a way to manage what I applied to or wanted to come back to. So I had Claude build a dashboard with shadcn, with the backend on Supabase, running locally.

AI inside. The refresh button triggers the Claude routine, which goes out to company careers pages and fills an inbox. From there I sort, use different views, and jump to LinkedIn to find someone for a referral.

Lifestyle: habit tracker and workout program

The problem. My habit tracking lived in a notebook. Great low-tech solution, until I had to carry it everywhere, including on a trip where I was short on space.

Made with AI. A habit tracker I can edit on the fly and open on my phone as an app. Same for the workout program.

AI inside. The workout side runs through my Obsidian second brain, where Claude knows my goals and the training I want to do. I talk through how the last program went, it updates my notes, and it generates the next plan, whether that's one week or sixty days. Then I hand the plan to a Claude Code session and it adds it to the app.

The lesson. These started as one app. I split them because they have different lifespans. The workout plan resets constantly, and I didn't want to touch the habit database every time.

Wedding planning app

The problem. My fiancée and I needed one place for guest list numbers (we're capacity-limited), inspiration for the vibe and the invitations, and the budget. It also powers our wedding landing page.

Made with AI. The whole thing. We dumped information in bulk through Claude, and now we use the database day to day.

AI inside. None. It has local APIs, analytics, and tracking, but no LLM. It's a clean example of path one.

The lesson. Early on I tried to do too much. I wanted AI everywhere, even a generative UI, and I'd tried putting a Claude chatbot directly into an interface on an earlier project. It didn't work well. It taught me to draw boundaries around what I ask AI to do.

Offer Writer

The problem. I was at my mom's house and she'd been working on a real estate contract for two hours. I thought, there has to be something for this. I knew Claude could do it, because I'd had it work inside a browser and complete the information.

Made with AI. A Chrome extension, released in the Chrome Web Store, that works inside a tool agents already use.

AI inside. It's the whole product. It's trained on the contracts in that platform. An agent gives it a screenshot of a text, a voice recording, whatever they have, and it fills in the contract. It asks disambiguation questions, then flags fields green, yellow, or red, with a clickable list in the chat that jumps to each field to review.

The lesson. I built it as a plugin inside an existing process on purpose. I've worked on a real estate startup, and I learned how hard it is to get people to move into an overbuilt ecosystem. This is a working MVP, and there's more to do, like mobile.

⁂

Where the two paths meet

They don't stay separate. Trying to overbuild the AI part of one project taught me a boundary that made my next builds cleaner, and it gave me a habit I now follow: make it a skill first.

Before there's any UI, I run the task in Claude, refine the instructions, and see whether Claude can actually do the thing. Claude is the sidecar. Once I trust it, I can wrap an interface around it. Offer Writer went exactly that way. And eventually, the sidecar and the tool can come together into something more generative.

⁂

How I decide whether AI goes inside

My default is no AI. Every LLM call costs something, and part of why I love this is that I can build solutions to my own problems without them getting expensive to live with.

But it's not really about cost for its own sake. It's about the functional use case. Can I solve it without AI in an MVP? If yes, I do that first, and if it earns it, AI can scale in later. The path is: build it lean for myself, show it to a friend, and if there's real interest, make it cost a little more to run and maybe make it worth money.

⁂

Same process, different focus

This applies on both paths. Design is well positioned to work with stakeholders to understand the criteria: what it needs to do, who it's for, what good looks like. Then to make with that in mind. Engineering carries the concerns that don't go away because a designer can now build a working version: scalability, security, and the technical soundness of how the functionality gets made. Same process, different focus. The tools just let both sides get into the work together, earlier.

⁂

Build for yourself

Every project above exists because I had the problem. That's the best brief there is. You're the user and the tester, so you find out fast whether it works. You do your own dogfooding and your own validation.

So look at the problems in your own life and make solutions. Share what you're building, talk about it, and have fun. Or, as Abhishek Shankar says, build cool shit.

⁂

Open questions

Scalability. I don't fully know what it takes to turn something like this into a releasable product: the interfaces, the security protocols, the admin layers. I'm still learning the technical side as a designer, improving my GitHub practices, cleaning up my code, and managing databases.

When it's worth the cost to grow. My answer for now is lean first, validate with people, then invest. I don't think I've settled the hard part, which is knowing when the signal is strong enough.

⁂

Where I think this goes

I wonder how many more design founders we'll see because of this. Building has never been cheaper, and founding has always needed what designers are trained in: human empathy, gathering feedback, and iterating.

I hold that next to real ethical and moral concerns, and next to a worry about over-relying on these tools. That's part of why I'm taking courses and learning to code without AI, so I can actually validate what I'm making instead of just trusting it.