Same data, four users: notes on the Turkish Art Platform

01A main center and subsidiary platforms

The Turkish Art Platform is an enterprise art platform that presents artist profiles, artworks, events, applications and editorial content through a main center and subsidiary platforms. Subsidiary platforms serve different countries or organizations. Public pages, user areas, administration and the API are considered together. This is a company project; I took responsibility in development, integration and delivery for the enterprise web application. The interfaces use Next.js and React, the services NestJS, and the data layer Prisma and PostgreSQL; Redis and Tailwind CSS are also part of the stack.

The most noticeable aspect of this structure at first glance is multitenancy. But what made me think more in this project was the different people standing in front of the same data.

02Four perspectives, one set of data

Take an artist profile. For a content visitor, it is a page to read and browse. For the artist, it is a space that represents their work and that they want to keep up to date. For an applicant, it is a record still inside a process whose outcome is not yet known. For an administrator, it is content to review, publish or correct. The data stays the same, but each of them wants something different from it.

In my view, not seeing this difference usually leads to one of two extremes. Either each user ends up with a separate copy of the data and separate rules, which drift apart over time. Or everyone is shown the same screen and the same fields, which serves nobody's work fully. The approach I prefer is to keep the data single and express the differences in the presentation, permission and workflow layers. This approach asks for more thought about permissions and presentation, but keeps the data consistent.

The data can stay single; the needs do not have to.

03Multitenancy is a question of boundaries

When managing content and user workflows across the main center and subsidiary platforms within one shared product, each platform's local context and management responsibilities need to be retained. I see multitenancy primarily as a question of boundaries: which data belongs to which platform, who can see what on which platform, and where the shared part begins and ends.

If these boundaries live only in the interface, they are fragile. A platform context needs to be carried the same way through the service layer and the queries. In an architecture like this, multitenancy, content management and application workflows are not topics to solve separately; they are parts of the same architecture. A decision made in one directly affects the behavior of the other two.

04Local context and management responsibility

Difference is the very reason subsidiary platforms exist. Each organization may want to manage its own content, its own events and its own applications. At the same time, the main center needs to be able to see the whole. Striking a balance between these two needs is as much a product decision as a technical one.

In the administration interface, this balance shows up most in permissions. Whether an administrator sees only their own platform or several; on which platform a piece of content is published; which organization an application is reviewed by: these are questions that need answers before screen design. A panel written without those answers turns into a panel that keeps collecting exceptions.

05Looking from integration and delivery

My role in this project covered integration and delivery alongside development. That gave me a slightly different angle on the product. Public pages, user areas, administration and the API may seem to work separately, but at delivery they all rest on the same data model and the same platform context. Seeing during delivery how a small change in one layer shows up in the others is a reminder of how much that coherence matters.

User experience, administration workflows and the multitenant service structure have to work together. Not losing sight of the others while improving one is, in my view, the work that needs the most attention on platforms like this.

06What stays with me

The clearest thing I took from this project is that when designing a data model, you need to think not only about the entities but also about the people looking at them. Content visitors, artists, applicants and administrators come to the same record with different questions. A good structure should be able to answer all of them, and do so without fragmenting the data. The way to do that, in my view, is not a technical trick; it is asking again, whenever a new screen or workflow is added, what that data means for the other users.