1
7 Comments

I stopped starting with ideas. Now I start with systems.

About a month ago, I wrote that outcomes started to feel predictable.

Not because the ideas were bad,
but because the structure behind them was weak.

If I didn’t know how something would make money,
it usually didn’t.

That realization changed how I build.

But something else happened after that.

I started asking a different question:

What if the problem isn’t the idea or even the revenue model—
but the fact that I’m building things in isolation?

So I zoomed out.

Instead of thinking in terms of single products,
I started designing a system.

Over the last 60 days,
I mapped out 76 small apps.

Not 76 random ideas—
but 76 connected pieces.

I call it the “Memory Universe.”

Each app solves a very specific problem.
But more importantly, each one supports how I think, store, and reuse information.

Because that’s where I kept failing before.

Not execution.
Not even ideas.

But fragmentation.

Good prompts lost in notes
Insights buried in past projects
Things I already figured out… forgotten

So instead of fixing that once,
I decided to build around it entirely.

The first piece I shipped is Prompt Picker.

It’s simple.

Just a fast, low-friction way to store and reuse prompts.

But it sits inside a much bigger direction:

A system where ideas, memory, and execution are connected.

Interestingly, this approach changed how I work:

I build less randomly
I decide faster
And I don’t expect each product to “win” on its own

Now, the goal isn’t to find one breakout idea.

It’s to make sure every piece fits into a structure that can work.

Still early.
Still experimental.

But this feels very different from before.

Less guessing.
More alignment.

Curious—

Has anyone here tried building products as part of a larger system,
instead of treating each one as an independent bet?

Would love to hear how you think about structure vs ideas.

on April 30, 2026
  1. 1

    Refactoring your workflow into a Memory Universe is like moving from chaotic spaghetti code to a highly cohesive microservices ecosystem. You are essentially shipping a personal operating system where every small app acts as a specialized plugin for your existing knowledge graph. This ensures that your previous breakthroughs become permanent dependencies rather than forgotten snippets lost in a dead repository.

    Does this systemic approach make it easier to decide which of those seventy-six apps gets moved to the top of your sprint backlog?

    1. 1

      Honestly, the “microservices → personal OS” framing is exactly how I’ve been thinking about it.

      The biggest shift wasn’t just structure — it was decision latency.

      Before this, I kept re-evaluating the same ideas every day. Now each app isn’t really a “project” anymore — it’s a pre-defined execution unit inside the system. So prioritization becomes less about intuition and more about:

      → which node unlocks the most downstream leverage

      So to your question — yeah, it does make prioritization easier.
      But only because I stopped treating all 76 apps equally.

      Most of them are intentionally starved.
      A few are treated as core infrastructure.

      That constraint is what makes the system actually move.

      1. 1

        Treating your apps as pre-set tools instead of random bets is a great way to stop overthinking and keep your momentum high. I am building Bunzee.ai to help founders pick their best moves using real data so they don't waste time on the wrong ideas. Since you love building smart systems, I would value your feedback on our approach would you mind checking out Bunzee?

        What is the biggest "forgotten insight" that finally became a permanent part of your system?

        1. 1

          I’m not sure it’s fully “permanent” yet,
          but one thing that keeps coming back is this:

          Storing information is easy.
          Reusing it is the real problem.

          I’ve ignored that idea multiple times,
          but it keeps showing up every time I build something.

          1. 1

            That is the classic "data hoarding" trap where we build a library but forget to build the librarian. Storing information is just digital clutter until it actually triggers a decision or a new line of code. We focused Bunzee on the PRD output because retrieval only matters if it leads to an immediate action. Solving for reuse is what separates a static database from a functional, living development workflow.

            What is the most frustrating piece of info you find yourself constantly hunting for in the middle of a deep-work session?

            1. 1

              Honestly, it’s usually not raw information — it’s context.

              Why I made a certain architectural decision.
              Which prompt actually worked.
              What assumptions existed when I wrote a PRD.

              The frustrating part is that the information technically exists somewhere, but retrieving the right version at the right moment breaks flow completely.

              That’s what pushed me toward building smaller memory-oriented tools instead of another giant knowledge base.

              I’m starting to think the real bottleneck isn’t storage anymore.
              It’s contextual retrieval during execution.

              1. 1

                Usually not “information” itself.

                More like:
                “I know I solved this before… where was it?”

                Prompts, positioning lines, edge-case fixes, workflow decisions.

                Deep work breaks the moment retrieval becomes friction.