It Started with a DNS Form: How a Django App Evolved Beyond Forms

Speaker
Speaker: Lien Nguyen

🧑‍💼 Linkedin Profile

Pages are projections. Forms are mutations. The business entity is what we model. GVINTRA started with a small Django DNS request form, deliberately scoped as a manageable first application for solving a real operational problem. As new business needs followed, the application evolved far beyond forms.

Using one real request domain in depth, this talk explores that transformation: from forms to persistent business entities, from CRUD pages to lifecycle-aware projections, and from isolated implementations to reusable platform capabilities. It is a practical story about letting Django architecture evolve with real requirements instead of trying to predict the final system upfront.

Abstract

GVINTRA started with a small Django DNS request form.

The goal was to solve a real business problem with a manageable first application and learn from building it. At that point, nobody had planned a platform containing many different IT request applications.

That happened naturally.

As stakeholders saw what was possible with DNS, Folder Permissions followed, then further operational domains. Over time, GVINTRA expanded across DNS, folder permissions, firewall, procurement and employee onboarding.

Adding another Django form each time was no longer enough.

In this talk, I will use one of these request domains as a concrete case study to show how my understanding of the application changed.

A submitted request became a persistent business entity with an identity and lifecycle rather than data that had merely passed through a form. Its detail page became an operational workspace: current state, available actions, version history, related entities and external operational progress could all be projected around the same entity.

This led to a distinction that now shapes GVINTRA:

Pages are projections. Forms are mutations. The business entity is what we model.

History became part of that model rather than an administrative afterthought. A user can reconstruct what changed, when, by whom and why. At the same time, progress in an external IT service management system represents a different kind of history. The two can be presented together to the user without pretending they have the same source of truth.

As more domains arrived, another boundary became important: not everything that looks similar should become generic.

DNS, folder permissions, procurement and employee onboarding have different business rules. Those differences belong inside their domains. Capabilities that genuinely recur, such as validation, normalization, ticketing integration, document generation, lifecycle interactions and approval, can instead become shared building blocks.

One year later, GVINTRA has become a feature-rich internal Django platform, and it is still evolving. Additional business applications are already planned, including Change and Offboarding. The architecture continues to encounter requirements that were never known when the first DNS form was built.

The lesson from that year is not that every Django application should become a platform. It is that we did not need to know the final architecture when we built the first application. We needed to model the first real business concept well enough that the architecture could continue learning from every one that followed.

You don’t need to design a platform on day one. You need an architecture that can become one when the business demands it.

About Lien

TBD

Visit my website