Exprty

The problem

Getting a senior engineer’s attention is disproportionately hard. If you need a few hours of genuinely experienced help, every available route is badly sized for the job: hiring is a months-long commitment, consultancies are priced for projects rather than questions, and free community channels are a lottery in both quality and timing.

On the other side, experienced developers have knowledge they could sell but no practical way to sell it in hour-sized pieces. Setting that up alone means solving scheduling, payments, tax invoicing and payouts before earning anything.

Exprty makes that transaction small enough to be worth doing. A learner describes what they are stuck on, finds an expert, and books a single paid session. An expert publishes their availability and rate, and gets paid without running their own billing operation.

What we built

Exprty is a two-sided marketplace, which in practice means two products that have to stay in balance, plus the machinery that settles money between them.

For experts

• Profile, skills, hourly rate and bio, with admin approval before going live
• Recurring weekly availability, managed in their own timezone
• Bookings, session history and earnings in one dashboard
• Bank and PAN onboarding to a payment linked account, which gates bookability
• Automatic invoices, generated as PDFs
• Post-session recaps and action items, generated for them

For learners

• Conversational discovery that turns a vague problem into a shortlist
• Semantic search that ranks experts by meaning rather than keyword overlap
• A short rationale on each result explaining why that expert fits
• A structured session brief built from free text, sent to the expert ahead of the call
• Booking and payment in one flow, with instant or enquiry-based options
• In-app messaging, voice calls and video sessions
• Session history, invoices and feedback

Running the platform

• Admin tooling for approvals, bans, refunds and account deletion
• Transactional email, SMS one-time passcodes and push-style notifications
• Scheduled jobs for session reminders, payment reminders, post-session nudges, expiring unpaid bookings and sweeping orphaned payments
• Error monitoring and structured retry around every database call

Engineering challenges

Moving money without ever holding it

Exprty splits every payment at the moment of capture. Each expert onboards to their own linked account with their bank details, and every booking attaches a transfer to that account with a hold until shortly after the session. The expert’s share goes directly to them and releases automatically. The platform never takes custody of it at any point.

That design is deliberate, and the reason is regulatory as much as technical. The moment a marketplace holds the seller’s share between the sale and the payout, it is a custodian of other people’s money, which is precisely what payment aggregator rules exist to govern. Splitting at capture removes the question entirely rather than answering it.

Building it that way puts the difficulty in three places:

• Bookability is gated on payout readiness. An expert who has not finished bank onboarding cannot be booked at all. The rule is enforced in three independent places, including the query that builds the learner-facing listing, because a booking that cannot be paid out is worse than no booking.
• Refunds run in reverse. The transfer to the expert is unwound before the learner is refunded, never after, so the two can never both be outstanding.
• Reconciliation is automatic. Scheduled jobs expire unpaid bookings, resume interrupted payments and sweep orphaned ones, so a dropped webhook or an abandoned checkout never leaves a booking and a payment disagreeing about what happened.

Getting timezones right, not approximately right

Availability is published by experts in their own timezone and consumed by learners in another. Every time is stored and compared in UTC and displayed in local time, which is the standard advice and not the hard part.

The hard part is that the single most common way to derive a calendar date in JavaScript is silently wrong. Taking an ISO string and slicing the first ten characters converts to UTC first, so for any timezone ahead of UTC it returns the previous day for a large part of every evening. The same trap sits in parsing: a bare date string is read as UTC, not local.

Both patterns are banned in this codebase and replaced by a small set of shared helpers that build and parse dates from local components. It is an unglamorous constraint, and it is the difference between a booking calendar that works and one that drops a day for half its users after 5:30pm.

Meeting the user wherever they already are

Rather than commit to one video provider, sessions can run on Zoom, Google Meet or Jitsi. Experts connect their own account through OAuth, and the platform creates and tears down the meeting for each booking.

That means three separate integrations, three token refresh paths, and a per-provider permissions policy so the browser will grant camera and microphone to the right embedded origins. Jitsi carries the case where an expert has connected nothing at all, so a session can always go ahead. Voice calls run natively in the app on a separate telephony stack, for the cases where a full video call is more ceremony than the question deserves.

An AI layer that is allowed to fail

Exprty uses AI in four places: conversational discovery, semantic expert matching, short explanations of why a given expert fits, and structured session briefs and recaps. Matching runs on vector similarity over embedded expert profiles; the generative features run on a hosted model from an edge function.

The design rule is that no AI feature is ever on the critical path. Every one of them has a defined non-AI fallback: discovery falls back to searching on the last thing the user typed, matching falls back to keyword search, explanations render as nothing at all rather than blocking the results, and a brief falls back to the learner’s plain notes. Recaps are generated once and persisted on the booking, so repeat views cost nothing and produce the same answer.

A learner who arrives while the model is rate-limited still finds an expert and still books a session. They just do it with a slightly less clever search.