AI Made My Perfectionism Look Like Progress

I have spent years building personal products. Some became working prototypes. Some reached the point where I could show them to other people. But I have never released one of my own products to real users. There was always a reason. It needed another feature. The design could be better. I had found a more elegant way to build it. I needed to test one more thing. Sometimes a new idea felt more exciting than finishing the old one, so I quietly moved on.

I told myself I cared deeply about quality. That was true, but it was not the whole truth. Finishing makes the work real. Once something leaves your laptop, other people can misunderstand it, criticise it or decide that it is not useful. Continuing to improve it privately delays that moment.

For me, uncertainty about how people will respond can become overwhelming. Being autistic is tangled up with that. I can become so focused on getting something right that continuing to work feels safer than allowing anyone else to see it. Perfectionism can look like ambition from the outside. In my case, it has often been avoidance with an impressive amount of work attached to it.

My role is not in engineering, but I naturally look for problems I can solve. When I see a process that could work better, my instinct is to understand it and build something that helps. AI has made that far more possible. It helps me turn an idea into something tangible, learn while building and cross technical gaps that would previously have stopped me at the description stage. I can test an idea in days rather than leaving it as a note about something I might build one day.

That is genuinely empowering. It also created a new problem. Before AI, every extra feature had a cost. It required enough time, effort or technical knowledge that I eventually had to choose what mattered. AI reduced much of that friction. A new thought could quickly become another component. A question could become another workflow. A possible edge case could become another branch of the product.

Almost everything felt achievable, so almost everything felt worth adding. I thought AI was making me more productive. Sometimes it was simply helping my avoidance produce more.

This became clear after I asked someone senior at work to mentor me. Asking felt terrifying. I had imagined rejection before I had given them the opportunity to respond, but they agreed. During our first conversation, they gave me a problem to explore. Within a few days, I had a working prototype. I showed it to the person who had encouraged me to seek mentorship. Halfway through, they unexpectedly invited my mentor into the meeting. I had not prepared for that, but I carried on. I explained the problem, demonstrated the prototype and answered their questions.

They understood it. That mattered more than whether every detail was finished. I had shown an early version of something useful, and the conversation helped make it better. It was evidence that I did not need to remove every possible flaw before sharing my work. Then I was given a second challenge. I created an initial version, showed it to people and received a positive response. It solved the problem clearly enough that I should have paused.

Instead, I treated “this is good” as permission to keep going. Every new idea became another addition. Each addition looked sensible on its own, so I assumed the whole must be improving. I never stopped to ask whether the original solution needed any of it. The work became larger, but not clearer.

Eventually, I could still explain the individual pieces, but I could no longer explain why the complete product needed all of them. Different parts were answering different versions of the problem. The story connecting them had disappeared. Then I presented it. I struggled to answer simple questions about the purpose of the work because I had allowed the purpose to change repeatedly while I was building. I had not lost the technical understanding of what I had created. I had lost the reason for creating it. That distinction was painful, but important.

At the time, I treated the presentation as proof that I was not capable. That was not how anyone else responded. They did not tell me to stop building. They showed me where the work had drifted, which parts no longer served the goal and what the audience actually needed from it.

The presentation had failed. That did not make me a failure, and it did not make every part of the work worthless. It gave me information I could use. I took the weekend to think about what had happened. When I returned, I rebuilt the work around the original outcome. I reduced the scope, removed what did not belong and restored the story that the extra functionality had buried. The result was not perfect. It was more useful.

That experience changed the lesson for me. Failure is not something I need to rename to make it less uncomfortable. An iteration can fail. A presentation can fail. A feature can fail. The important distinction is between an unsuccessful version and a permanent judgement about the person who made it. Failure becomes useful when it changes the next version.

AI did not create my perfectionism. It amplified it. It gave me the ability to move faster, but it could not decide where I should be going. It could help me build almost anything I asked for, but it could not decide what was important on my behalf. That responsibility remained mine. The lesson was not that I should use AI less, build less ambitiously or care less about quality. It was that speed needs direction, and quality needs a stopping condition.

Before I build now, I try to write down five things:

• One person: who the work is for.
• One problem: what they need help with.
• One outcome: what should be different after they use it.
• One story: what they need to understand when I present it.
• One stopping condition: what must be true for this version to be ready for feedback.

New ideas do not automatically become features. They go into a separate list. They can earn their way into a later version, but they do not get to redefine the current one simply because they are possible. That final stopping condition matters most. Perfectionism prefers an open-ended project because there is always another improvement available. A stopping point forces a decision: this version is useful enough to leave my hands.

I have not stopped noticing flaws. I still feel the urge to add one more feature, rethink the design or rebuild something that already works. I still worry about what people will think when they see something I have made. The change is that I no longer want to treat those feelings as evidence that the work must remain hidden.

A product that solves the intended problem does not need to solve every possible problem. A version that receives criticism can improve. A version that never leaves my laptop cannot. The real goal is not to produce something nobody can criticise. It is to produce something useful enough that other people can respond to it. That is the lesson I want to keep at the centre of how I build:

Something imperfect in the hands of other people is worth far more than something perfect that never leaves mine.

There are still sentences in this article I could rewrite. There are probably ideas I could add and sections I could polish. I am publishing it anyway.