Kenlet: how one school's CRM became a product on the market
The system was built for a single dance school. It has been in daily use for six months, and it now has a name, a website, a price and licensing, and other schools are in talks to adopt it.
What was wrong
The CRM for the DaSaBelle dance school was conceived as an internal tool for a single client. It took root: administrators, teachers and the director use it every day, and about a hundred students a month go through the system. That raised a question for a product owner rather than a developer: can this system be sold to other schools, and what would have to change? The answer came down to three things. The product needed a name and a clear price. It needed a way to sell access and switch it off without losing the client's data. And since July 1, 2025, personal data of Russian citizens may not be initially collected and stored in foreign databases, while the system ran on Google Firebase. The fine is up to RUB 6 million, and up to RUB 18 million for a repeat offense.
What I did
The product got a name, Kenlet, a website, kenlet.ru, and pricing plans. The core interface principle stayed the same as in the first school: staff should be doing their work, not guessing where to click. There are now eight roles: director, administrator, manager, marketer, teacher, senior teacher, finance officer, and student with a personal account. Permissions can be set per role and per individual. For students I built gamification: achievements with a rule builder that can handle even a combination like "attended a class on their birthday", plus a leaderboard. For the school this means better attendance; for the student, a reason to come back. For sales I built a separate license management console. Each license is cryptographically signed (Ed25519), so it cannot be forged on the client side. When a license expires, the system does not delete data or lock users out; it switches to read-only mode. The school can see everything but cannot keep working without renewing. To comply with 152-FZ, I prepared two plans for migrating from Firebase to servers in Russia, with an effort estimate for each. I chose a custom backend on FastAPI and PostgreSQL. The migration runs as a separate project: the existing school keeps working with no changes, as agreed with the client.
What changed
Kenlet has been running in a live school for six months. Two schools are in talks about adopting it. Licensing works in production: read-only mode has been tested live. The legal risk under 152-FZ was identified before the first sale and is being closed through architecture, not through promises in a contract. The roadmap is planned 12 months ahead. The case shows the shift from "build us a system" to product-owner decisions: the sales model, revenue protection, legal requirements and obligations to the first client.
Product screenshots
Want the same result?
Let's start with a free review - 30 minutes to see where your business loses money on IT.
Book a review