Composable Software: Why I'm Building CoCube

Tools tend to make you choose between flexibility and reliability. The simplest solution is usually the easiest. Doom Emacs gave me flexibility, allowing me to build my own solutions exactly as I needed, but was fragile, text based, and lacked any collaborative features. Notion gave me reliability but walled off my data behind an export that lost structure every time I used it. Obsidian gave me local ownership, but markdown text for everything including structured data and reactive views became limiting. CoCube exists because I wanted the best of each of these tools and the drawbacks of none of them.

What composability means

Composable software is built from independent pieces you can take apart, rearrange, and combine into something new. The idea traces back to the Unix philosophy from the 1970s, where Ken Thompson and the Bell Labs team built an operating system out of small programs that each did one thing and composed through pipes. Instead of a fixed application with a fixed set of features, you get building blocks. Each block does one thing, and you connect them however you want.

Most software doesn't work this way. You get a product with a specific set of capabilities, and if what you need falls outside that set, you're stuck. You file a feature request, wait, and switch to a competitor in the meantime.

Unix proved that composability works when the building blocks are small, focused, and easy to connect. That model was designed for programmers working in a terminal, and it still thrives there. CoCube applies the same principle to a different surface, a visual workspace where the building blocks are reactive components instead of command-line programs.

CoCube is built from the ground up around this idea. Every component can be deconstructed, modified, and recombined. A button is a tree of reactive nodes with cells that define its width, color, and behavior. Don't like how it works? Change the cells. Want something that doesn't exist yet? Compose it from the pieces that do.

The principles driving CoCube's composability

Building composable software isn't about modularity alone. It's about getting the foundations right so that flexibility doesn't come at the cost of stability.

The user owns the data. Your data is always stored locally and can be painlessly exported. CoCube is built local-first, meaning your device is the source of truth, not a server. Every document is a Loro CRDT binary on your machine. You can copy it, back it up, or hand it to another tool that reads the same format. If CoCube disappeared tomorrow, your data would still be on your device in a documented, open format.

Soundness over cleverness. Functional programming, declarative definitions, and strong type systems make composable systems reliable. When you modify a component, the system tells you when something doesn't fit instead of failing silently at runtime. Updating a component should never cause anxiety.

A high skill ceiling. CoCube should feel like an instrument, not a toy. Keyboard shortcuts for every action, a command palette for everything else, and a component model where the thing you built last month is a building block for the thing you build next month. A Steinway, not a kazoo.

Performance that induces flow. Composable software falls apart if interactions feel sluggish. Every interaction in CoCube targets a response time under 10 milliseconds, with full keyboard navigation and zero loading screens. The goal is to eliminate the time between deciding what to do next and doing it.

Fundamentally searchable. Finding what you've done before is as important as producing the next thing. Building CoCube local-first means all your data lives on your device, which opens the door to search that responds as fast as you can type.

Always collaborative. Composable components are meant to be shared. CoCube uses CRDTs for conflict-free real-time collaboration, and anything you build can be used and modified by the people you work with without a merge dialog or a locked file.

Who needs composable software

If any of these sound familiar, composable software is worth your attention.

• You've tried popular platforms but felt limited by their inflexibility.
• You value local-first design but want a modern UI with it.
• You've tried open-source solutions but spent too much time maintaining your system.
• You want to personalize your tools but don't have time to build from scratch.
• You don't want to deal with HTML, CSS, or JS to customize your workspace.
• You want your system to work when you need to share and collaborate.
• You have a capable computer with a GPU that sits idle all day, and you're tired of slow web-based tools.

CoCube is a medium where people who care about their tools can build something that fits their work perfectly and share it with the people around them.

What's next

CoCube is focused right now on making reactive cells feel right for building collaborative knowledge bases. Rich text editing, custom component types, and local-first data sync are the three active fronts.

The composable-software idea is old. Unix proved it for programmers over forty years ago. The piece that was missing was a way to make it work for everyone else without requiring a programming language to glue the pieces together. CoCube is the bet that a reactive cell model, rendered by the GPU instead of the DOM, is that glue.

Try it and tell me where it falls short.