StudioSAAS

It is the way.

Comment

Inspiration

StudioSaaS was inspired by a real creative education studio workflow.

Many small art, music, dance, language, and creative learning studios still manage their students with a mix of spreadsheets, paper forms, messaging apps, shared folders, and manual lesson-balance notes. This works at the beginning, but it quickly becomes fragile: registrations are scattered, lesson credits are easy to miscount, student artwork is hard to organise, and every studio has to rebuild the same operational system from scratch.

The original starting point was a working internal CMS for Let’s Paint Studio. During OpenAI Build Week, I used Codex to turn that single-studio CMS into a more reusable multi-tenant SaaS foundation: a platform where each studio can have its own branded CMS, registration page, student records, courses, packages, lesson credits, and portfolio system.

The bigger idea is simple:

Give small creative studios the kind of operating system that usually only larger education businesses can afford.

What it does

StudioSaaS is a multi-tenant CMS and studio management platform for creative education businesses.

It has three main layers:

  1. Super Admin
    The platform owner can create and manage tenants, plans, tenant status, usage, audit records, and database consistency.

  2. Studio Admin
    Each tenant can manage their own studio operations, including:

    • studio branding
    • CMS page appearance
    • registration page settings
    • courses and packages
    • students and guardians
    • lesson credits and balances
    • registration queue
    • portfolio and media management

  3. Tenant-facing CMS / Register pages
    Each studio gets its own public-facing pages, such as:

    • /<tenant_slug>
    • /<tenant_slug>/register
    • /<tenant_slug>/cms
    • /<tenant_slug>/studio-admin

The most important product decision is that Studio Admin is the revenue core. Super Admin should not operate each studio manually. Instead, every tenant should be able to customise and run their own studio through Studio Admin.

How we built it

The project was built as a practical SaaS migration from an existing single-studio CMS.

The current architecture includes:

  • Python backend
  • PostgreSQL database
  • multi-tenant routing
  • tenant-scoped /v1 APIs
  • legacy CMS bridge
  • tenant workspace generation
  • Studio Admin and Super Admin frontends
  • public registration and CMS pages
  • local deployment scripts
  • seeded demo tenants for testing

A key engineering decision was to preserve the existing working CMS through a legacy bridge while gradually moving data and operations into a PostgreSQL-backed SaaS architecture. This allowed the system to stay usable while being refactored into a multi-tenant product.

Codex was used heavily for:

  • code review
  • bug risk scanning
  • refactoring prompts
  • tenant isolation checks
  • auth and session review
  • Studio Admin workflow repair
  • database consistency planning
  • bilingual implementation prompts
  • project documentation
  • regression checklists

Rather than asking Codex to rewrite the whole system at once, I used it as a structured engineering partner: breaking large refactors into small repair tasks, defining acceptance criteria, and keeping the project aligned with the business model.

Challenges we ran into

The hardest challenge was not building one feature. It was keeping the product direction clear.

At first, it was easy to over-focus on Super Admin because that is where platform-level control lives. But the real commercial value is in Studio Admin: tenants need to manage their own CMS, students, registrations, courses, credits, and portfolios. The project had to be re-centred around the tenant experience.

Other major challenges included:

  • keeping tenant data isolated
  • avoiding root-level registration conflicts
  • making Studio Admin settings sync correctly to CMS and Register pages
  • preserving the legacy CMS while moving to a cleaner SaaS architecture
  • ensuring logo, title, colour, and welcome-message changes update across tenant pages
  • preventing authentication changes from breaking normal tenant operations
  • designing a Super Admin that manages tenants without becoming the daily operations panel

One specific bug discovered during testing was that the logo and title inside the legacy CMS sidebar did not update after Studio Admin changes. This revealed a deeper product requirement: tenant branding must not only update the outer wrapper, but also the visible legacy CMS interface inside each tenant page.

Accomplishments that we're proud of

The biggest accomplishment is turning a real studio CMS into a SaaS-ready product direction.

Key accomplishments include:

  • designed a multi-tenant architecture for creative education studios
  • created a clear separation between Super Admin and Studio Admin
  • established tenant-specific CMS, Register, and Studio Admin routes
  • planned PostgreSQL-backed tenant isolation
  • preserved the working legacy CMS through a bridge instead of breaking existing functionality
  • created repair prompts and acceptance criteria for Codex CLI/local AI execution
  • documented the product direction, technical architecture, deployment flow, and repair priorities
  • identified the Studio Admin experience as the true revenue driver
  • built a system that can grow from one real studio into many tenant studios

The project is not just a hackathon prototype. It is a practical foundation for a real SaaS business.

What we learned

We learned that AI coding is most powerful when the human provides product judgement, business context, and architectural constraints.

Codex can generate, repair, and inspect code quickly, but the key decisions still require clarity:

  • What is the business model?
  • Who is the real user?
  • Which interface creates revenue?
  • Which features must be self-service?
  • Which parts should stay simple?
  • Which legacy parts should be preserved during migration?

The biggest product lesson was:

Super Admin runs the platform. Studio Admin creates the value.

The biggest engineering lesson was:

A working legacy system should not be destroyed too early. It should be wrapped, stabilised, and gradually replaced with safer architecture.

The biggest AI workflow lesson was:

Local AI and Codex work best when tasks are small, prioritised, bilingual where needed, and tied to clear acceptance tests.

What's next for StudioSaaS

The next step is to complete the Studio Admin revenue loop.

Priority roadmap:

  1. Full Studio Admin to CMS/Register synchronisation
    Ensure tenant logo, name, colours, welcome message, CMS layout, and contact details update everywhere.

  2. Studio Admin feature completion
    Preserve and improve courses, packages, students, credits, registrations, and portfolio management.

  3. Registration workflow
    Allow public registration submissions to flow into a tenant’s Studio Admin queue and convert into student records.

  4. Tenant onboarding
    Let Super Admin create a new tenant, assign a plan, generate the tenant workspace, create the owner user, and make the tenant ready to use.

  5. Tenant isolation and database consistency
    Strengthen tests so each studio can only access its own data.

  6. Portfolio and media management
    Improve student artwork uploads, visibility controls, and parent-facing portfolio links.

  7. Pilot deployment
    Prepare AWS staging with PostgreSQL, object storage, backups, environment variables, and monitoring.

The long-term vision is for StudioSaaS to become a lightweight operating system for creative education studios: simple enough for small studios, structured enough to scale, and flexible enough to support art, music, dance, language, photography, and other creative learning businesses.

Built With

Share this project:

Updates

Submission history