Case study
An artist agency, built like a system
A case study on berlintina.de — the project that is hers alone.
A systems engineer with an AI focus, at home in the terminal long before language models existed. That is the difference this case study shows: she is not carried by AI tools, she directs them — with the discipline an engineering education leaves behind. Architecture, data model and edge cases are settled before the first line is written. What follows is told along a single project she built alone.
15
SQL migrations — schema, permissions, search
3
AI services wired up (OpenAI, Gemini, own layer)
2
Surfaces: public site and admin tool
DE · EN
bilingual, with language switching
2
tables missing row-level security, found + closed in her own audit
The task
An agency is not a contact form
From the outside, an artist agency looks like a website with nice photos. In truth it is a business with two sides that must never meet unfiltered: performers want to be seen, event organisers want to choose. Between them stands someone who reviews — and that review is the actual work.
The obvious shortcut would have been a contact form that sends emails. Instead she built what the business actually needs: a path for applications, a tool for reviewing them, and a catalogue that only shows what has been approved.
Decision 1
The visibility rule lives in the database, not the frontend
A submission may only become public once it has been approved. You can solve that in the frontend — a condition that hides unreviewed entries. It looks correct and isn't: anyone talking to the API directly still gets everything.
In her schema the rule therefore sits where it cannot be bypassed. One migration enforces it, another cleans up the access policies. That is the difference between "looks safe" and "is safe" — and it is the first thing a code review notices.
Decision 2
AI takes over the conversation, not the decision
Performers dislike describing themselves in form fields. So a language model conducts the intake conversation: it asks follow-up questions, drafts the show description and hands over finished copy — with several providers wired up, so an outage or a price change doesn't topple the product.
What matters is what the model may not do. It does not decide on admission. Its draft lands in the review tool, a human sees the page exactly as it will look, edits inline and approves. The AI is a tool inside a workflow, not a replacement for one.
Decision 3
The review tool shows the real page, not a table
Most admin interfaces show records as rows. Whoever approves sees fields — not what visitors will see. Mistakes surface only once they are public.
Her admin panel inverts that: it opens in preview, shows the finished page and puts editing on top as a narrow strip. Corrections happen in place, with a pencil right in the text. That is not a design whim but an error brake — you approve what you actually see.
Decision 4
Search belongs to the side that pays
A catalogue without search is a gallery. But organisers don't search for names, they search for what they need — and describe it in their own words.
So her schema carries a full-text search across the shows, plus dedicated matching logic between request and offer. Both sit in the database rather than in a browser-side filter: that stays fast when fifty entries become five hundred.
Decision 5
She audits her own work before someone else does
A running project rarely gets a security audit on its own initiative — usually only after something has gone wrong. She ran her own, unprompted, and found things she herself had built: an admin login that fell back to a default password when none was configured, instead of refusing access; two database tables holding personal data that had never had an access rule set on them.
Fixes followed the order of risk, not convenience: the login now fails instead of giving way, the token comparison runs in constant time, an endpoint that fetches external URLs now checks every redirect against internal address ranges, and security headers simply hadn't existed before. She verified the database rule live rather than just writing it into a migration file — the same detail from Decision 1, applied here a second time, this time to her own code.
What carries over
No part of this project is exotic. What carries over is the order of operations: first understand who uses the system and who pays for it — then the data model, then the permissions, then the interface. That order is what holds when a project outgrows the head that started it. It is the reason an engineer also carries the work where nobody wrote a specification first.
Verified against the public repository · as of August 2026
Questions about the architecture? info@berlintina.de