Fourbyfour

Describing Backends: A Note on SOP

Describing Backends: A Note on SOP

"Exploring the small foundation that will quietly guide how Fourbyfour builds and evolves projects."

As Fourbyfour has evolved, we’ve been looking closely at how a backend should be described before any code is written. Our internal code generation engine, MetaPro, already takes simple inputs and turns them into working backend projects. MagicGit, our internal version control layer, tracks how those inputs change over time. Together, they’ve shown us how much clarity and speed come from starting with a good description rather than jumping straight into implementation.

This has guided us toward an internal structure we’ve started calling SOP, short for Schema, Operations, Package. It isn’t a product or a new interface yet. It’s simply the approach we’ve been shaping internally to represent a project in a way that’s clear, visual, and consistent. SOP’s goal is to express what a backend contains, what it does, and how it runs, in a small, readable format that works equally well in the GUI at fourbyfour.dev or through the CLI.

The direction SOP opens up is promising. Creating a new service, whether it stands alone or works alongside others, becomes much simpler when everything begins with a uniform description. Independent services can be generated just as easily as composable ones, and connections between them stay understandable without adding noise or complexity. MetaPro can generate what’s needed from these descriptions, and MagicGit keeps the changes easy to follow as the system grows or shifts.

This also reshapes how services evolve. Expanding a system, integrating new parts, or breaking larger pieces into smaller ones becomes a matter of describing intent rather than coordinating scattered files or hidden configuration. As this structure matures, the entire deployment process will flow directly from these descriptions, allowing the platform to assemble and run everything without extra steps or manual stitching.

SOP is still taking shape, and we want to keep it simple enough that it feels familiar from the first moment. If it proves broadly useful, we’d like to make it open so others can benefit from it as well. For now, it serves as a quiet foundation influencing how we think about Fourbyfour’s next phase. Small structural ideas like this often end up having the biggest impact, and we’re excited to see how SOP helps us build faster, clearer, and cleaner as the platform grows.