It stays one app. Inside, it is cut the way a company is cut, so that everyone opens the door to their own work and nobody carries five other departments around. Underneath, all of it sits in the same database.
The app started as a set of SEO tools. Sales came in, then Intra with the personnel file, reports, times, holidays and finances, then Recruiting and Campus, both live since 5 September. Nine tools plus four areas behind one rail is where the old model stopped working: everyone saw everything, and every new tool made the rail longer for people who never open it.
Six doors into the same database. Behind each one sits the work of one department and nothing else.
Recruiting was the first area where we cut it differently. Its door is a checkbox, recruiting.zugang, not a role, because screening is a job and the intranet role would have handed the screener everyone's personnel file as a side effect. Campus went the same way, plus a role called lernender for accounts that exist only to learn: an applicant or a freelancer before the contract sees Campus and nothing else, and the backend keeps that session inside /api/campus.
The database does not follow the split. One Postgres instance on Supabase, one schema per department (superapp, intra, recruiting, campus, and webdev next), with foreign keys across them where the work actually crosses. That is the whole point of doing this inside one app instead of buying four tools: a client project stays one row, an applicant keeps the funnel session it came from, and a report can join all of it without an export.
Agents get the same treatment as people. A Windmill job or a Claude session does not get an admin key any more; it gets a named service token with scopes like webdev:read, revocable, with a log of what it touched. The doors and the database are the same ones. Only the key differs.
Route, door and status as of today. The small name under each department is what the code calls that area.
| Department | Route | Who works there | What is inside | Door |
|---|---|---|---|---|
Sales livesales |
/sales |
Dominik, closers | Prospect rooms, the visibility check before the first call, closing, the Close mirror | Role admin or closer |
Intra liveintra |
/intra |
Everyone internal | Personnel file, reports, times, holidays, finances, and the console where rights are given | Every internal role, plus intra.* checkboxes for the sensitive parts |
Recruiting liverecruiting |
/recruiting |
Whoever screens | Positions, applicants, screening stages, the intake endpoint, applicant mails | Checkbox recruiting.zugang |
Campus livecampus |
/campus |
Everyone internal, plus learners | Courses, lessons, progress, certification | Every internal role and lernender; campus.* checkboxes to teach and assign |
Visibility Machine livevisibility |
/ (tool paths stay) |
Tayfun, the team | Today, Projects, Portal Tracking, Writer, Production, Studio, Scout, Radar, Reports, Forms | Every internal role except backoffice and closer, as today |
Web Factory in buildwebdev |
/webdev |
Enes; Tayfun reading; Dominik | Funnels, conversion analytics, UTM links, website projects with the six gates, site inventory | Checkbox webdev.zugang |
The names. Visibility Machine is decided, including the technical id: those tools produce visibility in Google and in AI answers, and calling that department "SEO" undersells what it already does. Web Factory is a proposal. It picks up the word the team already uses for Anton's six-gate concept and covers everything that department ships: funnels, client sites, our own pages, and the measurement on top. If you have a better name, this is the moment.
The seams are thin and they point one way. A department writes into its neighbour at exactly one moment, then hands over ownership.
Web Factory into Recruiting. When someone finishes the funnel, the completion calls the recruiting intake directly, the same function the external forms use. The applicant lands in the target position as neu, and the file shows where they came from: funnel, variant, UTM, landing page, device. From that second on the application belongs to Recruiting.
Web Factory next to the Visibility Machine. The client project is the shared bracket. A website build in the Factory points at the same client project row the SEO tools use, so Tayfun's launch checks (meta, JSON-LD, Search Console) are a gate in that build instead of a separate list.
Intra into all of them. Every checkbox in every department is given in Intra. More on that below.
Out to Milo. One digest endpoint carries a block per department, so the evening summary reads sessions, completions and open approvals without a second integration.
The role is the house, the checkbox is the room. A department declares its rooms, Intra hands out the keys.
Rights are given in Intra, nowhere else. Every department writes its rights into one catalog with the department as a field, and the permissions console in Intra builds its blocks from that catalog. So a new department shows up there by itself, with its own group of checkboxes. Giving a right needs intra.nutzer, which today means Dominik, and every grant is logged with who did it and when.
Inside a department you can see what your own account may do, and a card tells you where the missing checkbox comes from. There is no page and no route in a department that changes a right. That is deliberate: one place to look when you ask who can do what, and one place to audit.
| Web Factory checkbox | Allows | Proposed holder |
|---|---|---|
webdev.zugang | Enter the department and read everything: funnels, analytics, projects, overview | Enes, Tayfun |
webdev.funnels | Create funnels, edit definitions, versions and variants, open the preview | Enes |
webdev.veroeffentlichen | Switch a funnel live or pause it | Enes |
webdev.projekte | Create website projects, work the gates, add artefacts, slices, QA runs | Enes, Tayfun for copy and SEO slices |
webdev.freigeben | Approve gates and go-live, with a protocol entry | Dominik at the start, Enes later |
webdev.einstellungen | UTM taxonomy, tracking ids, domains | Enes |
webdev.voll | Satisfies every webdev.* right, including future ones | Nobody for now |
Service tokens are named, scoped per department as <area>:read or <area>:write, revocable, and every call is logged. No token can reach credentials, users, the auth endpoints or the token endpoint itself, not even a token with a wildcard scope. Today they exist as an API without a screen, which is why nobody can answer "which key is still valid" without a query. They get their own tab in Intra next to the permissions console.
admin right now, which makes the role field carry almost no information.This is where our public web surfaces are made, go live, get measured and get improved. Our own pages, client websites, funnels. The applicant funnel for setter and closer is the first tenant, because we need it now and it exercises every part of the machinery at once: a public page, tracking, a variant test, and a handover into another department.
Your cockpit. Live funnels with sessions, completions and conversion. Open approvals. Warnings. Below that the client builds and our own sites, open and done, with a responsible person and a status that needs a reason.
stage 1 and 2List and detail: target, design, definition, versions, variants, publish. Version one gives you a validated JSON editor with a preview link.
stage 1Drop-off per step, split by source and by variant, then downstream: how many of those applicants got hired. CSV export.
stage 1UTM generator on a fixed taxonomy, so a job board never arrives as three different spellings. Generated links stay in a list.
stage 1The six gates from the factory handover as a state machine in the database: artefacts, approval protocol, build slices, QA runs, go-live as its own approval.
stage 2Inventory of our own domains: host, repo, last deploy, certificate, robots header, reachable or not. Checked by a nightly job.
stage 2Dominik builds the foundation: schema, rights, public endpoints, tracking, the analytics query, the area shell, and the two funnels as drafts. You take it from there. The step editor with drag and drop, image upload, testimonial and FAQ blocks, the design of the public pages, and new step types are yours, and the step catalog is a single file made for exactly that.
Two rules carry over from the factory handover and from the Glow build, because they were paid for the hard way. Gates live in the database, not in the interface, so a gate cannot be skipped by clicking somewhere else. And "done" on the cockpit means accepted, not live: a page that is online but nobody signed off is still open work.
After the funnel, the department grows in two more stages. Server-side Meta conversions from the completion event, with hashed contact data and no browser pixel, so we measure ad performance without a cookie banner. Then conversion work beyond the funnel: events on omni1.ch, experiments on landing pages, portal visits in the same analytics.
The split above is a proposal, and so is every right in it. You work in this app more than anyone, so bring the objections while changing it is still cheap.
Answer in the Slack thread, or bring it to the UI review on Tuesday 8 September.