attacked by this build reduced, not solved deliberately deferred
02 Objectives, from those causes
O1
A stuck student reaches the right expert without knowing who to ask.
cannot name · does not know who · manual routing
O2
Asking is cheap enough that a half-formed question still gets asked.
social cost of admitting you are stuck
O3
Expert supply survives the demand this creates.
capacity is invisible
O4
It ships inside the live platform without disturbing it.
features arriving as separate products
O3 is the one this build makes worse. It lowers the cost of asking and does
nothing about the cost of answering, which is how expert networks fail. It reads live on the dashboard.
03 Built, and cut
Built in the hour
Plain-language ask
Tag read-back
Ranked experts, with reasons
Request carrying the student’s words
Expert desk, accept or decline
Evidence recorded at every step
Cut on purpose
Scheduling and availabilitythe biggest thing that would fit, and the least revealing
Messaging threadsone clear handover matters more than a chat feature
Authenticationbelongs to the platform, not to this feature
Self-authored profilesmatching was the risky part, so the time went there
Tags as a join tablewrong at scale, correct for a sixty-minute build
04 A module, not an app
In the real role, features are built inside a platform that is already live. So this is shaped
as one. module.ts declares the entire contract with the host: what it requires,
what it owns, what it emits, and that it is removable.
The module owns three tables and two routes. It requires identity and the user and project
entities from the host and modifies neither, which is what makes it removable in one deploy.
Matching sits behind a seam because it is the part most likely to be replaced.
05 Scaling is capacity, not traffic
SPH is thousands of students, not millions. D1 and edge rendering are already oversized for
that. The binding constraint is expert attention.
1
Now
Tags as text, lexical matching, no capacity model.
Correct while the open question is whether students use the front door at all.
2
~50 experts
Join table, embeddings behind the same interface.
Triggered by students routinely choosing rank two or three.
3
Sustained volume
Capacity model and load-aware ranking.
Triggered by decline rate or time-to-first-response rising.
4
Ongoing
Useful answers per expert per month.
Not requests sent. That number only measures the easy half.
Every stage is reversible and every migration additive, which is what makes committing to the
small version now defensible rather than lazy.
06 What would prove me wrong
Five assumptions, each with a test that could disprove it and a live signal, on the evidence register. The one I cannot observe is the only one that
finally matters: whether the student got an answer that helped. I would rather state that gap
clearly than add a metric that does not actually test it.