What to Build?

Something fairly funny and a little uncomfortable is happening to me: I can build more and more things, and I don’t necessarily have a clearer sense of which one I want to build.

An idea shows up, I explore it, I start to understand how it might work. Along the way I find another possibility. And another. What looked like a fairly contained project starts to grow branches, some more interesting than the original idea.

I have to choose which way to go.

AI tools have a lot to do with this. Knowledge is available, and now I have something to interrogate it with, take it apart, and start applying it. I can walk into a topic I barely know, ask the most basic questions without embarrassment, and before long be trying something.

That step from curiosity to a first test got very short. I love it. It also leaves me facing a question I can’t find as comfortable a button for: among everything I can do, what do I want to spend serious time on?

When I think about creating a software product, several desires get mixed up.

I want it to be useful. I want to enjoy building it. I’d like it to become a business. And I care that it has enough runway to keep going deeper, so the first version is the beginning of something.

I spend a lot of time trying to find an idea that can carry all of that. Understanding what need it serves, who cares, what alternatives that person has, and why they would choose what I’m making.

That’s where the work starts to feel interesting to me. Technical ability still matters, but I increasingly have tools to push through it. Interpreting a need, choosing a segment, and recognizing where value sits demands a different kind of attention.

AI can help me research, discuss, and sort possibilities. But the decision to bet on one still sits with me. I have to trust my intuition enough to give it months, without yet having much proof that I’m looking in the right direction.

On top of that, I’m trying to understand what shape a product should take in a market where the tools keep improving all the time.

A feature that today requires building a specific solution may ship tomorrow inside a general-purpose model. That changes the product’s possibilities and what someone would be willing to pay for it.

I want to think about that condition from the start. If available capabilities keep growing, where is it worth building? What can I take advantage of in them? What would I have to contribute so the product keeps its value as those capabilities become more common?

That’s where a question shows up that has me pretty entertained: how deep technically is it worth going?

My first intuition is that more specialized software, which knows a problem better and solves more of it, should have more runway. But I quickly have to correct myself a little. I can make something technically enormously complicated that doesn’t change anyone’s life.

That would be a shame. And a lot of work.

The amount of code doesn’t seem like a very reliable measure of value. Neither does the number of things a product does. I could spend months adding features and still not properly solve what actually matters.

So I start thinking about depth another way: how much the software understands of the work it was created for. Whether it accounts for the situations that show up in practice. Whether its outputs help someone make a decision or do something next. Whether it fits the way someone works, without demanding they reorganize their life to use it.

Maybe that depth ends up requiring a lot of technical sophistication. Maybe some parts are surprisingly simple. I want to find where the difficulty worth solving sits.

There’s also the question of how to monetize it.

But before deciding how to charge, I need to understand what someone would be buying. How much it helps them, how often, what effort it saves them, what it lets them do that they couldn’t before.

I find it hard to separate that conversation from product design. If the value shows up only once, that should shape how it’s offered. If it accompanies work every day, the relationship is different. And if every customer needs a major adaptation, maybe I also have to rethink what kind of business I’m imagining.

These are questions I want to explore. I like that building software leads me to think about all these other things: habits, needs, decisions, money. Even if not all of them have a clear answer, or a single one.

Lately I found a fairly pleasant way to move forward in the middle of all this: solve a problem of my own.

I have access to the user: the dreamer writing this.

I know what I want to do, where I get stuck, and what feels uncomfortable. I can try a solution and find out quickly whether it works. Above all, I want to come back to the project because I care about using what I’m building.

That gives the process a different energy.

I can go deeper without having to commercially justify every detour. Follow a curiosity, try something that may not stick, discover that the interesting part was a little farther than where I’d started.

I don’t assume that because it works for me, it will have a market. That would be another question to explore. But in the meantime there’s a real need, someone using the product, and a reason to improve it.

Maybe it ends up monetizable. Maybe it stays a tool of my own. I like that both possibilities let the project be worth it.

Another of the branches that catches my attention is hardware.

The possibility of combining software with something that moves or acts on the physical world opens a pile of new questions for me. I see automatable tasks and want to understand what it would take to solve them. How far the software goes, what components are needed, how the parts connect.

Besides, that’s where AI progress can keep enabling new uses for an object. I find it very appealing to think of a physical product whose capabilities can keep growing through software.

Then I look a little further and materials, parts, prototypes, suppliers show up. The need to invest capital gets real fairly quickly. Sitting for a few hours in front of the computer and trying another version is no longer enough.

You have to buy things. Wait for them to arrive. Discover that something else was missing.

It’s a fairly unknown world for me, and I don’t want to romanticize it. But I’m drawn to exploring it. There’s something in that mix of programming and matter that makes me very curious. Being able to improve a piece of logic and see that, on the other side, something physical does its job better.

I understand perfectly that afterward you have to deal with making, delivering, and maintaining that object. For now I’m in the stage of wanting to know how it works. I’m going to let myself enjoy it for a while.

At times I feel like everything is already done, or at least that’s how it looks from my desk. Then I go out into the world and see there’s a lot of room for application. Many simple solutions that could be put in place.

That gap leaves me thinking.

On the screen I see finished products, launches, tools that do more and more. Outside I see jobs that are still cumbersome, needs that haven’t found a comfortable solution, and people who have more urgent or more important concerns than learning to use the latest model.

Between those two scenes there should be a lot of opportunity.

I don’t have an entirely clear sense of what shape the next thing will take. Software, hardware, some mix. I dream of it being useful and having real impact on people’s lives. I also want to keep that part of the process where one question leads to another and you end up learning something you hadn’t gone looking for.

For now I’m solving something I care about. A couple of branches have already shown up.

I’m going to keep exploring.