Website Studio

Introduction

Origin and transformation.

Website Studio started with a practical goal: I wanted to build and manage my own personal website. I could have used an existing CMS or website builder, but I wanted real control over how my projects, articles and professional services are presented, and the freedom to extend the site as new ideas came up, without being boxed in by someone else's structure. So I built my own.

What started as the backend for a personal website gradually became something more useful: a Studio for managing everything behind the public site, not just its pages. The website was still the starting point, but the capabilities I kept adding turned out to be useful well beyond any single page, and made running the website itself much easier.

That shift, from building a website to identifying the reusable capabilities behind it, is what now drives the project.

One place to manage the website

Public-site vs. Studio operating separation.

The public website and Website Studio serve two different purposes. Visitors see the finished experience: my work, writing, projects and professional offerings. Website Studio is where I manage the information and operational activity behind that experience.

Instead of treating every content change as a development task, I work with structured content directly in the Studio and decide what should be published. The public site can therefore stay focused on presentation, while editing, publishing and operational management happen separately.

This separation became increasingly useful as the website grew. What had originally been a convenient administration interface became the place where the website's underlying content and business activity could be managed consistently rather than spread across templates, configuration and external tools.

From one website to multiple sites

Implemented multi-site evolution.

The next architectural step was separating Website Studio from the website that originally created it. My personal website is now a consumer of the platform rather than the definition of the platform itself.

Website Studio can operate in the context of different websites. The Studio maintains a current-site context, and switching that context changes what I am managing: the content, capabilities and operational data belonging to that site. The same management environment can therefore support my personal website, Website Studio's own public presence and deliberately different demo sites without treating them as copies of one another.

This changed an important assumption in the architecture. A project, article or offering can no longer implicitly mean “the one belonging to my website.” The platform has to understand which website is being operated and compose the relevant data and capabilities around that context.

Multi-site support is already part of the working platform. Multi-user workspaces are a separate architectural problem and a later step; I deliberately do not treat the two as the same thing.

Platform capabilities, product experiences

Platform ownership principle.

Once Website Studio was no longer synonymous with my personal website, the boundary between platform capability and product experience became much clearer.

Website Studio owns reusable capabilities: structured content, publishing, media, offerings, incoming requests and the operational workflows around them. A website or downstream product decides how those capabilities become a public experience.

That distinction is deliberate. Website Studio should not force every product to inherit the same homepage, navigation, layout, colour system or visual identity. My personal website can look like my personal website. Website Studio can have its own product identity. A tailored learning platform can have a completely different interface while still using selected capabilities provided by Website Studio.

The same principle guides reuse inside the architecture. I do not generalize something into the shared platform simply because one product needs it. A capability becomes a candidate for the common layer when real use cases show that the same mechanism is genuinely being repeated.

Architecture

Technical realization of that principle.

Website Studio is currently structured as a modular Django application. Shared platform capabilities are kept separate from the product-specific composition that turns them into a particular website or product experience.

Conceptually, I think about the system in three layers:

The important part is not the diagram itself but the boundaries behind it. Product presentation remains product-owned. Reusable business capabilities remain platform-owned. Infrastructure and external providers stay behind explicit integration boundaries rather than defining the application's business model.

Website Studio remains a modular monolith while those boundaries are still evolving. That keeps the system simple enough to change without giving up separation between domains and responsibilities. Where downstream products eventually need programmatic access, the platform is being prepared for a defined API boundary rather than requiring those products to share Website Studio's internal application structure.

Capabilities instead of pages

Domain modelling.

One design decision has stayed consistent as Website Studio has grown: the system models things I need to operate, not pages I need to edit.

Projects are structured case studies rather than blobs of page content. Articles can belong to topics and series. Technologies are reusable references instead of text copied repeatedly into individual projects. Media can be managed independently of the pages on which it appears. Offerings represent something a visitor can act on rather than merely a marketing page. Operational concepts are modelled in the same way. An application, request, order or booking represents a business event with its own meaning and state, not simply a form submission that disappears after an email is sent.

The Studio navigation therefore reflects capabilities rather than mirroring the public website's sitemap. A public page is only one possible projection of the underlying data. That matters because the same underlying capability can later be presented differently by different products without duplicating its business meaning.

Publishing became a business lifecycle

Concrete example of those platform capabilities.

The point where Website Studio moved furthest beyond conventional publishing was the introduction of professional offerings. An offering is not just a page for it, have that application reivewed, recieve an acceptance, progress into an order then complete payment.

Offering → Application → Review → Acceptance → Order → Payment

Those stages are represented as persistent business entities and transitions rather than inferred from emails or payment-provider state. External systems such as Stripe participate at the boundary, they do not own the commercial lifecycle itself. This let the public website remain simple while Website Studio holds the operational history behind it: what was offered, who applied what was accepted, what became an order and whether the corresponding payment completed.

External payment providers participate at the boundary of that process; they do not define the commercial lifecycle itself. Website Studio owns the order and payment state required by the application, while the provider owns the mechanics of executing the transaction. This distinction makes the commercial model reusable without tying the business process to one payment provider.

Operating the platform

Operational experience.

As Website Studio accumulated more capabilities, navigating directly to individual administration screens stopped being enough. The dashboard became an operational view of the website currently being managed.

It brings together the active site context, capability state, recent activity and areas that may need attention. The site switcher changes the operational context of the Studio itself rather than simply linking to another public website. This is an important direction for the product. Website Studio should not only provide CRUD interfaces for records; it should increasingly make the state and lifecycle of a website's content and business activity visible.

The dashboard is therefore becoming less of an administration homepage and more of an operational surface for the platform.

The products are the demo

Real consumers as architectural validation.

The original demonstration of Website Studio was this website itself. The project page being read, the articles, technology references, professional offerings and visitor interactions all exist because Website Studio manages the structures behind them. What has changed is that my personal website is no longer the only thing testing the architecture. Website Studio now has its own product identity, while additional site compositions let me test whether the same shared capabilities remain useful when the public experience changes.

That gives the project a practical way to evolve. Instead of designing a generic CMS around hypothetical requirements, I can introduce a real consumer, observe which parts are genuinely reusable and only then move those mechanisms into the common platform . The products therefore do more than demonstrate Website Studio visually. They act as architectural tests of where the platform boundary should actually be.

Where it is going

Genuinly future work only.

Website Studio has moved from powering one personal website to managing multiple site contexts, but I still consider the product early in its evolution. The next phase is not simply adding more CMS features. I am continuing to strengthen it as an operational platform: clearer lifecycle and history visibility across offerings, applications, orders and payments; a defined API boundary for downstream products; and eventually authenticated users working within their own workspaces. The platform will continue to evolve through real use cases rather than by trying to predict every possible feature in advance.

That is now the central idea behind the project:

build the product I actually need, separate what is product-specific from what is reusable, and let real use cases determine where the platform boundary belongs.