The First Problem I Faced Was Not Code

Before I started building my first app, I assumed the hardest part would be code. That seemed obvious: I had no programming background, I was not a developer, and I could hardly say that I understood technology in any serious way.

I was closer to a product-minded person. I could think about needs, pages, flows, and how someone might actually use a feature, but I had no idea how a real app was supposed to be built from the ground up. So when I decided to use AI to build a family finance app, I expected unfamiliar code to be my biggest obstacle.

Once I actually began, I discovered that the first thing to consume my attention was something else: uncertainty.

Too Many Tools, Too Little Confidence

At first, the AI tools I was using felt like a remarkable entry point. I could discuss product ideas, ask technical questions, and get explanations for things I would not have known how to approach on my own. Problems that once felt completely out of reach suddenly seemed possible to begin.

Then I started seeing more and more discussions about other tools. One model was said to be better for programming, another editor was supposed to be better for real development, and new tools kept appearing, each with its own strengths and enthusiastic users.

I began comparing them constantly. Had I chosen the wrong tool? Would my app turn out worse because I was not using the strongest model or the most advanced development setup? Were other people moving much faster simply because their tools were better than mine?

For an experienced developer, these questions may be ordinary choices about workflow. For me, they felt much larger because I did not have enough technical experience to know which differences really mattered. I could not easily judge the quality of a piece of code, and I did not know whether the gap between two tools would eventually determine the quality of the product.

Every new recommendation created the same feeling: perhaps the road I was already on was not the best one. The comparison did not make me clearer; it made me more anxious.

I spent time reading what other people thought about different models, editors, and development tools. I wondered whether I should change my entire setup before I had even gone very far with the one I already had.

The problem was that new tools never stopped appearing. Before I had fully understood one of them, another arrived that seemed faster, smarter, or more capable.

I slowly began to see that more choice does not always make a person more free. For someone without a strong technical background, it can also create a place where you keep choosing instead of building.

The Cost of an Unstable Environment

There was another layer of uncertainty around the tools themselves. Because of changes in the environment and conditions around the services I depended on, I had to adjust more than once just to keep the basic tools I was using available and stable enough to continue.

None of this had anything to do with the product itself. It did not help me design a page, fix a bug, or move a feature closer to completion, but it still consumed time and attention that I would rather have spent building.

For a while, one of my recurring concerns was no longer only, “How should I build this feature?” It was also whether the tools I depended on would remain stable enough for me to keep going.

These interruptions may look small from the outside, but for an independent builder, they can repeatedly break concentration. And attention is one of the most limited resources I have.

The uncertainty around tools and the anxiety about choosing them also began to reinforce each other. When I worried that one tool might not remain reliable, I wanted to prepare alternatives. Preparing alternatives meant trying more tools, and trying more tools meant comparing them again.

The more I compared, the further I moved away from the problem I had originally wanted to solve.

When “What Should I Use?” Replaces “What Should I Build?”

My original idea was simple: I wanted to build a family finance and giving tool.

But there were moments when I spent more energy thinking about what I should use to build it than thinking about why I was building it and what the product actually needed. That was one of the first lessons I learned from trying to build an app without a programming background.

I had assumed that not knowing how to code would be the biggest obstacle. Instead, I discovered that a person can lose a great deal of time and energy before reaching the hardest technical problem at all.

You can be slowed down by tool choices, by changing conditions, and by the constant fear that another setup might be better than the one already in front of you.

I am not saying that tools do not matter. They matter a great deal.

For someone like me, without a programming background, AI tools are one of the main reasons I can build at all. They give me access to technical work that would otherwise be far beyond my current ability.

But I am gradually learning that endless comparison does not automatically move a product closer to release. At some point, a tool has to become good enough for the work in front of you, and then the work has to begin.

Good Enough to Keep Moving

I still pay attention to new AI tools. The models, editors, and development methods I use will probably continue to change, and some of those changes may be worth making.

But there is one question I ask myself less often now: am I using the best tool in the world?

A product will not succeed or fail because of that question alone. What I am learning instead is how to keep moving when the tools keep changing: to find something good enough to work with, stay focused long enough to understand it, and keep the original problem in view.

The first problem I faced was not code. It was learning not to let uncertainty around the tools become more important than the thing I was trying to build.