Building trust into a local marketplace.
LekkerKids helps families compare children's programs while giving local studios a practical way to maintain information and respond to demand. I designed and built the product end to end: product model, UX, application, data workflows, permissions and operational tooling.
One product, two sides
A maintained decision system
Parent side
Find a class that fits
Age, area, schedule, pricing, trials and current availability.
Studio side
Keep the promise current
Claim, edit, publish, respond and confirm the next term.
Shared source of truth
Core constraint
Useful before network effects
3
permissioned user roles
17
server endpoints
20
database migrations
60
automated tests
The product problem
Fragmented information is not only a search problem.
Parents need comparable details. Providers need a low-friction way to correct and maintain them. The product has to earn trust from both sides before either side creates strong network effects.
Families
Decision-first discovery
Parents search at the program level, then narrow by age, location, schedule, price, language and trial availability. Near-matches are explained instead of silently mixed into results.
Class providers
A working operator portal
Studios can review imported information, manage programs and terms, publish a listing, receive inquiries, decide trial requests and keep time-sensitive details current.
Operations
Trust is a workflow
The admin path records who was invited, which address received access, whether the capability expired or was revoked, and how a studio moved through the claim funnel.
System architecture
Simple where it can be, transactional where it must be.
The architecture follows the product's consistency boundaries instead of forcing every kind of information into the same storage and delivery pattern.
Demand
Families
Browse first; authenticate when an action affects another party.
Supply
Studios
Private, role-aware workspace for listing and lead operations.
Experience
Next.js App Router
Server rendering, static generation and responsive React interfaces.
Boundary
API routes
Validation and role checks.
Session
Auth proxy
Cookie refresh and route gates.
Transactional core
Supabase / Postgres
Relational marketplace data, Auth, RLS and atomic claim operations.
Delivery
Vercel
Web and serverless runtime.
Signals
Email + analytics
Resend and Umami.
Build-time content lane
Product engineering decisions
The difficult work lives between the screens.
These decisions shaped the data model, interaction design and operational cost of the product.
Make the program the decision unit
Parents choose a specific class, not a provider logo.
The discovery model flattens studios into program rows. Studio identity remains as trust context, while age fit, active terms, schedule and price decide whether a class belongs in the result set.
Split content from transactions
A map directory and a marketplace have different consistency needs.
Public place and event data can be curated as build-time JSON. Mutable marketplace data lives in Postgres: studios, programs, offerings, prices, conversations, trials, notifications and audit records.
Personalize before asking for an account
Early sign-in gates make a new marketplace feel empty and expensive to try.
A child age and location preference can live locally in the browser. Authentication begins only when a parent saves across devices, sends an inquiry or requests a trial.
Measure decisions, not surveillance
The product needs funnel evidence without leaking family or message data.
Typed analytics events record intent and outcomes: discovery setup, contact intent, lead success, registration handoff and studio activation milestones.
Security deep dive
A claim link is a capability, not a convenience URL.
A provider claim can change public information and receive family leads. The invitation flow therefore binds access to one studio, one recipient and one active server-side record.
- 1
Issue
Admin verifies the target and recipient before creating an auditable invitation.
- 2
Deliver
Resend sends the private capability; provider response is recorded separately.
- 3
Resolve
The server verifies signature, hash, expiry, recipient, revocation and claim state.
- 4
Authenticate
Supabase proves control of the invited mailbox before provisioning staff.
- 5
Consume
A database function uses the capability once and revokes competing invitations.
- 6
Operate
The new staff member reviews data before choosing whether to publish the listing.
AI-assisted development
Speed is useful only when ownership stays human.
AI supports research, extraction, implementation and review. It does not decide what is safe to publish or what the product should promise.
AI accelerates
- Source extraction and normalization
- Implementation drafts and repetitive changes
- Test-case exploration and code review prompts
- Research synthesis and documentation
I remain accountable for
- Problem framing and product boundaries
- Data model, permissions and failure behaviour
- Source verification and public claims
- Testing, debugging and production trade-offs
Current engineering stack
Application
Next.js App Router, React, TypeScript
Data and identity
Supabase Postgres, Auth and row-level security
Delivery
Vercel serverless and static generation
Communication
Resend email plus in-product notifications
Media and maps
Vercel Blob, Leaflet and OpenStreetMap
Quality signals
Vitest, TypeScript, ESLint and Umami
Quality and operations
Production means planning for the unhappy path.
The repository includes more than the public screens: data validation, anti-abuse limits, account deletion, role guards, audit records and operating notes for staged rollout.
Validation
Programs cannot publish without the age, description, timing and price context families need.
Abuse controls
Honeypots, link limits, duplicate prevention and database-backed rate checks protect studio inboxes.
Privacy
Account deletion redacts parent messages, cancels active trials and preserves referential integrity.
Verification
The current production build compiles with strict TypeScript and all 60 automated tests passing.
Honest reflection
What I would strengthen next.
The system is intentionally right-sized for validation, not presented as a finished large-scale platform. The next investments should follow observed demand rather than speculative architecture.
Operational reliability
Add scheduled trial lifecycle transitions, stronger background-job handling and production error monitoring.
Test depth
Extend integration and end-to-end coverage around authentication, RLS boundaries and the full two-sided lead lifecycle.
Data freshness
Formalize re-check schedules and make source, import and provider-confirmed timestamps distinct.
Evidence of value
Use pilot studio activation, parent demand and fulfilled-lead data to decide which marketplace workflows deserve more complexity.
I build across the boundary between product judgement and production code.
LekkerKids is the evidence: a deployed product with real data, constraints, operational work and decisions that cannot be reduced to generating a screen.