What Parallel Projects Really Cost When You Are the Only One Building Them

For the longest time I had one project. It was called Havnwright, and before that it was called AI Refurb, and before that it was just an idea I kept coming back to every few months. One project, one focus, one thing to make work. That was my whole operating model.

Today I am running five or six projects at once. A web platform. A native mobile app. A marketing tool. An AI memory system. Various smaller pieces that support them. All of them in active development, all of them solo.

That sounds impressive on paper, and some days it even feels impressive. Most days it feels like something else entirely. I want to write honestly about what this actually looks like, because the version of "running multiple projects in parallel" you see on social media is not the version I live.

What changed

Two years ago, running five projects solo would not have been possible. The tools that let me do it did not exist, or existed but were not good enough. The shift is real. AI agents that can hold meaningful context. Development environments that let me move between codebases quickly. Memory systems, including one I built myself, that keep each project's state coherent so I do not have to carry it in my head.

Without those, this would not work. I am clear about that. If the tooling regressed to where it was a few years ago, I would be back to one project. Maybe two. Not six.

But the tooling being sufficient is not the same as the work being easy. That is the part that gets glossed over.

What it actually costs

Let me describe a typical week. I work my day job as a marketing manager. That is a real job with real deadlines and real responsibilities. It takes a real amount of attention. When the day ends, I come home and open my project windows, usually several of them, and work until late. I do this most days.

After a long stretch of this, I disappear for two days. No computer. No monitor. No code. I am drained in a way that cannot be fixed by an evening off. It takes actual time away before I have energy to start again.

This is the trade-off nobody talks about when they tell you parallel projects are easier than ever. They are easier to attempt, which is not the same as cheap. Every project pulls energy. Running six of them pulls six times the energy, even if each individual task is faster than it would have been before.

I used to read one or two books a month. Sometimes more. Now I do not read books at all. Not because I stopped liking reading, but because I read all day already, at work and at home, in my own projects and in other people's code. When the work ends, I do not want to look at more words. I want silence.

This is not a complaint. I am choosing this. But I want to name it clearly: parallel projects are not a free lunch you pay for with extra energy. They are a real trade. You are giving up a certain kind of life to get a certain kind of output.

The system underneath

People ask me how I do not lose track of things across six projects. The honest answer is that I built a system specifically to stop me from losing track.

I have written about this before. A knowledge graph that captures the state of every project. Decisions made, decisions deferred, things in progress, things blocked, what matters today across all of them. When I open any project window, the first thing that happens is I get a briefing that tells me exactly where I left off, what has changed since I was last there, and what I should probably look at first.

Without that system, none of this would work. I would spend an hour remembering where I was on each project and then run out of time to actually do anything. The system is not an accessory. It is a precondition.

If you want to try parallel projects yourself, the single most important thing you can build, or adopt, is a way to not have to hold all of it in your head at once. Whatever that looks like for you. It might be a knowledge graph. It might be a single document per project that is religiously updated. It might be a very good notes app. But it cannot be "I will remember."

The vibe coding warning

There is a phrase I have heard a lot recently: vibe coding. It describes a style of working with AI where you do not really know how to code yourself. You describe what you want, the agent writes it, you run it, it works or it does not, and you iterate. People who advocate for it will tell you that you can build anything this way.

I want to be very clear about my opinion on this, because a lot of people start with vibe coding, find it frustrating, and conclude that AI-assisted development does not work. That is not the right conclusion.

If you do not understand what the code is doing, AI cannot save you. The agent will write something. It will sometimes work. When it does not work, you will not know why, and the agent will not always know either. You will spend days chasing bugs you cannot diagnose, rewriting things that were almost right, and wondering why the product feels unstable. You cannot ship serious software this way. Not because AI is bad, but because you need to know enough to tell when the AI is wrong.

What I tell friends who ask me how I actually work: I have a second agent running in a separate window whose only job is to explain things I do not understand. When the main agent is building something with a pattern I do not recognise, I pause, I open the explainer, I read, I research, I come back. I do this constantly. I have been doing this for years, and I still do it.

The result is that I know what my code does. I know why a given architectural choice was made. When something breaks at 11pm on a production deployment, I can actually debug it. That is the difference between someone who is using AI to build real things and someone who is vibe coding. Both use AI. Only one understands their own product.

Do not trust the autonomous hype either

There is a second thing that gets hyped and that I am deeply suspicious of. "Autonomous agents" that handle whole workflows without oversight. Run them, walk away, come back to results.

I have been working with agents seriously for three years. They have improved enormously. The version of Claude or GPT I work with today is dramatically more capable than what I had two years ago. I use them intensively, every day, across every project.

And I still do not trust them to run things without me in the loop.

What I mean by "in the loop" is more specific than watching their outputs. I read their reasoning. When an agent is thinking through a problem, I read the thinking, not just the conclusion. Sometimes I stop them mid-thought because I can see the reasoning going wrong before it produces a wrong answer. That interrupt saves me hours of cleanup.

The people who tell you they set up their agents to run autonomously and come back to clean results are either working on very narrow, well-defined tasks, or they are skipping the part where they find out later that something subtle went wrong. I have been burned enough times to stay in the loop.

Tools are tools. An agent is a powerful tool. It is not a teammate yet. Treating it like a teammate is how you end up with three weeks of work that has to be redone.

The double-check rule

Since we are on the subject of being cautious, let me name the single most important habit I have picked up working with LLMs.

Verify everything.

The agent will confidently tell you an API works a certain way. The agent will confidently tell you that a library supports a feature. The agent will confidently describe the state of your codebase or the current behaviour of a third-party service. Sometimes this is right. Sometimes it is plausible but wrong. You cannot tell which from the confidence alone.

I curl real APIs. I run real queries. I check the docs. I read the actual source if I have to. For anything that will end up in production, I do this before I ship. Not because the agent is bad, but because "probably correct" is not good enough for things that real users will depend on.

This takes time. This is also why parallel projects are harder than people think. Every project's "probably correct" output needs a human sanity check, and that check does not parallelise. Only your agents do.

The balance question

The honest version of the question "should you run multiple projects in parallel" is: are you okay paying what it costs?

If you want a chill life, mostly predictable evenings, weekends that feel like weekends, and the energy to read books and see friends without planning it like an operation, do not do this. Stick with one project. Ship it well. Enjoy your time.

If you want to take several ideas you have been carrying for years and actually build them while the tools allow it, you can. But it will cost you. You will work late. You will burn out periodically and need real recovery. You will lose some of the habits that used to make you feel balanced. The books will go first. Then the unstructured time. Then maybe weekends.

I am choosing to pay this. Not forever. Long enough to build things I have wanted to build for a decade, while the tooling makes it possible for one person to do work that used to need a team. But I am not pretending the price is zero.

Tools are tools

The last thing I want to say on this is about framing.

All the tools we have now, the agents, the memory systems, the dev environments, are genuinely new leverage. They make things possible that were not possible a few years ago. That is worth being excited about.

They are also just tools. They do not decide what matters. They do not tell you which project is worth the energy. They do not know when you should stop and rest. They amplify whatever you bring to them, including the good judgement and the bad habits.

Running multiple projects in parallel is possible. It is also genuinely hard, genuinely costly, and requires more than "the tools are good now." It requires a system that holds the state for you, a discipline of verifying everything, a willingness to stay in the loop even when the agent seems competent, and an honest reckoning with the fact that you are trading part of your life for the output.

If that trade is worth it to you, go. But know what you are trading.

---

This is part of a series about building products as a solo founder. Earlier posts cover my personal journey, why I built Havnwright, what building with AI actually looks like, the memory system I built, and every rule is a bug report. More coming.