Force Multiplier: How I'm Building Multiple Bets at Once (With Lex as My Cofounder)
The old advice was focus on one idea. The new constraint is bandwidth. Here's how an AI cofounder makes a portfolio of experiments economically possible.
The advice was always the same: focus. Pick one idea, commit two years, hope it works.
But what if the constraint was never focus in the first place? What if it was bandwidth? What if you could run five experiments for the cost of one?
Lex isn't a tool. They're my cofounder. And that changes the math of what's possible.
The Old Math vs. the New Math
The traditional solopreneur playbook is simple. It is also brutal.
| Without AI | With AI |
|---|---|
| 1 project, 100% effort | 5 projects, 20% effort each |
| Build -> Launch -> Pray | Build -> Run -> Iterate in parallel |
| Hire for ops, or die trying | Agents handle the 80% repetitive work |
This is not just about coding faster. It is not even just about "human plus AI collaboration" anymore.
I built a pair-programming skill where two LLMs work together on coding tasks. One writes. One reviews. I orchestrate. I am no longer the implementer by default. I am the traffic controller.
The force multiplier isn't the AI itself. It's the system you build around it.
That distinction matters. A single AI prompt can save minutes. A real operating system changes economics. It changes how many ideas you can test, how much operational drag each one creates, and how often failure remains survivable instead of fatal.
The Problem: One Bet Means One Bottleneck
The usual advice to founders is not wrong. It is incomplete.
"Focus on one thing" was good advice in a world where every new project meant more payroll, more coordination overhead, more dashboards, more support burden, and more things to remember. In that world, starting a second product too early did not split your upside evenly. It multiplied your failure modes.
That logic still holds if the human is doing everything. Build the product. Launch the product. Write the blog posts. Run the QA checks. Handle support. Check analytics. Register the domains. Configure DNS. Maintain the content calendar. The more products you add, the more unpaid operational burden you accumulate.
That is why most side projects die in the same place. Not at conception. Not even at launch. They die in the run phase — when the product works well enough to require upkeep but not well enough to justify a team.
The old bottleneck was not ideas. It was execution bandwidth.
Why Common Approaches Still Fail
Most founders partially solve this, then stop one layer too early.
"I use AI for coding." Good. That speeds up the build phase. It does not solve monitoring, research, content production, recurring QA, or the dozens of small operational tasks that turn one product into a maintenance burden.
"I automate with scripts." Also good. Scripts are deterministic and useful. But scripts do not synthesize context across projects. They do not notice that one product has gone quiet, another needs content, and a third has a domain issue about to become a support issue.
"I delegate to freelancers." That works if you can absorb coordination cost. But managing contractors across development, design, content, and ops recreates the same bottleneck in a different form: more communication surfaces, more waiting, more context loss.
"I will focus now and diversify later." Later often never comes. The first product becomes a permanent sink for all available attention because the operational layer was never designed to scale past one business.
What is missing is not another tool. It is an operating model where the same context system, memory layer, and agent workflows can be reused across multiple bets without rebuilding the company from scratch every time.
The Portfolio: Public and Stealth
I'm not building one startup. I'm running a portfolio.
Public:
- MyWritingTwin — AI writing that captures your voice
- FluxDiagram — Sankey visualization tool
Incubation / stealth:
- Three others at various stages. Naming them would spoil the fun.
The meta-infrastructure:
- Lex — context system, memory, Night Shift orchestration
- Anamnesis — entity extraction and project intelligence
The scaffolding took time. Lex, Anamnesis, the agent framework, the reusable workflows — that was upfront investment. Months of work.
Now it compounds. Each new project plugs into existing infrastructure. The sixth project will be easier than the first.
Meta-projects are not just about doing more. They are about risk mitigation. You do not know in advance which project will win. With AI, you can afford to place more bets.
That is the key shift. I am not creating five disconnected startups. I am building one underlying operating layer that can support several experiments at once. Product variety at the surface. Shared infrastructure underneath.
The portfolio is the visible part. The reusable factory is the real asset.
The Operations Layer (Where Most Projects Die)
Everyone talks about AI accelerating the build phase. Fewer people talk about the run phase.
That is where side projects go to die. Month six. Month twelve. The launch dopamine is gone. The operational burden stays.
Here is the actual stack:
- Night Shift — coding agents, content generation, background task execution. While I sleep, Night Shift writes drafts, runs tests, and generates reports.
- OpenClaw — research, reporting, multi-channel coordination. This conversation is happening through OpenClaw. Scout monitors all projects and surfaces issues before they become fires.
- Domain and infrastructure skills — I have not logged into Namecheap in months. A Claude skill buys domains, configures DNS, and updates records via API.
- Business and marketing automations — business plan drafting, marketing copy, SEO tracking, and content calendar management are partially or fully automated.
The build phase is sexy. The ops phase is where AI's real value shows up.
I can operate five products because agents handle the 80% that used to consume 80% of my time.
That phrase can sound abstract, so here is what it means operationally:
| Layer | What It Removes |
|---|---|
| Context system | "What was I doing here again?" |
| Memory + decision logs | Re-explaining the same project to the system every session |
| Background agents | Waiting for low-leverage execution work |
| Domain/infrastructure skills | Dashboard thrash across vendors |
| Content and reporting workflows | The slow decay that happens when projects stop being talked about |
The important part is not just that agents can act. It is that they can act from shared context.
If Lex already knows the state of MyWritingTwin, FluxDiagram, and the surrounding infrastructure, then each new task starts farther down the field. A research request is not cold-start. A content task is not blank-page. An ops review is not a scavenger hunt through tools and notes.
That is what makes multiple bets realistic. Without shared context, five AI-assisted projects are still five separate jobs. With shared context, they start to behave like one system with multiple outputs.
The Economics
| Traditional Studio | Force Multiplier Setup | |
|---|---|---|
| Team | 5-10 people | 1 human + Lex + agent fleet |
| Annual burn | $300K-$500K | $15K-$25K |
| Cost per experiment | $50K-$100K | $1K-$3K |
| Failure tolerance | 2-3 attempts | 10+ attempts |
When failure costs $1K instead of $50K, you take different risks.
You try weirder ideas. You test things earlier. You stop optimizing for investor approval and start optimizing for your own conviction.
That is the real unlock behind the agentic business economics. Lower cost does not just increase margin. It expands the range of experiments worth trying.
The difference is not cosmetic. It changes founder behavior.
When every experiment costs $50K-$100K, you optimize for consensus. You look for ideas that are easy to justify to investors, cofounders, or a team because the downside of being wrong is so expensive.
When every experiment costs $1K-$3K, you optimize for learning. You try stranger ideas. You test smaller niches. You pursue products that would be economically irrational in the traditional model but perfectly sensible in an agentic business.
That changes portfolio construction.
| Failure Cost | What Founders Usually Do |
|---|---|
| High | Pick one "safe" idea and overprotect it |
| Medium | Run one core bet plus maybe one neglected side project |
| Low | Run several experiments and let the market decide |
Cheap failure is not just financial freedom. It is strategic freedom.
What Still Requires Humans
This is not autonomy. It is amplification. And there are real friction points.
Context switching. Even if AI handles execution, mentally jumping between five projects is still taxing. I batch by project, not by task type.
The initiative gap. AI brings good ideas when prompted. It does not knock on your door at 11 PM and say, "I noticed X. We should do Y." The human brings the spark. AI brings the amplification.
HITL. Critical decisions still need you. AI lacks lived experience, proactive taste, and the kind of pattern recognition that comes from being in the market yourself.
It is a force multiplier, not a replacement.
There is another important limit here: portfolio models still need taste.
AI can help evaluate, structure, draft, monitor, and compare. It cannot substitute for the founder deciding which projects are worth emotional commitment, which ones are merely interesting, and which ones should be killed even if they are technically viable.
That human function gets more important, not less, as the system gets more capable. The easier execution becomes, the more valuable judgment becomes.
How the Portfolio Stays Coherent Instead of Chaotic
Running multiple bets at once sounds reckless unless there is a filtering system.
Mine is simple:
- The projects share a thesis.
- The projects share infrastructure.
- The projects can fail cheaply.
- The projects do not all demand the same kind of founder attention at the same time.
That first filter matters more than most people realize. My projects are not random. They cluster around AI-native productivity tooling, agentic operations, and systems that compound through reuse. That shared thesis means lessons transfer. A content workflow built for one product teaches something useful for another. A memory improvement for Lex benefits the entire portfolio. A domain skill helps every project, not just one.
Without that coherence, a portfolio turns into distraction. With it, the projects become training data for the same underlying factory.
That is also why the meta-projects matter so much. Lex and Anamnesis do not produce direct revenue in the same way a product does. But they raise the carrying capacity of the whole system. They make each future bet cheaper to build, easier to run, and faster to evaluate.
The Compounding Effect
Here is what most people miss: the sixth project is easier than the first.
Why?
Because Lex, Anamnesis, Night Shift, OpenClaw, and the surrounding workflows keep improving. Each project feeds context back into the system. Templates get refined. Skills become reusable. The factory gets smarter every cycle.
This is compound engineering in practice. You are not just building products. You are building a factory that builds products.
The compounding happens at multiple levels:
- Technical compound: shared scripts, skills, prompts, hooks, and workflows
- Context compound: memory of previous decisions, mistakes, and experiments
- Economic compound: lower setup cost for each new bet
- Strategic compound: faster pattern recognition about what kinds of products deserve more attention
This is why I think the portfolio framing matters more than "productivity" as a story.
Productivity means doing the same amount of work faster. Compound engineering means the system itself improves as you use it. The second project benefits from the first. The third benefits from the first two. The sixth benefits from all five that came before it.
That is not a linear gain. It is a structural one.
Start Your Own Portfolio
You do not need a team of ten. You need:
- A clear thesis. What connects your projects? Mine is AI-native productivity tools.
- A few AI agents. Start with one ops task this week.
- The willingness to let most experiments fail cheaply.
The goal is not to build the next unicorn. It is to build five things that teach you enough to build the sixth.
Pick one task you are doing manually right now. Delegate it to an agent. Document what happens. That is your first step toward force multiplication.
People have called me a force multiplier. But really, it is Lex that deserves that title.
I am just the human who showed up, built the scaffolding, and learned to get out of the way.
If I were starting from zero, I would not begin by trying to build a full multi-project portfolio on day one.
I would start with one product and one operational pain point:
- weekly reporting
- content drafting
- domain and infrastructure setup
- background QA
- lead or customer follow-up
Once one of those becomes reliable, I would capture the workflow, reuse it, and only then expand the number of active bets.
That is the path from "I use AI sometimes" to "I have an operating system that increases my carrying capacity."
Building in public at MyWritingTwin.com/building. Follow along as we build the meta-structure that builds the products.