Case study · Platform & mobile app
KizzyDance — social dance super-app
Web platform and mobile app for the international dance community, in continuous production since 2018, without major interruption.
Engagement period: · Page last reviewed on
Context
KizzyDance brings together a global community of dancers around events, classes and dedicated social features. The platform serves tens of thousands of active users and requires 24/7 availability, fast update cycles and tight cloud cost monitoring.
Challenge
Maintain a long-lived platform (web and mobile) while continuously shipping new features without regression, with a small team and strict cloud budgets.
Approach
SeedVision owns the entire DevOps chain: end-to-end CI/CD, monitoring (incident alerting and performance tracking), critical PostgreSQL migrations, continuous cloud cost optimisation and security hardening. A runbook enables the product team to deploy autonomously.
Engagement timeline
- — Go-live. The web platform and the mobile app open to the community. The operations engagement starts the same year: the deployment chain and monitoring ship with the product rather than being bolted on later.
- — Continuous operations. 8 years of uninterrupted service. Security patches, database migrations and mobile framework upgrades follow one another without major interruption for users.
Before and after
Release cadence
Before: A release that depends on one person and a maintenance window: update frequency is capped by the cost of each trip to production.
After: Deploy cycles brought under 30 minutes, triggered from the continuous integration chain.
Cloud bill
Before: Infrastructure sized for the peak and never revisited is paid all year at the price of its busiest hour.
After: More than 35% less cloud spend over 24 months, with no reduction in the scope served.
Availability
Before: Without monitoring, an incident is discovered by users — too late to avoid the outage.
After: 8 years of production with no extended major incident, alerts wired to signals that carry a user-visible consequence.
Product team autonomy
Before: A product team that cannot deploy on its own waits for its supplier to fix a line of copy.
After: An up-to-date runbook lets the product team deploy without SeedVision.
Results
- 8 years of production with no extended major incident
- Deploy cycles brought under 30 minutes
- Cloud cost reduced by more than 35% over 24 months
- React Native mobile foundation kept up to date with OS versions
Technologies and scope
- React Native
- Node.js
- PostgreSQL
- DevOps
- En production depuis 2018
Engagement period:
What the engagement covers, block by block
- Continuous integration and deployment chain — Build, tests, image publishing and environment deployment. The same path serves the urgent fix and the planned change: there is no emergency procedure less tested than the normal one.
- PostgreSQL database — Schema migrations on a live database, backups verified by actual restore, slow-query tracking. A backup that is never restored is not a backup, it is an assumption.
- React Native mobile app — A single foundation for both app stores: OS upgrades, native dependencies, publishing and handling of store review rejections.
- Monitoring, security and cost — Alerts on errors, latency and saturation; hardening of access and dependencies; regular review of sizing and of resources left running.
What running it demands
- A database migration is not decided at cutover — On a live database the risk arrives in the minutes that follow: long-held locks, query plans that flip. Every critical migration is therefore reversible and shipped separately from the code that uses it.
- An alert that calls for no action must go — Noise is paid back as reaction time on the day the incident is real. Only signals tied to a user-visible consequence stay wired to on-call.
- The runbook is a living deliverable — A runbook nobody replays ages faster than the platform. It is corrected on every procedure change, and the product team is the one executing it — the only test that proves it is right.
Architecture choices, and why
- One mobile foundation rather than two native apps — React Native for a small team: one codebase, two stores. The trade-off is a dependency on the framework's calendar; it is accepted and budgeted into maintenance rather than endured.
- PostgreSQL as the single source of truth — One relational database, no specialised engine added until the need is proven: fewer components to back up, monitor and upgrade over eight years.
- Short releases rather than big versions — A small change is reviewed, deployed and rolled back quickly. That is what makes a sub-30-minute cycle useful: when something breaks, the surface to examine is a handful of commits.
Technical and regulatory milestones
Public, dated facts that constrain the scope.
- — GDPR becomes applicable. A public fact, not a project date: the European data protection regulation applies from that day. The platform opened the same year, so it has run under that regime since its first day in production.
- — PostgreSQL 16. Every major PostgreSQL release is supported for five years by the community. That public calendar, not an internal preference, sets the pace of database migrations.
- — React Native 0.76. This release makes the new architecture the default. An app published since 2018 goes through such shifts: keeping the foundation current with OS versions is part of the engagement.
Questions about this engagement
Why does a platform launched in 2018 still need an operating engagement?
Because its environment moves without it: each major PostgreSQL release is supported for five years by the community, the React Native foundation switched its default architecture, and a security patch cannot be scheduled. The engagement covers those upgrades and the database migrations, not the addition of features.
How does the product team deploy without SeedVision?
It uses the same continuous integration chain, whose cycle is under 30 minutes. The runbook is corrected on every procedure change and the product team is the one executing it: a runbook nobody replays would be wrong on the day it matters.
Does this work on a platform built by someone else?
Yes, that is what the Run & maintenance offer is for: a takeover week audits the code, the runbook and the dependencies before any on-call commitment. If technical debt is too heavy, a remediation is proposed before the run.
Related services
- MLOps industrialisation — 15 to 30 days
- Run & maintenance — Monthly retainer or daily-rate engagements
Nearby case studies
Related reading on the blog
- Gemini 3.5 Flash: What Speed at Lower Cost Means for Production Agents
- deepsec: An Open-Source AI Agent for SAST, by Vercel
- Sleeper Agents: A $1,000 Backdoor That Benchmarks Miss
- AI Spend Quotas in Real Time: Jamf's IAM Pattern for Bedrock
- Claude for Finance: Anthropic Ships 10 Ready-Made Agents
- GitHub Copilot Goes Usage-Based: An MLOps Playbook for June 1
- A/B Testing Models in Production Beats Shadow Traffic Alone
Talk about your project
Facing a challenge close to KizzyDance — write to contact@seedvision.fr — reply within 24 hours.