When a Django Website Becomes a Platform

Speaker: Lien Nguyen 13:00 stage 🎤

I only wanted to build my personal website.

It started as a fairly ordinary Django application for projects, articles and professional offerings. But as real requirements arrived, the architecture began to change. The interesting question was no longer simply how to build the next page, but which parts belonged to this particular website and which were becoming reusable capabilities of their own.

That question eventually led to Website Studio.

This talk is the story of how a personal Django website gradually evolved into a reusable platform without starting with a platform architecture.

Abstract

Website Studio began as a fairly ordinary Django project: a personal website for publishing projects, articles and professional offerings, with an administration surface behind it. There was no plan to build a platform. The first goal was simply to make one real website work well.

As the application grew, the requirements started to change the shape of the system. Projects became structured case studies with relationships and metadata. Articles gained topics and series. Technologies became reusable references rather than text repeated across pages. The application was gradually modelling more than pages - it was modelling concepts with their own identity, relationships and behaviour.

The clearest shift appeared around professional offerings. What could have remained a marketing page followed by a contact form developed into a commercial lifecycle:

Offering → Application → Review → Acceptance → Order → Payment

That process raised a more interesting modelling question than simply how to build another form. Not every step deserved its own database table. Application, Review and Acceptance belong to the guarded lifecycle of one request: Review and Acceptance are state transitions rather than independent business entities. Order and Payment, by contrast, have identities and lifecycles of their own.

This distinction became important as the system evolved. A business process is not automatically a sequence of models. Sometimes a new requirement introduces a new entity. Sometimes it introduces another state in the lifecycle of something that already exists.

The payment boundary created a similar architectural decision. Stripe performs the transaction, but it does not define Website Studio’s commercial process. Order and Payment state remain part of the Django application, while provider-specific concerns stay behind an explicit integration boundary.

As these capabilities emerged, another boundary became visible. The personal website had originally defined almost the entire application, but structured content, publishing, offerings, requests and commercial workflows were no longer inherently tied to one particular public presentation.

Website Studio therefore began to separate reusable application capabilities from the product experience built on top of them. The public website owns its presentation, navigation and visual identity. Website Studio owns the reusable capabilities underneath. The personal website consequently changed from being the definition of the system into its first real product consumer.

That separation also made multi-site support possible. Website Studio can now resolve different website contexts with their own data and activated capabilities while remaining a single Django application and a modular monolith.

The architecture is still evolving, and that evolution is part of the story. The platform boundary was not predicted in advance. It emerged from building one real product, modelling the concepts it actually needed, and allowing new requirements to reveal which parts should remain product-specific and which had become reusable.

The point is not that every Django website should eventually become a platform. Sometimes, the architecture becomes clearer only as the product evolves.

For Website Studio, the platform boundary emerged from the products themselves.

About Lien

Lien Nguyen is a DevOps Engineer based in Germany with experience across data, software engineering and platform operations. She approaches engineering through systems thinking, with a focus on building transparent and maintainable systems. Her current interests include Django-based platforms, engineering governance and production provenance. Outside her day job, she builds her own Django products and a self-hosted environment for hands-on DevOps mentoring. In her free time, she enjoys sports, especially going to the gym, travelling and learning new things.

Check out Lien’s website: nguyenthibichlien.com.