NELLA Labs product
Building verification into the centre of a learning marketplace
A tutoring marketplace where an educator profile is invisible to families until identity and credentials have been checked, and where sessions accumulate into curriculum-level progress rather than billable hours.
- Client
- Trellis — a NELLA Labs product
- Status
- In private beta
- Year
- 2026
- Sector
- Education and workforce development
This is a NELLA Labs product or platform, not an external commission. Nothing here implies a client engagement.
Context
Trellis is a NELLA Labs product, not a client commission. It exists because private tutoring across the UK and Ghana is a market conducted almost entirely on unverified trust, with no shared record of what a learner has covered.
Challenge and constraints
- Verification is expensive and slow, and every day an educator waits is a day they are earning elsewhere. Making verification a precondition of visibility risks starving the supply side.
- Safeguarding requirements differ between the UK and Ghana, and a single hard-coded process would be wrong in at least one market.
- Learners in Ghana frequently access the platform on older Android devices over metered mobile data, which rules out a heavy client application.
- Progress is only meaningful if it maps to a curriculum, and curricula differ per market.
Discovery
What we found, and what it changed
Research is only worth doing if it changes a decision. Each finding below is paired with the design or architecture change it caused.
Finding
Families overwhelmingly selected on perceived safety before price or subject expertise, but existing platforms surfaced verification — where it existed at all — several clicks into a profile.
What changed
Verification status was promoted to the primary result attribute in discovery, shown at the same visual weight as the educator’s name.
Finding
Educators abandoned onboarding at the document-upload step when they were not told what would be checked or how long it would take.
What changed
Onboarding was restructured to state the full check sequence, its purpose and an expected duration before any document is requested.
Finding
Session notes written as free text were unusable for progress reporting — they described what happened, not what was covered.
What changed
Curriculum objectives became first-class entities, and session completion records coverage against them rather than a narrative.
Finding
On a mid-range Android device over a 3G connection, an image-heavy discovery page took long enough that users assumed it had failed.
What changed
A performance budget was set for the discovery route and enforced in CI, with images served responsively and the critical path rendered server-side.
Solution
What we built
- Verification modelled as a sequence of steps with per-market configuration, so the UK and Ghanaian processes differ in data sources without differing in domain model.
- Verification state stored with its evidence, its assessor and an expiry, and re-checked on a schedule rather than captured once at sign-up.
- A curriculum model where objectives are entities that sessions attach to, making progress reporting a query rather than a summarisation task.
- In-platform communication retained per booking, giving safeguarding a record rather than a policy.
- Held funds released on session completion, so the cancellation position is applied by the system rather than negotiated per case.
Journeys
How people move through it
Educator: application to visible profile
Application, identity verification, credential assessment, then publication — with the profile hidden from families throughout, and the reason for any delay visible to the educator.
Guardian: search to recorded progress
Search with verification status shown in results, an introductory session with funds held, objectives agreed against a curriculum, and progress visible at objective level.
Learner: session to evidence
See what a session will cover, join it, complete the attached practice, and see which objectives are covered, in progress or untouched.
Architecture
Decisions and the reasoning
These are the choices that would have been expensive to reverse. Each one is recorded as an architecture decision record in the project.
Postgres row-level security as the isolation boundary, not application middleware.
A learning platform holds children’s data. A missed authorisation check in application code should not be able to become a data breach, so entitlement is enforced where the data lives.
Verification providers behind a per-market interface.
UK and Ghanaian identity and background-check sources have nothing in common. Isolating them behind one interface meant adding a market became configuration rather than a rewrite.
Server-rendered discovery with aggressive caching; only booking and payment are dynamic.
Discovery is the highest-traffic, most performance-sensitive route and its content changes slowly. Making it cacheable was the single largest contributor to usability on constrained connections.
Curriculum objectives as entities rather than tags.
Progress reporting, pathway construction and AI-assisted course drafting all need the same structured target. Modelling objectives properly once made all three tractable.
Security, accessibility and quality
- Isolation testing
- Positive and negative access tests for every role across API, search, storage paths and realtime channels.
- Accessibility
- Designed to WCAG 2.2 AA with manual keyboard and screen-reader review on the discovery and booking journeys.
- Performance
- Budgets set for the discovery route and enforced in CI, tested against throttled mobile profiles.
- Safeguarding
- Communication retention, reporting routes from every session, and review gating on any change affecting adult–learner contact.
Timeline
- Shape4 weeksMarket research across the UK and Ghana, safeguarding review, verification provider assessment.
- Design6 weeksDiscovery and booking journeys, verification onboarding, design system, low-bandwidth testing.
- BuildOngoingTwo-week increments; verification, discovery, scheduling and payments delivered first.
- ValidateContinuousIsolation, accessibility and performance testing in every increment.
Team shape
- Product lead
- Service designer
- Two full-stack engineers
- Platform engineer
- QA and accessibility specialist
Technologies
- Next.js
- TypeScript
- Postgres
- Supabase
- Row-level security
- Vercel
Outcomes
What we can actually substantiate
Each statement is marked either verified — meaning it is demonstrable in the system — or design intent, meaning it is what the design sets out to achieve and has not yet been measured in production.
- Design intentVerification status is the primary attribute in discovery results, by design.
- VerifiedTenancy and role isolation is enforced in the database and covered by automated positive and negative tests.
- VerifiedProgress is reported at curriculum-objective level rather than as session hours.
- VerifiedA performance budget for the discovery route is enforced in continuous integration.
Next stage
What comes next
- Progress reporting for institutions, subject to guardian permission
- AI-assisted course construction with educator approval required before publication
- Ghanaian curriculum coverage and local payment methods
- Native mobile applications
Related
Keep reading
Work
Treating identity verification as orchestration rather than integration
Verification modelled as a configurable, resumable sequence of steps with an append-only evidence trail, so adding a market or replacing a provider is a configuration change rather than an engineering programme.
Work
Modelling the tenancy, not the transaction
A property platform built around the tenancy as the central record, so applications, agreements, payments, maintenance and communications form one continuous, attributable history.
Next step
Have a problem shaped like this one?
Start with the Project Architect and you will get the same structure — problem, constraints, architecture direction, delivery path — for your own situation.