Building Things Only I Will Ever Use

I’m very aware I built something probably only useful to me.

And I’m learning to be okay with that.

Yesterday afternoon I shipped my first public GitHub repository. A semantic image search tool built in two hours while doing my actual job at the Himalayan Trust.

The tool solves exactly one problem: finding photos in our horrendously organized SharePoint archive while building content calendars.

It probably won’t change anyone’s life.

But it changed my workflow.

And maybe that’s enough.

Here’s what content creation looked like before.

I’d draft a week’s worth of LinkedIn posts and Instagram captions. Themes locked in. Messaging aligned. Calendar looking clean.

Then I’d open SharePoint.

And lose an hour.

Scrolling through thousands of unlabeled photos. Folders organized by… who knows. File names like IMG_2847.jpg and DSC_0192.jpg. No tags. No metadata. No search that actually worked.

I needed a photo of kids in a classroom for an education program post.

SharePoint gave me 47 results for “classroom” and none of them were classrooms.

This wasn’t just annoying.

It was a tax on creative work.

Every content calendar became a photo scavenger hunt. Every post draft stalled at “insert image here.” The friction between idea and execution wasn’t strategy or writing—it was file management hell.

I’d been complaining about this for months (which, let’s be honest, is my default state with SharePoint).

Then I had two hours and decided to fix it.

This is all I had.

Two hours on a Wednesday afternoon.

Content calendar due Thursday morning. Three meetings scattered across the day. Slack pinging. The usual chaos.

Most people would’ve kept scrolling through SharePoint. Or bought a third-party DAM tool and spent a week configuring it.

I opened Claude Code and started building.

Here’s the thing about constraints: they force clarity.

I didn’t have time to build the perfect solution. I had time to build something that worked. Semantic search using CLIP embeddings. FAISS for vector similarity. SQLite for metadata. Done.

No fancy UI. No user onboarding. No feature creep.

Just: describe what you want, get results instantly.

The constraint didn’t limit the solution. It sharpened it.

This is the part that still feels weird to explain.

I wasn’t coding for two hours straight.

I was running growth for a nonprofit while Claude Code built a Python MCP server in the background.

Write a quick PRD—thirty seconds. “Build semantic image search using CLIP. Index SharePoint folder. Return ranked results based on natural language queries.”

Claude Code starts working.

Switch back to my actual job. Answer Slack. Review a campaign. Draft an email.

Check in ten minutes later. Read the code. Ask questions. Adjust direction.

Claude Code keeps working.

Back to my day job.

I’ve started calling this “double working.” Two processes running in parallel. One human, one AI agent. You make progress on two things at once—not by fragmenting attention, but by knowing when to direct and when to let the agent run.

It’s not magic. It’s orchestration.

(But it feels a bit like magic.)

Here’s what people get wrong about AI-assisted building.

Lower barriers don’t mean less discipline.

They mean more.

I wrote a PRD for a two-hour project. Not a long one—maybe 200 words. But clear. Specific. Structured.

Without it? Spaghetti code solving the wrong problem.

With it? Clean Python, proper architecture, reusable components.

The tool lowered the barrier to building. But the discipline requirement went up.

You still need to know what you’re building and why. You still need to articulate it precisely. You still need to review the output with a critical eye.

This is the paradox: modern tools accelerate building, but they punish ambiguity harder than ever. Speed amplifies whatever you feed it—clarity or confusion.

For years I wished I’d studied computer science instead of architecture.

I thought I’d backed myself into an odd corner. Too technical to be just a marketer. Not technical enough to be a proper engineer.

A misfit.

Then tools like Claude Code arrived, and something clicked.

I don’t need to be a Python expert to build a working MCP server. I need to understand the problem clearly, describe the solution well, and review the implementation critically.

Architecture degree? Helps with systems thinking and structured problem decomposition.

Growth role? Helps with identifying real user friction.

AI-assisted coding? Bridges the gap.

Plot twist: the generalist wasn’t the problem. The environment just wasn’t built for us yet.

Now it is.

I built a production tool in two hours while running growth strategy. Not because I’m special—because the tools finally reward this particular shape of brain.

I could’ve bought a tool.

There are dozens of DAM systems. Most of them would work fine. Some even have AI search now.

But I didn’t want to buy a tool.

I wanted to build one.

Not because it’s cheaper. It’s not—my time costs more than a $20/month SaaS subscription.

Not because it’s better. Probably not. My v0.1 is rough around the edges.

I wanted to build it because I wanted to learn.

There’s a concept I keep coming back to: building sovereignty. It’s the idea that you optimize for capability and autonomy over convenience. You choose the harder path on purpose—not from masochism, but because the skills compound.

Here’s the underlying assumption: every tool you buy embeds someone else’s opinion about how you should work. Every tool you build is a chance to think for yourself.

This isn’t anti-SaaS. I use plenty of tools. But when the problem is specific enough and the learning is valuable enough, I’d rather build.

Even if I’m the only one who ever uses it.

This is my first open source project.

That sentence feels weird to write.

I’ve built things before. Lots of things. But always private repos. Always internal tools. Always just for me or my team.

Publishing this felt vulnerable.

The code isn’t perfect. The README could be better. The repo probably looks amateur to actual engineers.

But I put it out there anyway.

Because I’m trying to become someone who builds in public. Someone who shares half-baked ideas and invites collaboration. Someone who cares more about learning together than looking polished alone.

This is the first of (hopefully) many.

And honestly? I’m hoping to meet people who care about the same weird problems. People building tools for themselves. People solving niche workflow friction. People who’d rather learn than buy.

If that’s you, reach out. I’d love to compare notes.

No good project is ever finished.

Especially when you’re your own user.

I’m already thinking about v0.2.

Next iteration: index keyframes from video files. Same semantic search, but for finding specific moments in footage. Makes creating Reels and TikToks faster.

After that: layer in ReCraft or maybe Figma’s API. Generate branded assets on the fly. Combine search results with design automation.

I have no idea if I’ll actually build these.

But I know I’ll keep iterating. Because the tool serves me, and my needs keep evolving.

That’s the beauty of building for yourself: you’re never blocked waiting for a feature request to get prioritized.

You just build it.

I’m still not sure if anyone else will ever use this tool.

Maybe it’s too specific. Maybe the setup is too technical. Maybe the problem only exists in badly-managed nonprofit SharePoint archives (though I suspect there are more of those than anyone admits).

Maybe I built something only I’ll ever use.

And you know what?

I’m okay with that.

Because I learned how to build MCP servers. I learned how CLIP embeddings work. I learned how to orchestrate AI agents while doing other work.

I learned by building. And the next thing I build will be better because of it.

Building sovereignty isn’t about creating the next unicorn startup. It’s about solving your own problems first, learning in public, and seeing who shows up.

If you’re building weird tools for yourself, I want to hear about it.

Hit reply. Show me what you’re working on.

Let’s build in public together.