Zenosoft — our own product
Zeno Studio
15
Custom modules
28
Custom entities
0
Nodes
EN + TR
Languages
Drupal 11 as an application framework
Zeno Studio manages dance and pilates studios: branches, classrooms, courses, schedules, enrolments, attendance, payments and instructor pay. It replaced a Windows desktop application that had been running a real business since 2014.
It is built on Drupal 11, and it contains no nodes. Twenty-eight custom content entities model the domain directly, across fifteen modules. Business logic lives in a service layer that both the administrative interface and the HTTP API call, so the two cannot drift apart — the API is not a later translation of the UI, it is the same code.
It is sold as software as a service. One codebase, one database per customer studio, and a single command provisions a new tenant.
What it does
Scheduling that materialises
Recurrence rules generate real session records up to a configurable horizon, so a session can be edited, cancelled or reassigned without breaking the pattern it came from.
A calendar-first admin
Month, week, day and list views, plus a classroom-grid "Week Rooms" view that lays out rooms as columns. Filters for branch, classroom, instructor and subject.
Conflict detection
Across classrooms, instructors and students — including across branches, with per-branch rules for how strict to be.
Enrolment and waitlists
A full waitlist lifecycle: join, notify in bulk, approve to capacity, convert to enrolment. Students can self-register, with optional admin approval.
Two billing models
Per-lesson and period packages, with billing grids that lock a price snapshot per period and reconcile automatically when the schedule changes underneath them.
Tokens and credit
Token packages, balances and a transaction ledger, with configurable consumption timing and cancellation windows. Undelivered value can be refunded or moved to another course.
Instructor compensation
Flat rate, per student or percentage, resolved down a scope hierarchy from session to company — most specific wins, no stacking — then a draft, pending, approved, paid payout workflow.
Branch-scoped access
Enforced in three layers: entity access handlers, query-level filtering on list builders, and branch filters in the calendar and API. A supervisor cannot see another branch's data.
Bilingual from day one
English and Turkish throughout, with translations shipped in the modules and imported on deploy rather than re-entered per customer.
The Week Rooms view
Most calendar interfaces answer "what is happening on Tuesday". A studio manager needs "is the mirror room free at six" — a different question that a standard week view answers badly.
So there is a view that puts classrooms across the top and time down the side, one block per day. It is the screen the product is actually used from.
Three audiences, three surfaces
Studio administrators and branch supervisors work in a back office built on Gin. Instructors see their own sessions, mark attendance and review their pay. Students browse the catalogue, enrol, reserve places and check their attendance and payments.
How it was built
The system it replaced was a Windows application on SQL Server, holding a decade of real operating history. Migrating it meant a documented, repeatable extract-transform-load process — not a one-off import — because it had to be run many times against live data before it was run for real. The finance reporting the old system never produced cleanly came out of the same exercise.
A node is a good page and an awkward domain object. Sessions, enrolments, payouts and token transactions have their own access rules, their own lifecycles and their own invariants, and expressing those through node types and field permissions produces a system nobody can reason about. Custom content entities cost more up front and less every week afterwards.
Controllers are thin and business logic lives in services. The HTTP API is transport over those same services rather than a parallel implementation, which is the only arrangement where an API and a UI stay consistent without constant effort.
Calendar defaults, materialisation horizon, cancellation windows, currency, billing mode, proration, waitlist thresholds and notification toggles are all settings. Studios differ from each other in exactly these ways, and a fork per customer is not a business.
Need something like this?
If your operation is being run out of a desktop application or a spreadsheet, the interesting conversation is about what it would take to replace it.
Services delivered
Custom Drupal applications
Drupal used as an application framework — custom entities, services and access control — when the thing you need is not a website.
Content migration
Getting years of content out of an old system and into a new one with its structure, its media and its URLs intact.
Platform engineering and DevOps
Local environments that match production, pipelines that catch problems before review, and deploys that are boring.