When I introduced Space Zero, I said I would focus on it for the next six months.
I’ve decided to stop building it as a product.
The strange part is that I still want to build it. If Space Zero were my full-time work, I would happily keep going. But I have around fifteen hours a week for it, and working on the rebuild has made me reconsider how much I can actually take on.
I wanted a better way to work with Pi
I love Pi. Space Zero started because I wanted to improve my own daily workflow.
Running agents in the terminal worked well for me. Reviewing their changes, opening Markdown files, and navigating project documents felt less comfortable. Sometimes I just wanted a proper graphical interface.
I tried terminal-based options. They weren’t what I wanted.
So building a graphical companion felt natural. This was something I wanted to use myself, solving problems I encountered while doing actual work.
I still think those problems are worth solving.
The first version already did a lot
The first version wasn’t just a chat interface around Pi. It already had:
- Agent conversations: streaming responses and reasoning, model selection, tool confirmations, reusable agent definitions, and subagent delegation.
- A working environment beside the chat: a file explorer and editor, editable Git diffs, an embedded browser, and a terminal.
- GitHub integration: browsing issues and pull requests, reviewing changes, and starting agent sessions from an issue or PR.
- A knowledge base: rich Markdown editing, search, repository sync, and its own chat.
- Multiple workspaces: project sessions visible side by side, plus global chat outside a particular repository.
There was also a command palette, configurable keyboard shortcuts, onboarding, and automatic updates.
I could explain why I wanted each part. That made it easy to keep expanding the scope. Together, though, they meant building and maintaining an entire workspace.
I had built and released a substantial application. But I had rushed it. The features were there, and I found it useful, but the experience was too buggy.
The rebuild was about making the core workflow dependable. It was also about changing where the work could run.
Local and remote execution were the plan
I wanted Space Zero to support agents running locally and in the cloud. That wasn’t something I intended to bolt on after finishing the desktop app. It shaped the rebuild.
The first version was organized around Electron, with its main process coordinating application services, persistence, and agent execution.
For the rebuild, I separated those responsibilities:
- Workspace Host: a headless process that owns projects, agent sessions, Pi execution, managed Git worktrees, Git operations, and durable session history.
- Desktop: the Electron application that presents the interface, handles native integration, and starts and manages the local host.
- Client Runtime: a shared, UI-independent layer that communicates with the host. It sends commands over authenticated HTTP, receives streamed events through SSE, and handles reconnecting and catching up with session state.
The point was to use the same host implementation and protocol whether execution happened on my computer or on a remote machine. I didn’t want one execution system embedded in Electron and a second, different one for the cloud.
For a remote session, both the agent and its working files would live on the remote host. The desktop would be the interface used to supervise that work. The cloud plan included on-demand hosts for individual sessions and persistent, dedicated hosts.
The rebuild started with the local host. Remote hosting wasn’t implemented yet, but its requirements were already shaping the foundation.
That meant even local operation needed a real client–host boundary: authentication, durable history, streamed updates, reconnection, and clear ownership of session state.
I wasn’t simply cleaning up the first version’s screens. I was rebuilding the execution architecture underneath them, then bringing the workspace features back onto that foundation.
Fifteen hours a week changes the calculation
Even getting basic chat working again in that architecture took two weeks of my available side-project time.
That’s roughly thirty hours, not two full-time working weeks. And that was one part of the rebuild, not the time spent on the whole architecture.
I was making progress, but I was still working on foundations rather than having the product I wanted to release.
Those foundations are necessary. I had already tried moving quickly and putting lots of features together. The bugs were part of why I was rebuilding in the first place.
But making the basics reliable takes time before I can get to the parts that would make Space Zero particularly useful.
Looking at tools like Cursor and Codex also made me think about the experience people already have. I don’t need every feature they offer. Still, if someone opens Space Zero, the basic experience needs to work well. Being a small independent project doesn’t make a broken chat interface less frustrating.
And finishing the rebuild wouldn’t remove the time constraint.
Maintenance, releases, support, and helping people discover the product would all have to fit into those same fifteen hours. I don’t have one block of time for building the application and another for everything that comes with running it.
When I imagine working on Space Zero all day, I still feel excited about it. When I look at what I can give it each week, the same scope feels too complicated to sustain.
Maybe I need to change my workflow instead
Seeing Omarchy prompted another question: how much of the environment I want actually needs to be a new application?
Some of the capabilities I wanted Space Zero to bring together already exist in my setup.
I already run jobs on a server. That doesn’t give me everything I had planned for Space Zero’s cloud experience, but it already lets me run work away from my laptop.
I can configure subagents and workflows around Pi without building an entire graphical system to manage them.
That doesn’t mean a unified interface has no value. Having everything work together was part of what attracted me to Space Zero, and it still does.
But it makes me question how much I need to build and maintain myself.
Maybe I can improve the awkward parts of my workflow with graphical tools alongside Pi, rather than building the application around everything. I haven’t worked out exactly what that setup should look like yet.
The original need was to make my daily work more comfortable. Building a complete product was the solution I chose, but it might not be the solution I need.
I still like the idea
I’m not coming away from this thinking Space Zero was pointless, or that I should never build my own tools.
The first version was useful to me. The friction that started the project is still real. And I still enjoy working on this kind of software.
What has changed is my decision to keep developing it as a product.
I said I would give it six months. I’m changing that plan because I now have a clearer view of what the work involves—not because I’ve stopped wanting to do it.
I still want to build Space Zero. I just can’t give the product I have in mind the time it needs.