Mycelium

The Rest

47 Documents

I have a folder in my drive called "Ideas." It has 47 documents in it.

Product requirement documents for apps I was excited about. Business plans for SaaS products. Feature specifications for platforms that would solve real problems. Some of them are genuinely good ideas. A few might even be viable businesses.

Forty-seven documents. Zero shipped products.

Meanwhile, at my day job at a printhouse, I've planned, designed and built: a WhatsApp Business client integrated with Meta's Cloud API, an analytics dashboard that syncs data from our external CRM, internal tools for tracking orders, managing customer communications, automating workflows.

These aren't side projects. They're production systems. People use them every day. They work. They ship. They get updated when they break. And none of them would ever end up in that "Ideas" folder, because none of them started as ideas for "the world." They started as: "This specific thing is annoying me today."

The CRM That Became a Graph Database

I wanted to build a CRM. I've been working in marketing departments since my first job. The premise was simple: Israeli businesses need Hebrew-based CRMs, and most existing solutions are bloated or expensive or both. Start with something minimal. See your leads. Track conversations. Know who to follow up with.

I wrote the PRD. But then I started doing proper UX.

I wasn't just thinking about tables of leads anymore. I was asking "why?" How could this be more than a data entry tool? How could it work with a user's natural workflow?

Then I remembered a Fireship video about Neo4j. It explained a simple, powerful idea: humans think in relationships, not tables. The Cypher query language was built on this: Entity -> Action -> Entity.

Something clicked. The name of the product itself was Customer Relationship Management. What better use case for a relationship-based database?

What if it was graph-based? Not tables and relations, but semantic relationships. Person -likes-> Post. Customer -ordered-> Product. With timestamps and event sequences, you could do pattern recognition. Predict behaviors. Understand customer journeys not as rows in a database but as paths through a network of meaning.

This wasn't feature creep. This was architecture. This was the foundation that would make everything else possible.

So I started researching graph databases. Neo4j, ArangoDB, Amazon Neptune. I mapped out the schema. Designed the query patterns. Calculated the infrastructure costs.

The simple CRM that could've taken two months became a six-month project. Then nine months. Then "when I have time to do this right."

It's still in the "Ideas" folder. Document #23.

The Problem With Being Right

Here's the uncomfortable part: I still think I was right about the graph database. Not right as in "clever." Right as in: this is genuinely how CRM data should be structured.

So why didn't I build it? Because being architecturally correct doesn't make something solopreneur-feasible.

The right solution required learning Neo4j, different hosting infrastructure, more complex data modeling, fewer available resources, higher cognitive overhead. The simple version — PostgreSQL with foreign keys — would've been architecturally wrong but practically shippable. The graph version was architecturally right but practically impossible for one person.

What Actually Shipped

Meanwhile, at work, someone mentioned that tracking customer conversations was getting messy. We were using personal WhatsApp accounts, and when someone was out, no one else could see the conversation history.

I built a WhatsApp Business integration in 2 days. It stores messages in Firestore. The UI is functional and beautiful. It works. Every customer service interaction runs through it. When someone's out sick, anyone can pick up the conversation.

It solved the problem. It shipped.

The Real Difference

The work project shipped because it had constraints:

The CRM had none of these. Infinite time. Infinite scope. Imaginary users. No feedback loop.

Without constraints, "better" became the enemy of "done."

The work projects ship because I can't make them better than they need to be. When someone says "we need to track WhatsApp conversations," I can't respond with "let me spend three months researching the optimal message store architecture." They need it now. They need it to work.

So I build the simplest thing that works. And then something interesting happens: once it exists, I can make it better. I see how people actually use it. I find the real bottlenecks, not the theoretical ones. Each feature comes from using the system, not from imagining it.

The CRM never got to that stage because it never existed in the first place.

The Lack of Constraint Isn't Freedom. It's Paralysis.

Side projects fail because they have too much freedom. At work, constraints force me to ship. For side projects, I have infinite time, no feedback, infinite scope. The lack of constraint removes the pressure to decide, which removes the pressure to ship, which removes the opportunity to learn.

I'm not going to tell you I learned my lesson and now I'm shipping simple CRMs with artificial constraints. That would be a nice ending. I'm still sitting here with 47 documents, still convinced each of them could be something if I just had the time to do them right.

What I am noticing is the pattern. Work gives me problems that come with constraints built in. Real users, real deadlines, real consequences for not shipping.

The WhatsApp system isn't a billion-dollar startup. It's a tool that helps 8 people do their jobs better. And it exists.

That might be enough.