DEPLOYMENTS / DRUŽINA PUBLISHING WORKFLOW
WORKFLOW SOFTWAREDružina Publishing Workflow
Internal publishing workflow software that moves every publication through editorial, prep-and-design, print and distribution. Phase-specific forms, role-based approvals, one-click Excel handoffs and a permanent activity log keep every department working from the same source of truth.
CLIENT
Družina publishing
YEAR
2025 — ongoing
SYSTEMS
WEB
STATUS
DEPLOYED
4
workflow phases (departments) per publication
3
user roles: member · admin · superadmin
18
months in continuous production use
[ THE BRIEF ]
The challenge we walked into.
A national publisher was running its weekly editions on shared spreadsheets and email. Editorial decisions were invisible to the print manager, directors couldn't see status without asking, and the print house needed a specific technical-spec .xlsx that was being hand-produced every week. We needed one platform where the whole lifecycle lived — with clear roles, real approvals and a printer-ready export at the end.
[ TOPOLOGY ]
How the system is wired.
// SYSTEM TOPOLOGY
[ WHAT WE SHIPPED ]
Feature by feature.
Urednistvo → Priprava → Tisk → Distribucija.
Every publication moves through four ordered departments: editorial, prep-and-design, print, distribution. A project_phases row is created for each department at project-creation time; each phase has its own start/end date, its own required fields, and its own status. The next phase unlocks only when the current one is complete.
- ▸Ordered per-phase rows on project creation
- ▸Phase-specific required fields
- ▸Independent start/end dates per phase
- ▸'v čakanju' status until the previous phase completes
[ APPROACH ]
How it came together.
01 — MODELING THE WORKFLOW
Publications aren't all the same shape.
A weekly, a monthly publication and a one-off book need different fields at each department. Rather than a single bloated form, the Zod schemas branch by type; a tednik shows technical print specs the others hide, publikacije shows appendix + issue-number fields, and knjiga captures vrsta izdaje. The UI stays clean because the model is clean.
02 — TRUSTING THE ROLES
Permissions live in the database, not the router.
Row-level security gates reads and writes on every table. When a new user is provisioned with a role (member / admin / superadmin), they get exactly the visibility their role prescribes — and the same policy that hides a row in the UI would also block a curl request against the API. Directors can approve; superadmins can confirm on someone's behalf; members can only advance their own phases.
03 — SERVER ACTIONS EVERYWHERE
No REST layer, no client-side supabase calls.
Every mutation is a typed server action colocated with its component. React Hook Form + Zod validate on the client; the same Zod schema runs again on the server before the write. There is no separate API to keep in sync with the UI — the boundary is the function signature, and TypeScript enforces it.
04 — SHIPPING INTO A WORKING TEAM
18 months of deployments were events, not disruptions.
The publisher couldn't afford downtime — the paper ships every week. We rolled out risky features behind flags, kept old flows available during migrations, and shipped small safe increments. 18 months in, no data loss, no rollback, and the client can point at any weekly edition and tell you exactly which director confirmed which layout on which day.
[ DELIVERY ]
What the build looked like.
01 ▊
[ TECH STACK ]
What’s under the hood.
HOVER FOR ROLE
[ IMPACT ]
What changed.
The publisher moved from spreadsheet-and-email chaos to a single source of truth. Weekly throughput accelerated because print handoffs are one click, directors see status without asking, and every approval — every layout confirmation, every print-run decision — is permanently logged against the project. The platform has been in daily production use for 18+ months with no rollbacks.