One Project, Multiple Paths: The Spin‑Off Story

The story behind how one project spin-off into many

Building products for many people is exciting, but creating something truly great—and experiencing that achievement—is even more rewarding.
The unique journey of how a project evolves over time and how much we learn as humans is what makes us fall in love with the process. That passion empowers us to improve with every iteration.

That’s a product‑centric perspective, but building products happens in a business context with deadlines and revenue targets. That’s why there are many delivery techniques—like the popular MVP.

When building products, we must consider many factors—there are always plenty of features to add to keep up with competitors, and we need to iteratively deliver substantial functionality while maximizing growth.

This story is exactly about that—how we iteratively spin-off one project into several.

Chapter 1: The Beginning

Our project was a documentation framework called xyd. Where did the name come from? The “x” and “y” come from the Cartesian coordinate system, and “d” stands for “docs,” signifying it as an expandable documentation framework.

We knew our scalability needs were high, and building software like this would require significant effort—yet we didn’t have much time or team resources, since we also had to develop our primary product.

Chapter 2: Scalable Software

We needed scalability from day one, even for the first release. You can’t spin off software if it isn’t designed to scale. We anticipated those needs early, so we built for scale from the outset—but we also knew that gold plating can jeopardize delivery when a product is endlessly improved. Challenge accepted.

Components

Components provide huge value and are often underrated. In our case, they’re a first principle. Here, the time‑honored “dummy components” principle applies: documentation frameworks handle UI tasks—rendering sidebars or headers with user‑defined links, for example—so those components must remain decoupled from business logic.

That’s why @xyd-js/components is a package of reusable dummy components, and xyd itself employs a composable architecture.

Contrary to appearances, components created for documentation frameworks—like header, sidebar, footer, and many more—are common in the web world, especially when they support customization. We can use these components to build other marketing pages or content‑rich sites (this blog, for example).

In the future, we plan to spin off the xyd components into separate packages and integrate them more natively into the LiveSession ecosystem (coming soon).

Abstractions

We rely on many abstractions. Documentation frameworks address various engineering concerns, such as rendering content with Markdown or other processors. Modern frameworks also support generating API reference documentation for OpenAPI or GraphQL.

Chapter 3: APIToolchain

We split responsibilities and created a layer called uniform. It’s a simple interface that transforms multiple API formats into a single, unified one. This project will evolve beyond the scope of xyd itself. While Uniform is powerful, it’s just one part of a larger initiative we named APIToolchain.

APIToolchain is a collection of tools and interfaces for generating API‑style documentation—such as SDK generation (coming soon) or OpenAPI/GraphQL docs. Developers can create API reference docs without our framework; APIToolchain can be embedded anywhere, since it’s framework‑agnostic.

Chapter 4: APIAtlas

Currently, APIAtlas is a subset of components for building API docs pages, similar to Tailwind Protocol. We’ve extracted this code from our base components and are shaping it into a standalone package.

This package has the potential to become a full‑featured API docs platform or a modular set of building blocks. Our Developer Platform is still evolving, and contributions to APIAtlas will align with our product needs.

Chapter 5: XWrite

We faced many challenges in achieving the ideal writing experience with existing content tools. For example, we tried Markdoc (from the Stripe team). We liked its concepts but found its syntax unreadable for us, and its template‑style expression evaluation too rigid.

Then we tried the classic MDX approach. We love the JS/JSX style, but when writing documentation, we also need text evaluation like Markdoc offers—one reason text‑focused languages like LaTeX and Markdown remain popular.

That’s why we created XWrite. It balances the strengths of Markdoc and MDX with custom features for a superior writing experience. We call it a framework for content artisans:

# Python SDK

## Get settings
@let(snippet = await snippets.py.getSettings())

### API Reference:
@uniform({snippets})

Chapter 6: 1Magazine

It’s a relatively new concept. Given our writing engine, components, and composable architecture in xyd—plus our internal needs for rich content—we needed a solution: a platform to deploy content‑rich sites with full technological freedom.

For example, building this in‑house seemed reasonable for us, which is why we’re giving 1Magazine serious thought. If you like the idea, let us know.

Chapter 7: It’s Just Beginning

The creation of xyd has opened many doors, but it’s still just one piece of software for upcoming LiveSession projects. Stay tuned for what’s next!