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.
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?
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.
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?
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.
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?
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.
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.