Why I Built A Side Project Nobody Asked For (And Shipped It Anyway)

Building something nobody wanted

I shipped a side project recently that literally nobody asked for.

No waitlist. No user interviews. No imaginary target persona called "Sam, 32, productivity enthusiast".

It scratched a very specific itch that only I seemed to care about. I built it anyway. In public. On purpose.

If you only ship things once the market begs you for them, you end up stuck in research mode forever. I got tired of that. I wanted more reps, not more perfect ideas.

What I actually built

I will start concrete. The project is a tiny web tool that tracks my deep work sessions and mood over time, then overlays them with my Git commits and training load.

I am a developer, a builder, a biohacker, and I coach baseball. My days are a weird mix of code, caffeine experiments, strength work, batting cages, and client calls. My attention is the bottleneck. Not ideas. Not tools.

I wanted a single timeline that answered one question: what conditions actually make me do good work?

So I built a minimal internal dashboard:

• Manual deep work sessions with tags like frontend, writing, coaching.
• Simple mood check-ins: one slider, no cute emojis.
• Pulls Git commits from GitHub for specific repos.
• Pulls training data from my wearables and a basic spreadsheet where I log workouts.
• Plots it all on a weekly heatmap so I can see patterns without thinking.

No social login. No billing. No AI summary. Just a private tool that answers questions I actually ask myself.

Zero people asked me to build this. Most people do not want more tracking. I do. For now.

Why I built it anyway

I could say I did it for the data insights. That would sound smart. It would also be half true.

The real reasons were messier:

• I wanted to ship something small, opinionated, and slightly weird.
• I wanted more practice finishing things, not starting them.
• I wanted a playground for my stack where I was the only stakeholder.
• I wanted a forcing function to check my own biohacking bullshit.

Shipping for yourself is underrated. Not as a romantic idea, but as a very practical training tool. There is no better way to discover your own bullshit than to dogfood it daily.

I see a lot of people stuck in side project limbo. Big Notion docs. Miro boards. Backlogs for products that do not exist yet. They wait for proof that someone will care before they touch a line of code.

I think that is backwards for individual builders. The value is in the reps, not the guaranteed audience.

Build in public, even when nobody cares

I build in public by default. That does not mean I turn everything into a polished content funnel. It mostly means I show the messy bits while they are still messy.

For this project I did three simple things:

• Posted a short Loom of the first ugly prototype to X and Mastodon.
• Pushed the repo to a public GitHub with an unpolished README.
• Logged small updates in a changelog-style thread instead of tweeting finished features.

None of that was for marketing. There is no audience for "Richard's weirdo productivity dashboard". The audience was me, plus whoever happens to care about process.

Building in public helped in three specific ways.

1. It kept me honest about scope

"Week one" me wanted a full tracking suite with onboarding, presets, and a social layer where you can compare deep work scores with friends.

"Public" me wrote a very blunt first post:

Goal: log deep work + mood + training volume, display on one timeline, ship in 10 days, no accounts, no payments, no integrations that require OAuth, I am not building a quantified self platform.

That sentence killed at least five rabbit holes. Adding public accountability to the scope made it harder to lie to myself.

2. It gave me tiny feedback, not big asks

Because I repeatedly said "this is for me", people responded differently. No one asked for a roadmap. No one asked about pricing. People dropped tiny useful comments:

• "Your heatmap looks like crap on mobile."
• "Why not just use RescueTime?"
• "You will stop filling in that mood slider after two weeks."

That is the kind of feedback you need early. Not a 20-question survey. Just friction you can feel.

Also, the "use RescueTime" comment forced a good check: if a commercial tool already solves my problem with 80 percent quality, maybe I am just procrastinating. In this case I really wanted manual, subjective input, not constant passive monitoring. So I kept going.

3. It turned shipping into a public habit

I like using public threads as a visible timer. If I start a thread that says "building X in 10 days" then disappear for two months, it feels like a tiny failure. Not dramatic. Just enough friction that I think twice the next time I want to wander off into Abstract Idea Land.

For this project I kept a simple rule: every day I either posted a 1–2 line update or admitted I touched nothing.

It looked like this:

• Day 1: data model + rough UI sketch.
• Day 3: first deep work session logged, chart totally unreadable.
• Day 6: GitHub integration working, timestamps are wrong, timezone hell.
• Day 9: mood slider added, instantly regret making it too granular.
• Day 12: first full week of my own data, no one else is testing this, shipping anyway.

Nothing glamorous. Just receipts.

Shipping for yourself vs chasing imaginary users

When people say "validate the idea first" they usually mean "get strangers to tell you they might pay someday".

I think that can be useful for big bets. For small side projects, I think it is pure friction. It also encourages you to build for ghosts.

"My users will need X" is a nice way to hide from your own taste. You stop asking what you actually want to use, and start asking what the imaginary market expects.

Shipping for yourself flips that.

I made three conscious decisions on this project that a generic "user" would probably hate:

• No onboarding. You land on a blank screen with a form. If you are confused, good. Future me knows exactly what to do.
• No calendar integration. I do not want auto-logged meetings. Meetings are not deep work.
• No daily streaks. I am a coach, I know how streaks destroy nuance. I care about weekly and monthly load, not "did I click today".

If I had optimized for adoption, I would have done the opposite on all three. That is fine, but it would have moved the project away from the use case that actually matters to me.

Shipping for yourself forces priorities that feel selfish. I think that is healthy, especially early.

The boring technical stack (on purpose)

I treated the tech stack like an athlete treats equipment. Boring, reliable, familiar. The goal was more reps, not a new toy.

I used:

• Next.js with the app router.
• TypeScript, because I refuse to debug undefined in 2026.
• SQLite in development, Postgres in production via a managed service.
• Prisma for simple migrations.
• Tailwind for styling, plus a tiny component library I keep reusing.

Nothing special. That was the point.

I set myself a constraint: no new libraries unless I hit a concrete pain that justifies them. So when I wanted charts, I did not go on a library safari. I grabbed a lightweight chart lib I already knew and lived with its quirks.

This is a big part of why building for yourself is so useful. You can optimize for finishing, not for impressive tech. Nobody cares if I used the hot new CSS framework. Including me.

What actually changed for me

After a few weeks of using my own weird tool, some patterns slapped me in the face.

They were not subtle:

• My best deep work blocks cluster on days when I have some form of physical training before 11:00.
• My Git commit volume does not correlate with "good work". Writing days look empty in Git, but the mood logs tell a different story.
• Coaching nights tank my morning energy the next day unless I sleep at least 30 minutes more.

None of this required AI or fancy stats. I could literally see it in color on a timeline. That is all I wanted.

The bigger change though was psychological. Shipping something that nobody asked for reminded me that my own curiosity is enough reason to build. I do not need a trend report or a TAM slide.

I feel less pressure now to justify every project with "market potential". Some projects are practice. Some are toys. Some are internal tools that teach you how you actually work, not how you think you work.

Costs and tradeoffs

Shipping weird private tools is not free. There are tradeoffs.

• Opportunity cost: those 20–30 hours could have gone into a more monetizable SaaS idea. I am fine with that. Reps compound too.
• Maintenance: every shipped project is another thing that can break. I keep a strict rule: if I stop using it for 30 days, I shut it down or archive it. No zombie apps.
• Public perception: some people think side projects only "count" if they make money or go viral. Those are not my people.

I like having a graveyard of small, finished things more than a cloud of massive half-started ones. Shipping this project helped me keep that bias strong.

My build-in-public rules for selfish projects

If you are tempted to build something nobody asked for, here are the rules I actually followed on this one. They are opinionated on purpose.

• Set a stupidly small scope. If it does not fit in a 10–14 day window next to your actual life, cut features.
• Post ugly work early. First screenshot, first video, first commit log. Early embarrassment is a feature.
• Write one clear sentence about who this is for. Mine was "this is for me, not you". That helped a lot.
• Use boring tech you already know. If you want to learn a tool, call it a learning project, not a product.
• Ship when it is useful to you, not when it feels impressive. The bar is "does this change my behaviour" not "would this go on Product Hunt".

That is it. No growth loops. No launch strategy.

Why I will keep building things nobody asked for

I like markets. I build client projects. I care about real users. I am not anti-customer.

But I think individual builders get stuck worshipping the idea of "product-market fit" so early that they forget to practice the basics: finish, ship, observe, adjust.

This side project was not a company. It was a rep. A focused block of practice that gave me a tool I use and a clearer picture of how I work.

That feels like enough. More than enough, actually.

If you are sitting on a weird idea that only makes sense to you, I think you should build it. In public if you can handle strangers watching. In private if you cannot.

Not because the world needs it. Because you need more shipped reps than you need more perfectly validated ideas.

Ship something small that nobody asked for. Then live with it for a month. That feedback loop is where the real value hides.