A marketplace MVP with five modules — a vetted caregiver marketplace, training academy, events engine, paid memberships and a full admin console — built as one platform for three audiences in two languages, and running in production today.
“They delivered on time and were very proactive in recommending new capabilities for the marketplace.”
SigmaticAI delivered a complete MVP with five feature areas, including a vetted caregiver marketplace, membership plans, courses, and events. The team was proactive, talented, and knowledgeable, recommending new capabilities and using the latest technology.
Ara VazquezFounder, The Raising Club
5
Product modules, shipped as one platform
95
Postgres tables, every one under row-level security
First commit 29 May 2026 · five-module platform in production 2 July 2026
Scope
Product architecture · Full-stack build · Payments & billing · Admin tooling · Native mobile app · Handover & training
The problem
Childcare gets coordinated across a dozen disconnected tools. The Raising Club wanted it to be one place.
Ara Vazquez spent eight years running a bilingual early-childhood program in New York, watching the same pattern repeat: families find caregivers on one site, vet them on another, pay through a third, book classes on a fourth. And a caregiver’s training stays invisible — a claim in a bio, not something a family can check.
Her answer was one membership holding all of it. That is five substantial products, and they had to launch together, on a fixed window, and afterwards be operable by someone with no technical background.
Three audiences, one product
Parents, caregivers and organisations each need their own home screen, navigation and permissions — without this becoming three apps, or a generic directory.
Trust is the product
A childcare marketplace where verification is a phase-two feature has no reason to exist. ID checks, background screening and visible badges had to ship in release one, wired into search.
Bilingual on day one
The community this was built for is bilingual. English and Spanish had to be a routing concern from the first migration, not a layer bolted on later.
A non-technical owner
Plans, prices, courses, events, users and even payment keys had to be editable from an admin console. No deploys, no env vars, no developer on call.
A fixed launch window
Production fast enough to start onboarding real caregivers — which ruled out a discovery phase that produces documents instead of software.
What we built
Five modules, one platform
Each of these would be a project on its own. They share one schema, one permission model and one payment path — which is the only reason five of them could ship together. Each has its own page with the full breakdown.
The whole platform, end to end: the caregiver marketplace, the academy, events, memberships and the admin console, in the build that is running in production.
A two-sided market where families post care needs, caregivers apply, and organisations build a staffing bench — with verification visible at every step.
Families post care roles with structured requirements: care type, schedule, pay rate, hours per week, start date and child age groups.
Caregivers filter by care type, child age, location and keyword, save listings, and apply in one click with an optional cover note and proposed rate.
A real application pipeline — Applied → Under Review → Shortlisted → Hired or Declined — visible to both sides, with duplicate applications blocked at the database.
A complete LMS where the credential a caregiver earns becomes a searchable filter in the marketplace — the mechanism that makes the whole platform cohere.
A course builder with chapters holding modules, and modules mixing rich text, embedded video and downloadable resources.
A final quiz — the “Integration Moment” — with a configurable pass mark, unlimited attempts, and answers revealed only after passing.
Certificates with configurable signers and footer text, issued automatically on completion.
A subscription business the owner can reconfigure without a developer — plans, prices, seats and Stripe credentials all live in the database.
A database-driven plan catalogue with monthly and annual pricing, seat limits, feature lists and per-audience presentation — created and edited entirely in the admin console.
Stripe subscriptions with a customer portal, plus one-off checkout for paid events and courses, all fulfilled by a single webhook.
Entitlement is recomputed server-side and stored as a snapshot on each profile, so every access check is one indexed lookup rather than a Stripe round-trip.
After the web platform went live we shipped an iOS and Android client in Expo. It talks to the same Supabase project as the web app — the same tables, the same row-level security, the same SECURITY DEFINER functions. There is no second API and no second permission model to keep in sync.
Expo SDK 54 with Expo Router, TypeScript and a shared brand token system.
The onboarding state machine is reused verbatim from the web app, so someone can start signing up on their phone and finish in a browser.
A route gate resolves session state on launch: no session goes to welcome, a partial signup resumes mid-onboarding, a complete profile lands on the dashboard.
Marketplace, events and course surfaces built against the same query layer as the web app.
How it was built
Dependency order, shipped continuously
We built the data model and the permission system first, then layered the five modules on in order of dependency. Each one went live as it finished rather than waiting for a big-bang release — 208 commits, deployed continuously.
Phase 1
Schema, roles and the onboarding spine
Four roles on a profiles table mapped 1:1 to Supabase Auth, with row-level security written into every migration from the first table. Onboarding was built as a tested state machine before any screen was designed — every other module reads what it collects.
Phase 2
The marketplace
Job posts, applications with a real status pipeline, applicant management and messaging — with trust and safety filters built into search from the start rather than added to it later.
Phase 3
Training academy and events
A course builder (chapters, quizzes, certificates) and an events engine (sessions, capacity, waivers). Skills earned in a course feed marketplace search — the link that connects the two commercially.
Phase 4
Memberships, Stripe and households
A database-driven plan catalogue, Stripe subscriptions and one-off checkout fulfilled by a single webhook, an entitlement snapshot on every profile, and shared family households with seat limits.
Phase 5
Admin console, verification, bilingual release
Twenty-three admin screens, identity and background checks wired to a third-party provider, and English and Spanish routing — then production.
After launch
Native mobile app
An Expo client for iOS and Android on the same Supabase backend — same tables, same policies, same onboarding state machine. No second API to keep in sync.
Architecture
One database, one deployment, one payment path
One Postgres database with authorisation enforced in the database itself, a Next.js App Router front end that reads it directly from server components, and a single payment path. No microservices, no separate API tier, no ORM abstraction sitting over the security model.
Front end
Next.js 16
App Router
React Server Components
TypeScript
Tailwind CSS v4
Turbopack
Server components read Supabase directly under the caller’s own credentials, so row-level security applies to page rendering as well as to mutations.
Data & auth
Supabase Postgres
Supabase Auth
Supabase Storage
47 SQL migrations
Row-level security
SECURITY DEFINER RPCs
95 tables, every one with RLS enabled and its policies colocated in the migration that creates it. Migrations are hand-written SQL applied in a documented order.
Payments
Stripe Subscriptions
Stripe Checkout
Customer Portal
Webhook fulfilment
Subscriptions, paid events and paid courses share one webhook and one entitlement recomputation. Price and role are always re-read server-side, never trusted from the client.
Trust & safety
Authenticate.com
ID verification
Background checks
Risk scoring
Digital waivers
Checks run under explicit user consent. Results stay private to the caregiver and to families who request care, and drive the verified badges used in marketplace search.
Delivery
Vercel
Continuous deploy from main
Stable staging alias
Resend
Push to main deploys to production; a stable staging alias lets a release be reviewed against real data before it is merged.
Mobile
Expo SDK 54
Expo Router
React Native
Shared Supabase backend
Same database, same policies, same onboarding state machine as the web app.
The production schema — 95 tables spanning profiles and roles, marketplace, courses, events, billing, households, notifications and verification. Every table carries its own row-level security policies.
Engineering decisions
The six calls that shaped the build
Every one of these was a fork where the fast answer and the right answer differed. They are the reason the platform could keep absorbing modules without collapsing under them.
01
Authorisation lives in the database, not in the application
A forgotten check in application code fails closed. The public surface of every private table is an explicit, reviewable list of functions instead of an accumulation of policy exceptions.
The problem
A platform holding children’s names, home addresses, emergency contacts and background check results cannot depend on every route handler remembering to check permissions. One missed guard is a breach.
What we did
Every table is owner-only by row-level security. Anything that must be publicly readable — a caregiver’s marketplace profile, an organisation page — goes through a SECURITY DEFINER function that validates the request and returns only safe fields: no email, no phone, last initial only. When a new public view is needed we add a function; we never loosen a policy.
02
Onboarding starts before the account does
Signup can be abandoned and resumed on another device, and nothing is re-keyed at conversion. The account a caregiver ends up with is the one that has been accumulating their answers since step one.
The problem
Caregiver signup collects a lot of information. Asking for an email and password on step one loses people who have not yet decided the platform is worth it; asking at the end risks losing everything they typed.
What we did
Entering onboarding creates a Supabase anonymous user and a progress row immediately. At the profile step that same account is upgraded in place to a permanent one, so the auth identifier and every saved answer carry over untouched.
03
The onboarding wizard is a tested state machine, not a sequence of pages
The flow could be reworked repeatedly during the build without breaking resume — and the mobile app reuses the module verbatim instead of reimplementing it.
The problem
Onboarding branches by role, and the caregiver path branches again on whether they want paid work or community. Encoding that in navigation code makes every later change a regression risk.
What we did
Steps, branches, progress and resume logic live in one versioned module with its own unit tests; screens read from it. A single promotion step writes the collected answers into the typed role tables at completion.
04
Entitlement is a snapshot, not a question asked at read time
Reads are one indexed lookup. Subscriptions, admin comp grants and shared family plans all resolve through the same path, so a comped account behaves exactly like a paying one.
The problem
Access depends on subscriptions, comp grants and shared household seats. Resolving that on every page load would mean joins across three tables, or a call out to Stripe.
What we did
A SECURITY DEFINER function recomputes entitlement and denormalises the answer onto the profile: active plan, status, expiry date. A ledger table records every assignment — Stripe or manual — against a polymorphic subject that can be a user, a household or an organisation.
05
Stripe credentials live in the admin console, not the environment
The owner switched the platform to live payments herself. No deploy, no engineer, no key pasted into a chat window.
The problem
Keeping API keys in environment variables means the owner needs a developer, and a deploy, to move from test mode to live — or to rotate a key.
What we did
Test and live key sets are stored as an admin-managed record with a mode toggle, masked secrets and a test-connection action. The Stripe client resolves the active mode’s keys at call time, falling back to environment variables if none are configured.
06
Training and the marketplace are one system, not two
Training has a payoff a caregiver can see, families get a signal that is earned rather than self-declared, and the membership has something concrete to be worth paying for.
The problem
Most platforms bolt a course library onto a marketplace and the two never touch. Caregivers then have no commercial reason to train, and families gain no new signal.
What we did
Skills are attached to courses by the admin. Completing a course awards those skills to the caregiver, they appear as verifiable badges on the public profile, and they become filter criteria families search on in the marketplace.
The product
Screens from the live platform
Taken from production and from the admin console built alongside it. Click any shot to enlarge — each module page carries the rest.
The public homepage — one club, framed for three audiences.The marketplace landing page, with entry points for parents, caregivers and organisations.Posting a care role — structured fields with server-side validation, saveable as a draft.A job detail view: requirements, pay, schedule, family details and a direct message action.Trust and safety filters — narrowing search to identity-verified and background-checked caregivers.A caregiver profile — experience, verification state, and the badges earned through training.
Outcome
What the client ended up with
Live, and operating
First commit on 29 May 2026; the full five-module platform in production on 2 July 2026, released continuously across 208 commits rather than in one big-bang launch.
Five modules, not five projects
Marketplace, training, events, memberships and the admin console shipped as one product on one schema — training credentials feeding marketplace search, and a single payment path serving all three revenue lines.
The owner runs it without us
Plans, prices, courses, events, users, notifications and Stripe credentials are all editable from the admin console. No deploy is needed to change what the business sells.
Bilingual at launch
English and Spanish routing shipped in the first release, so the community the founder built this for could use it in their own language from day one.
Extended to mobile without a rewrite
The native iOS and Android client reuses the same database, the same security policies and the same onboarding state machine. No second backend was written to support it.
A codebase built to be handed over
Hand-written ordered migrations, a tested onboarding module, colocated security policies and two written manuals — the platform is legible to whoever maintains it next.
Next.js 16
React Server Components
TypeScript
Tailwind CSS v4
Supabase
PostgreSQL
Row-Level Security
Stripe
Expo
React Native
Vercel
Resend
Authenticate.com
i18n (EN/ES)
Handover
Delivered means you can run it without us
A build is not delivered when it deploys. It is delivered when the client can run it without us. We write the documentation as part of the product, not as an afterthought.
19-page Admin Handover Guide
A step-by-step manual for managing users, events, courses, plans and payments — written for a new administrator with no technical background. Every screen, every field.
19-page Course Creation Guide
A second manual covering how to build, price, publish and manage a training course: curriculum structure, quiz configuration, certificates and enrolment management.
Marketplace launch handoff
A feature-by-feature statement of what was built and verified across job posting, discovery, application and applicant management, with the accounts used to validate each path.
Navigation flow maps
Documented navigation and back-button behaviour across courses, events, marketplace and settings, for both the member-facing and admin-facing side of every module.
A repository the client owns
Application code, migrations and operational scripts live in a repository the client owns, with the migration run order documented alongside them.
Investment
What a build like this costs
Fixed scope, fixed timeline, agreed before a line of code is written. You know the number and the date up front — no hourly meter, no change-order surprises.
Single-module MVP
One marketplace, one booking flow, one internal tool — with auth, payments, an admin view and a real handover. Typically 3–5 weeks.
Multi-module platform
Something the size of The Raising Club: several products on one schema, subscriptions, role-based surfaces and an operable admin console. Typically 8–12 weeks.
Continuing work
A monthly retainer for feature work after launch, or a clean handover with documentation if you would rather take it in-house. Both are normal.
Tell us the scope and we will send a fixed price and a date within two working days. If it is smaller than you feared, we will say so.
NOT READY TO BOOK A CALL?
Get the 19-page admin handover guide we wrote for this build
Every project we deliver ships with a written manual its owner can actually run the platform from. This is the real one from The Raising Club — every admin screen, field and option explained for someone with no technical background. It is the best evidence of how we hand work over.
Managing users, roles and account deactivation
Building, pricing and publishing courses and events
Editing the plan catalogue and switching Stripe between test and live
The verification queue, red flags and what to do about them
FAQ
Questions people ask about this build
How was a platform this size built this fast?
By making the data model and the permission system the first deliverable rather than the last, and by keeping the stack narrow — one database, one deployment target, one payment path, no separate API tier. We also build AI-native: Claude is in the loop for migration drafting, test scaffolding and refactors, which compresses the mechanical work and leaves the time for architecture. The build covers 208 commits shipped continuously to production, not a prototype.
Is the platform actually live?
Yes. The Raising Club runs in production at theraisingclub.com with real caregivers, families and organisations. The screenshots on this page come from the live product and from the admin console built alongside it.
Who owns the code?
The client. Application code, SQL migrations and operational scripts live in a repository they own, along with the two written handover manuals. There is no proprietary runtime, no licensed component, and nothing stopping another team picking it up.
Could we start with one module instead of five?
Usually you should. The Raising Club needed all five because the modules reinforce each other commercially — training produces the credentials the marketplace sells on. If your modules do not depend on each other like that, we would rather ship one properly and add the next when it earns its place.
What happens after launch?
Whatever you need. The Raising Club continued past the first release into the native mobile app and ongoing feature work. Equally, everything is documented and handed over so a client can take it in-house — that is the point of writing the manuals.
Do you work in industries other than childcare?
Yes. We build enterprise software, AI automation and agentic systems, and rapid MVPs across healthcare, education and finance. The pattern on this page — one schema, database-enforced permissions, an admin console the owner can run — is how we build regardless of sector.
Want one of these
We build this as a service
What you have just read is a community platform. If that is the shape of what you need — or the training side of it on its own — both have a page of their own.
SigmaticAI is led by Ketan Khamgaonkar — an IIT Roorkee M.Tech who went on to PhD research at IIT Bombay before spending four years building AI automation, agentic systems and full web and mobile products. On every project you talk to the person writing the code.
No pitch deck. Tell us what you are trying to ship and we will tell you the fastest honest path to live — including if that path is smaller than you thought.