The modular kernel

Most apps decide up front what they are. A note-taker, a CRM, an inventory system. Everything after that bends to the decision. Cobblr works the other way. At its center is a small kernel that tracks almost nothing by itself. What the app becomes depends on which modules you turn on.

Modules stand side by side on the kernel and never touch: the gaps are real. Wires arc across them ("when this happens there, do that here"), and a bundle sits over a set of modules like a hat, shaping them into one app without owning them. Machines is enabled here too; the bundle just doesn't cover it.

Nothing is locked to one use case

The kernel understands workspaces, items, fields, and views in the abstract. It has no opinion about what you're tracking. A 3D-printer workshop, a yarn stash, a lego club, and a garage are all the same Cobblr with different modules enabled and skinned to fit. There's no "inventory app" or "workshop app" to choose between. There's one system, and you build the shape you need.

Modules don't know about each other

Each module is self-contained and doesn't reference the others. Inventory has no idea Projects exists. Scanning doesn't depend on Machines. They fit together through the kernel's shared pieces (items, fields, views, events), not by calling into each other. That's the reason you can enable any subset and have it work, and the reason a new module can arrive without disturbing the ones already there.

Why it's built this way

You only carry what you use. An empty workspace stays empty until you enable something, so nothing is forced on you. Once you learn how items, fields, and views behave, you've learned every module, because they all work the same way. And the app grows without rewrites: new capability means a new isolated module, not surgery on a monolith.

Next up: Workspaces are the spaces all of this lives in, Modules are the features you enable, Bundles are ready-made sets of them, and Views are the ways you look at your data.