Building SaaS on a Reusable Engine

Every software product we build starts from the same small set of capabilities rather than a blank repository. That's a deliberate choice with real trade-offs. Here's how we think about it, and why YTPublishers is the first product to come out of it.

The shared capabilities

Under most of the products we want to build, the same four problems keep showing up:

• Content transformation — taking a document in one format and producing a clean, structured, validated version in another.
• Automated layout and formatting — applying consistent structure, styling and pagination across a whole document from a template.
• Applied-AI drafting — turning a prompt or an outline into structured draft content a person then reviews and refines.
• Workflow automation — mapping how work moves through a team today and removing the repetitive, well-defined steps.

We build those once, properly, with their own tests and their own operational history, and treat them as infrastructure.

YTPublishers as the first product on the engine

YTPublishers — our SaaS for self-publishing authors — is mostly those capabilities pointed at one job: manuscript in, store-ready EPUB and print-ready PDF out, with prompt-to-draft on top. Because the hard parts of transformation and layout already existed as shared components, the product work was about the book: formats, typographic conventions, what "publish-ready" means to a retailer.

What stays specific to each product

The engine is not the product. Every product still owns its domain model (what a "chapter" or a "claim" or an "application" actually is), its interface, its rules, its pricing, and its support. Reuse lives underneath that line; above it, each product is built for its users and nobody else. Trying to share the parts above the line is how you get software that fits every use case badly.

The trade-off, honestly

The first product on a shared engine is slower, because you're building the engine and the product at the same time and resisting the urge to hard-code. The payoff is every product after it: less to build, fewer novel bugs, one place to improve performance or reliability for everything at once. The risk is over-generalizing — building for hypothetical future products instead of the one in front of you. Our rule is that a capability only becomes shared infrastructure once a second product actually needs it.