A strategic pivot from single-operator production platform to SaaS for creative producers. Same product. Different customer. Different business.
“I don't want to produce a million projects a year.
— Roy, on the realisation
I want to do the work I love — and have the tool I built earn quietly while I do it.”
Bento OS was designed as ByBento's internal operating system. Roy runs the production company, manages clients, assigns freelancers, handles quoting and invoicing. Revenue comes from project margins (COGS + 25–30% management fee).
Roy is the bottleneck. The business doesn't scale, and it isn't sellable.
Roy is the customer, not the clients or freelancers. There are thousands of creative producers with the same problem: managing multiple clients, crews, budgets, schedules, deliverables and payments across concurrent projects.
They need the same tool Roy is building for himself.
Is “creative producer” a real category, or a hopeful hypothesis?
Real and growing. Still an emergent self-descriptor rather than a formally codified job title — which is exactly the right moment to own it.
Profiles using “creative producer” as a primary title have grown steadily since ~2019 — especially in commercial photography, branded content, and social video. The exact cohort Bento OS targets.
APA (Advertising Producers Association) and AICP separate creative producer from line producer or executive producer. The first handles concept, clients, and crew assembly. Exactly Roy's archetype.
Mid-career creatives (5–10 years in, often ex-agency) reposition as creative producers to access bigger briefs they can subcontract rather than execute alone. The career arc Roy has lived himself.
Used by practitioners in Cape Town and Johannesburg's branded content and advertising sectors — less formally than US/UK, but meaningfully. Roy's immediate network is inside this cluster.
Current stack: Google Sheets, WhatsApp groups, Dropbox, Xero. Notion and Airtable for the more organised tier. There is no purpose-built tool for this archetype. That's the opening.
Lead with “creative producer” as the aspirational identity Bento OS is built for — not just a job title, but a business model. The solo creative who runs multi-person projects. Bento OS is the operating system that makes the leap from freelancer to creative producer viable.
Same features. Different model. Compounding outcomes.
How the same code becomes a multi-tenant SaaS without rocking the boat.
You can't be a competitor and a tool provider under the same name. Three entities, three brands, three roles.
The SaaS product. Workspaces, subscriptions, recurring revenue.
The businessRoy's production and photography work, run as a sole proprietor.
Personal incomeThe legal entity that owns and operates Bento OS.
Behind the scenesByBento as a production-company brand retires. Roy doesn't need a new entity — sole proprietor under his own name handles the production work cleanly.
Each producer gets a fully-isolated workspace. Bento OS is the platform that hosts them.
Each workspace is fully isolated. Producer A cannot see Producer B's clients, quotes, or freelancers — enforced at the database via Row-Level Security.
Roy runs his production work as Workspace #1. SaaS subscription revenue is the business; production income is personal.
Many creatives wear two hats. The platform supports both for the same person.
What's the cleanest pattern? Single account with role toggle (Uber driver/rider model), two linked profiles, or context-dependent views? This affects the data model, auth flow, and UX.
Open by default. Free to list. Booking fee on value delivered.
The original "private pools" model created a chicken-and-egg problem: free freelancers had no incentive to sign up if they were invisible to all but the producer who onboarded them. Producers had no value in browsing.
Open listing creates a flywheel. The booking fee monetises the moment value is delivered, not access.
Freelancers create a profile with skills, equipment, portfolio, availability, rate card.
By default, visible to all producers. Optional: exclusivity to specific producers.
Filter by skill, location, availability. Invite directly from the directory.
Charged to the freelancer when booked through the directory. Not a commission. Direct onboards (outside the directory) are free.
What's in the build. What stays the same. What changes. Where the boundaries are.
The features Roy needs are the features other creative producers need.
Bookem-level invoicing, not full accounting. Producers quote, invoice, and track payments inside the platform.
Why not? Handling other people's money in SA requires being an authorised financial service provider. Different industry, different regulations, different liability. Hard no.
Reference product: Bookem ↗ — SA practice management software with similar invoicing scope and customisation model.
Three tiers at launch. Agency tier deferred until validated.
Freelancers who want to be listed and receive jobs
Independent creative producers with their own clients
Small production companies and busy creative producers
Pricing is illustrative. Validation needed with 5–10 real target creative producers.
The good news from the technical audit. The numbers. The path forward.
A deep audit of the current Bento OS 5 codebase revealed something unexpected.
workspaces table
Producer accounts sitting above client companies
workspace_id to ~8 tables
Scope packages, quotations, inquiries
+2–3 weeks to the existing sprint. The core feature work (projects, quotations, packages, freelancer portal, client portal) is identical — Mindlink builds the same features, just scoped to a workspace instead of globally.
Production revenue is linear. SaaS revenue compounds.
To match today's R30k/mo ceiling, Roy needs ~30–40 paying subscribers. To surpass it, ~50+. Achievable in the SA creative industry — if the product is good. After 12–18 months of moderate growth, SaaS revenue could significantly exceed what production work could ever deliver.
Four phases. Don't market until Roy has used it on real projects first.
Naming the things that could go wrong, and how we handle each.
"Thousands like Roy" is a hypothesis. SA creative industry is small.
→ Roy validates by using the product first. Then 5–10 beta invites to creative producers he knows. No marketing until demand is proven.
CTIJF, Defender Trophy, photography website, ROYS_OS, Bento OS — Roy's bandwidth is real.
→ Don't acquire external users until Roy has run 3–5 real projects through the platform. Launch = Roy using it.
Data leaking between workspaces would be catastrophic.
→ Comprehensive test suite: User A cannot see User B's data. Mindlink advises on the refactor approach.
+2–3 weeks to the sprint, not months.
→ Workspace layer is additive. Build features as planned, add scoping.
Onboarding UX, support, docs, billing management — all new work.
→ Defer all of it to post-MVP. First version: invite-only, Roy + 5 friends.
Producer + freelancer profiles add UX and data model complexity.
→ Get Mindlink's recommendation on the cleanest pattern before building.
First guess is usually wrong.
→ Start with Free + one paid tier. Iterate from real usage.
Platform does not handle producer-client money.
→ Producers collect their own payments. Platform only collects subscription fees.
What changes for Mindlink, what doesn't, and the three architectural questions we need a recommendation on.
“We're building the same product, but instead of it being my internal tool, it's a SaaS that any creative producer can sign up for. I'm User #1 under my @roywrench brand. The features are 70% identical. The database is already 80% ready for multi-tenancy. It adds 2–3 weeks to the sprint but changes the business from a production company to a software company with recurring revenue.”
— The 30-second version
workspaces table and scope all data to workspacesWhere we need your architectural recommendation before building.
We need to replace ~47 RLS policies that currently use global is_admin()
with workspace-scoped is_workspace_admin(workspace_id). What's the
safest approach? What testing pattern do you recommend to verify workspace isolation
and prevent cross-tenant data leaks?
Roy (and many users) need to be both a producer (paid workspace, manages clients) and a freelancer (listed in directory, gets booked by other producers). What's the cleanest architecture? Single account with role toggle? Two linked profiles? Context-dependent views? This affects the data model, auth flow, and UX.
Recommendation on building basic in-platform quoting + invoicing (Bookem-level: create, send, mark-as-paid, track) versus integrating with Xero/QuickBooks. We're leaning towards basic in-platform for MVP with integrations as a Phase 4 feature, but want your view on the technical implications.
For reference. These are locked.