From Lovable Prototype to Production: Sepatra's Enterprise Cutover

From Lovable Prototype to Production: Sepatra's Enterprise Cutover

About Sepatra

Industry

Freight marketplace / partner platforms

Engagement

Product hardening, cloud migration, and multi-environment delivery

Timeline

About one month from owned infrastructure to production-ready platform

Sepatra needed a live partner and member marketplace: quote intake, partner embeds, admin ops, and CRM handoff. The product owner already had a working prototype. It lived in Lovable.

The problem

That prototype was brief.

No-code and vibe-coding tools have become the new PRD for many product owners. Instead of a long requirements document, Sepatra arrived with clickable flows, real screens, and a first cut of backend behavior. The client built that first version in Lovable and validated the product shape quickly.

Speed got them far. Production asked for more.

Once real users, partner widgets, transactional email, and admin privileges entered the picture, the gaps showed up as engineering work, not as polish:

Hosted edge logic and secrets still sat on a vendor-owned stack.
A single shared database was risky for staging experiments and live traffic.
Auth redirects, RLS, embed URLs, and mail paths had to behave correctly on a domain Sepatra controlled.
Security and delivery habits that feel optional in a sandbox become blocking items when the site takes real partners and buyers.

The ask was clear: keep the product momentum, take ownership of the runtime, and make the platform safe to operate.

What we did

1. Treat the Lovable build as the source of truth for product intent

TechCare did not restart from a blank Figma file. The Lovable app was the living PRD:

Routes
Roles
Partner tiers
Quote flows
Admin surfaces

We mapped that behavior into an owned codebase (React, Vite, TypeScript) and replaced vendor hosting with infrastructure Sepatra could audit and deploy.

2. Give the platform an enterprise operating model

We split environments the way a production product needs them:

EnvironmentGit branchRole
Stagingmain-supabaseInternal QA and integration
ProductionprodLive site (www.sepatra.ai)
PlaygroundplaygroundProduct-owner experiments and demos

Each environment got its own Supabase project (Postgres, Auth, RLS, Edge Functions, storage). Staging and production no longer shared a database. Playground received a schema-mirrored sandbox so the product owner could try ideas without touching live data.

3. Move the heavy path onto AWS Amplify

AWS Amplify hosted the frontends. A custom pipeline tied Amplify apps to the branch model above so a push to playground, main-supabase, or prod built and published the right site with the right Supabase keys. That pipeline carried most of the day-to-day delivery weight:

Preview URLs for demos
Staging for QA
Production for go-live

4. Migrate edge functions, then leave Lovable behind

Serverless work moved into Supabase Edge Functions under Sepatra's projects:

Quote intake
Widget API
Transactional mail
Auth email hooks
Admin helpers
CRM-related notifications

After those functions were deployed, secrets were wired, and smoke paths passed, Lovable was cut off as the runtime. The prototype had done its job. Production traffic no longer depended on it.

5. Put security and delivery practice on the critical path

Production work included the unglamorous checks that keep a marketplace upright:

Row Level Security and privilege boundaries for partners, members, and admins
Auth site URLs and password-reset redirects on owned domains
Service-role secrets kept out of the client bundle
Transactional email through Brevo with queue processing instead of ad-hoc sends
Widget and referral URLs pointed at owned hosts and the correct Supabase project
Documented showstoppers and follow-up hardening so open risks stayed visible

Security and basic ops practice went on the launch checklist with the feature work.

6. Make QA match the migration, not sit beside it

Platform migration is where silent breaks hide: wrong project keys, stale widget.js, broken reset links, mail that never leaves the queue. We introduced a systematic QA rhythm around the cutover:

Smoke checks on auth, quote create, partner embed, and admin paths per environment
Targeted unit coverage where logic was easy to regress (URL builders, privilege helpers, form validation)
Regression passes before promoting staging behavior to production
Short written checklists before partner demos so demos did not become the first test

QA sat inside the migration plan and ran before each promote.

7. Stay agile without stretching the calendar

Delivery ran in short loops:

Ship a vertical slice
Smoke it on Amplify
Fix what failed
Promote deliberately

Scope stayed tied to production readiness rather than a long rewrite:

Owned hosting
Separated data
Migrated functions
Safe partner demos

That discipline is how the engagement stayed inside about a month while still finishing the cutover.

8. Keep the product owner innovating on a dedicated branch

An interesting outcome of the environment split: Sepatra's product owner can keep vibe coding and prototyping on playground, against the playground Supabase project, while staging and production stay stable. Innovation continues on a branch and database built for that purpose. Engineers still promote only what passes QA. The client does not have to stop exploring because production went live.

Sepatra platform interface showing the marketplace overview
Sepatra platform interface showing a partner workflow
Sepatra quote request form for freight shipping

Technology stack

LayerChoices
FrontendReact 18, TypeScript, Vite, React Router, TanStack Query
UITailwind CSS, Radix / shadcn-style components
Backend dataSupabase (Postgres, Auth, Storage, RLS)
ServerlessSupabase Edge Functions (Deno)
EmailBrevo, queue-backed transactional sends
CRMOdoo integration for opportunity sync
Hosting / CIAWS Amplify with branch-based pipelines (playground, main-supabase, prod)
Source controlGitHub (TechCare-Inc/sepatra-two)
Origin prototypeLovable (retired as runtime after edge migration)

Results

Sepatra runs on owned Amplify frontends and owned Supabase projects for staging, production, and playground.
Lovable is no longer in the production path after edge-function migration.
Partner embeds, admin workflows, and quote flows can be demoted and promoted through a clear branch model.
The product owner still has a safe place to prototype (playground branch + playground database) without putting live partners at risk.
Security findings, env separation, and QA habits sit inside the same delivery loop that shipped the platform in roughly a month.

Takeaway for similar teams

If your product owner can already click through a Lovable (or similar) prototype, that artifact is often enough to start an enterprise build. The cutover still has to earn its keep:

Separate databases
A real pipeline
Migrated serverless
Production security
QA that treats migration as the feature under test

When those pieces are in place, the client can keep innovating on a playground branch while production stays stable.

Other Case Studies

AI & Automation

AI Knowledge Base Assistant

Built a Claude-powered chatbot that delivers real-time, personalized answers across teams, automating knowledge sharing and documentation.

AI & Automation

Cleo

At TechCare, the People & Culture team was spending 8–12 hours every week answering the same five Slack questions. The data existed. The problem was access.

Healthcare

DiveThru

Our healthcare platform project won investor confidence, built a lasting partnership, and expanded its reach with powerful mobile and web experiences.