1
5 Comments

I thought I was building a prompt manager

I started building AI Prompt Studio because I wanted a better way to work with my own prompts.

I use AI every day, and after a while I realised I wasn't just collecting prompts anymore. Some were finished and ready to use, others were experiments, some were only ideas, and many were different versions of the same prompt. Keeping everything in notes or old chat history quickly became frustrating.

So I started building a tool that matched the way I actually work.

At first the idea was simple: create prompts, edit them, organise them and find them again later. But once I began using it myself, I kept running into new situations that the original idea didn't cover.

I added templates because I found myself rewriting the same prompt structure over and over again. Variables came next so a single template could be reused with different inputs. Notes appeared because many ideas weren't ready to become prompts yet, but I still wanted to keep them. Projects and collections followed for the same reason—they made it much easier to organise related work as the library grew.

The latest milestone was being able to generate a prompt from a template and save it straight back into the library. While working on that feature, I realised the prompt itself had become just one part of the process.

The project is still very much a work in progress, and I'm sure it will keep changing. But today it already feels different from the idea I started with. Instead of building a place to store prompts, I'm gradually building a workspace that reflects how I actually work with AI from the first idea to the final prompt.

One thing I'm wondering now is where that evolution naturally stops. At what point does a tool built to organise prompts become something broader without trying to be everything at once?

on August 5, 2026
  1. 1

    The part that stands out is that every new feature came from you actually using the tool yourself, not from guessing what other people might want. That tends to be the difference between a tool that quietly grows into something broader and one that just becomes cluttered. On where the evolution stops, I would watch for the moment a feature exists because it seems useful in theory rather than because you personally hit the wall it solves. Templates, variables, and notes all sound like they came from real friction, so the scope seems to be expanding in the right direction so far.

    1. 1

      That's a really good way to put it. Most of the features so far came from moments where I found myself thinking, "I wish the app could do this right now." I think the real challenge will be noticing when I start adding things because they sound useful instead of because I actually need them. I'm hoping I can stay on the first path for as long as possible.

      1. 1

        Staying on that first path is easier if you write the trigger down every time, not just the feature. "Wish the app could do this right now, because X just happened" is a very different note than "this would sound useful." The second kind is where scope creep sneaks in, since it feels like product thinking but it is really just pattern matching on other tools.

        1. 1

          I like the idea of writing down the trigger instead of just the feature.

          I've noticed that the features I actually end up using always come from a real moment of frustration. The ideas that start with "this could be useful one day" usually stay unused or make the product more complicated than it needs to be.

          For me, that simple question of "what happened that made me want this?" is a really good filter.

          1. 1

            That question works because it forces a real story instead of a hypothetical. If you cannot point to the exact moment the frustration happened, the feature is probably a nice to have wearing a disguise.