Rebuilding the backend around modules

This one’s for the engineering-minded. Zeno grew fast, and like most fast-growing codebases it accumulated a sprawling features/ directory where business logic, integrations, and shared pipelines all lived side by side. That worked until it didn’t. Recently we did the unglamorous work of reorganizing the backend around explicit boundaries.

Modules, pipelines, integrations

Everything in the old features/ folder now lives in one of three places, each with a job:

Modules: the business domains, including rental, development, expenses, books, and glass. Each owns its entities, its rules, and its surface area.
Pipelines: cross-cutting machinery that serves every module, such as document ingestion, bank feeds, notifications, and server-sent events.
Integrations: the seams where we talk to the outside world, including QuickBooks, Manager.io, and Quo.

By the end of the migration, features/ was gone.

A boundary checker in CI

A reorganization nobody enforces drifts back into mud within a month, so we added a boundary checker to the build. Modules can’t reach into each other’s internals, pipelines can’t depend on a specific module, and integrations stay at the edge. A pull request that crosses a line fails CI before a human has to catch it.

Chat moved to WebSockets while we were in there

Team chat used to run on heartbeat polling and a stream of “user is typing” POSTs, which was wasteful and always felt a half-second behind. It’s on a WebSocket connection now. Presence, typing indicators, and new messages arrive when they happen, at a fraction of the request volume.

What this makes possible

You’ll never click a button labeled “modules,” and a refactor doesn’t show up in a changelog as a feature. What it buys is parallel work: an auto-glass vertical, construction progress billing, and AI reconciliation are all being built this spring, in different modules, without stepping on each other.

Questions about how Zeno is built? We’re happy to talk shop: [email protected].