I think I’ve found a way to create software that’s actually useful.

But to do that, you have to be doing useful work yourself.

Here’s what I mean.

I’ve been writing consistently for the last couple of months.

I enjoy the process, but I wanted to increase volume.

So I began systemizing it.

That’s when I ran into friction.

There were steps I kept repeating.

Things that could be condensed into one click.

If I had software that understood my process, it could eliminate these small frictions.

And that’s what I proceeded to do.

Over these months, I have created 4 chrome extensions and two python scripts that help me out in various tasks.

Albeit their function is not limited to just help me write.

Each with good potential to gain traction if done well.

That’s when it hit me.

Useful software doesn’t come from brainstorming.

It comes from building systems around things you already do at scale.

If you are doing something valuable and you’re trying to scale it

You will naturally run into inefficiencies.

And once you start creating systems to handle those inefficiencies, you’ll begin to see exactly where software fits in.

Software becomes obvious once the process becomes real.

That’s why this approach works:

Start by doing something useful.

Then try to do it at volume.

Then build a system around it.

Then add software into the system to remove drag.

It’s a loop.

Action → Friction → Solution.

But here’s the bonus most people miss:

You don’t just build better software this way.

You also build a sharper product-market fit.

Because when you solve your own problem, you already know the user.

You are the ICP.

You know how they think, what they struggle with, and what they’ll pay for.

You don’t need to imagine the market. You embody it.

This changes how you sell.

You won’t need 50 customer interviews.

You won’t need cold guesses about positioning.

You’ve already lived the pitch.

You’ll know what to say because you’ll know what you needed.

That’s the value of embodied cognition.

It’s not just better design

It’s also better distribution.

Because when you’ve walked the road, you know where it hurts.

So if you want to build software that actually matters and actually sells, start here:

Do something useful.

Try to scale it.

Build a system.

Watch for the bottlenecks.

Then build the tool that clears them.

You’ll solve a real problem.

You’ll know the exact user.

And your product will be something that speaks for itself.

Because it was built where the work was.

Plus, for the extensions and scripts I mentioned earlier

I see them being useful in many, many domains including than the ones I intended.

So who knows what pot of gold you might hit.

Maybe this also explains something about the rise of internet gurus.

A lot of them were entrepreneurs before.

They’ve already gone through the system.

They’ve felt the bottlenecks.

Now they make money talking about those frictions to educate others on solving them.

Because once you’ve lived the chaos, it’s easier to sell clarity.

They just turned their experience into content.

Same way, if I build software to solve my own friction, it might end up being valuable to others too.

And maybe, at some point, I’ll be the one sixing friction in other people’s system via SaaS.

That’s how the cycle works.