Senpai Collective

The problem

A talented African designer or engineer has no credible way to prove what they have done. A portfolio is a claim. A referral is a favour. Neither survives a client who needs to know whether this person can be trusted with real work, so the global market resolves that uncertainty the cheap way: it prices the country instead of the person.

We know the size of that gap because we spent four years on the wrong side of it, and because the founder kept hitting the same wall from the other direction. Founders would ask him for a designer, a frontend developer, someone who could actually ship. He could answer for about twenty people, the ones he had personally watched deliver. For the several hundred others in a community of two thousand, the honest answer was silence.

On any given day there was no way to know who was genuinely good at JavaScript. The talent existed. The index did not.

That sentence is the whole product. Everything below is implementation, and the nine years of evidence that produced the spec.

How it started

Lagos, 2016. The founder was in college, watching the same thing happen over and over: people with real creative ability, designers and photographers and writers and developers, who had no idea how to turn that ability into a career. The tech industry was growing. The opportunities existed. Nothing connected the two.

It was named SENPAI after the Japanese word for an experienced guide who leads by example instead of by instruction. That choice was the first design decision, and it ruled out the obvious model. Not a school. Not a bootcamp. A community of people a few steps ahead, pulling others forward.

The brand was designed in-house. The community was built manually, one conversation at a time. Events ran out of the founder’s own pocket, and the money that funded them came from design services sold under the same name. That was the operating model from the start: a social enterprise, where client revenue paid for scholarships and programmes. It proved profit and purpose could run on one balance sheet. It also, eventually, proved the ratio was wrong.

Who we were building for

Before designing any programme we had to know who was actually turning up. Three types emerged from the early events and conversations, and they wanted genuinely different things.

Type	What they had	What they were missing
The Aspiring Creative	Interest and raw talent	Any idea what a career in this looks like, or where to start
The Skill Builder	Real, usable skills	The professional context, vocabulary and network to convert them
The Connector	Social energy and relationships	A reason to convert connection into output

The decision: build the programme for the Skill Builder. Not because the other two mattered less, but because the Skill Builder was the only one whose outcome we could measure. Employment, projects, earnings. If the curriculum worked for them it would pull the other two forward anyway, and we would be able to prove it worked instead of asserting it.

That decision is the reason there are hard numbers in this case study at all.

What people did instead

The alternatives were not nothing. They were each missing a different thing.

Option	What it gave	What it did not
Bootcamps	Structure and intensity	Affordability. Out of reach for most Lagos creatives
YouTube and self-study	Skills, in unlimited supply	Context, feedback, accountability, anyone to answer to
Twitter and Facebook groups	Volume and reach	Signal, programmes, outcomes
University design programmes	Theory and a certificate	Industry connection, practitioners
Informal mentorship	The single highest quality option	Scale, and equity. It depends entirely on who you already know

Nobody was combining curriculum, mentorship, community, real projects and career outcomes in a form somebody earning Lagos wages could pay for. That was the gap, and it is worth being precise about it: the shortage was never teaching material. It was structure with somebody accountable inside it.

What we built then, and what it produced

From 2017 to 2021 the community grew past 2,000 members, with a newsletter reaching over 3,000. Four cohorts ran across five tracks: product design, frontend, backend and cloud engineering, project management, and mobile development. Graduates worked on real builds instead of exercises, so they left with a portfolio instead of a certificate.

Around it ran three things that were not the course. Senpai Academy held the cohort programmes. A writers programme published members’ own learning on a Medium publication, which developed their communication and left a proof-of-learning record an employer could read. And Co Ops distributed responsibility to the ten most committed members, split into Collective Talents who were contracted out to client projects, Collective Freelancers available for their own work, and Collective Founders building businesses with community support behind them.

Hold that last one in mind. Co Ops is the direct ancestor of everything the platform now does, and it was built in a WhatsApp group.

The flagship was Design 101, a six week course at ₦4,999, and it is the part of the programme we have the hardest numbers for.

Measure	Figure
Enrolled, Design 101	157
WhatsApp sub-groups	13
Mentors	6
Graduated	45, a 29% completion rate
Now earning in dollars or at top firms	~35, or 78% of graduates
Total course revenue, four cohorts	~₦1,000,000
Newsletter subscribers at peak	3,000+
In-person events	Multiple, including Social Media Week Lagos

Read that table twice. 78% of everyone who finished went on to earn in dollars, with no job board, no employer relationships and no placement programme. They went and did it themselves on the foundation the course gave them. Most of them out-earn the founder today.

That is not a failure story. It is a story about a machine that produced real outcomes and captured none of the value, which is a different and more useful problem to have solved for you in advance.

The curriculum, and why it was ordered that way

Six weeks, and the order is the argument.

Week	Topic	What a student left with
1	Introduction to design, Figma, Maslow’s hierarchy	A reason design exists, before any tool
2	Visual hierarchy	How the eye moves, and how to control it
3	Layout and composition	Structure, spacing, organising information
4	Typography	Type as a design tool, not a text setting
5	Colour theory	Colour as communication, not decoration
6	The design process	Problem to solution to iteration, end to end

Most design courses open on the tool. Design 101 opened on Maslow: the argument that design exists to serve human needs before it exists to look good. Students who arrived believing design was shapes and colours left with a way of framing problems, and the tools arrived later in a context that made them mean something.

Two more mechanisms did the actual work.

Small groups with a mentor a few steps ahead. Thirteen groups of no more than fifteen, each with someone who had recently been through the material. Deliberately not senior industry figures: relatable, and fast to answer. Nobody was ever in a room of 157 people.

Weekly assignments that required producing something. Not reading, not watching. Week one: find two well designed sites and two bad ones, and explain why. Week two: apply three Gestalt principles and show your work. Passive absorption was structurally impossible.

The students said it better than we could.

“I realized I knew nothing. Compared to what I was doing, I was just putting together things that looked aesthetically nice. Glad I took the course because I’m a much better designer.”
Agboluaje Quadri

“Design 101 was my first official introduction to design education. It basically set me on a path to seek more knowledge and see design as a way of life.”
Imasuen Osamudiamen

“I realize how much I missed learning with people.”
Aliyu Sofiya

That last one is the whole thesis in eight words, and it was written by a student, unprompted, on a public blog. The most credible marketing the programme ever had was the marketing we did not write.

What broke

The first community model failed in weeks

Before any of the above, there was a Slack group. It was opened to everyone and it got past 300 signups quickly, which felt exactly like traction. Then engagement collapsed. Ghost accounts, empty channels, no culture, nothing to belong to.

A community of 300 people who do not know each other is not a community. It is a list.

We abandoned it and restarted deliberately: identify the most committed people, build real relationships one at a time, and let them pull others in. That lesson is now a rule the platform enforces, and it is why the founding cohort of the Collective is capped at about twenty people who were invited personally. You cannot skip the manual phase. You can only decide whether to do it on purpose.

Placement was real, and accidental

The most important outcome happened without any system anyone controlled. So it could not be measured, could not be improved, and could not be promised to the next cohort.

Worse: having trained people, we discovered that persuading businesses to hire from a talent pool is a completely different skill from teaching. The people we had promised the most to left, one at a time, for opportunities we could not match. Andela hit the same wall with a hundred times the funding.

Placement is the product. Training is the process. We had built the process and called it the product.

There was no bird’s eye view

You could message any individual. You could not see the community: who was active, who had gone quiet, who was ready to be pushed further.

Founder memory has properties that disqualify it as infrastructure. It holds about twenty people. It decays. It skews toward whoever you worked with most recently. And it disappears entirely the moment the founder is unavailable. At a hundred members you can run on it. At two thousand what replaces management is triage, and triage means whoever is loudest gets the attention.

Opportunities had nowhere to land

Someone would ask for a designer. Finding the right member meant messaging people one at a time to discover this one had a full-time job and that one was not taking clients. Availability and skill lived in individual WhatsApp threads and nowhere else, so the single strongest promise of membership, that being here opens doors, ran at the speed of one person’s thumbs.

Rules lived in one person’s head

Values existed. Culture existed. None of it was written down or enforced structurally. When community rules live only in the founder’s head they can only be enforced by the founder’s direct intervention, which does not scale and which makes the whole thing fragile on any day he is tired.

₦4,999 could not fund the operation

The price was set deliberately low to remove the barrier, which was the right call for access and a slow bleed on everything else. A six week programme with mentors, weekly feedback and real project supervision does not run on five thousand naira a head. Service revenue was meant to cover the difference. It helped, and it was not enough.

And the founder was the bottleneck, in two different ways

Operationally, everything ran on one person’s energy, and energy is not infrastructure.

Personally, something less obvious. SENPAI was built straight out of college by someone with no prior work experience, learning in real time while being responsible for two thousand people. The brand grew faster than the person behind it, and at some point it became clear that SENPAI had a face, and it was not his. Everyone knew SENPAI. Nobody knew Henry Ikoh. The brand was simultaneously bigger than him and entirely dependent on him, which is an unsurvivable position for both parties.

Stepping away was not only burnout. It was recognising that the ceiling on the brand was the founder’s own ceiling, and that the fix was to go and raise it.

There is a part of this nobody warns you about. Watching students from your first cohort earn in dollars and work at firms you have not worked at, while you are still figuring it out, is proud and it stings, at the same time, and both are true. That tension is a fair part of why the second attempt exists at all.

The bridge: what we would change

Written before a line of the platform was committed. Everything in the right column became a schema decision.

	2017	2026
Community launch	Open Slack, anyone	Closed application, manual intake of the first 20 to 30
First cohort size	157 students, 13 groups	30 to 50, to protect completion and culture
Pricing	₦4,999 flat	Free for the founding cohort. Monetise outcomes, never entry
Placement	Organic and informal	Employer relationships and a job board that exists before the cohort does
Visibility	WhatsApp and Instagram DMs	Every member on a platform with a profile, skills and availability
Opportunity matching	Manual DMs and hope	A searchable directory answering “who is good at X” in seconds
Rules	Informal, founder-enforced	Published documents, accepted server-side, enforced by permissions
Management	Solo, ad hoc	Roles and circles with recorded seats, from day one
Success	“People are enrolling”	Numeric targets with failure lines, published before the cohort starts

Why we built what we built

Each failure above is a line in the schema. That mapping is the entire design brief, and nothing was added to the platform that does not answer one of them.

What broke	What answers it
No bird’s eye view	A searchable member directory, an append-only activities log, and an idleness detector over it
Opportunities unroutable	member_skills carrying verification state, plus job_postings and applications
Rules in a head	Published Terms, Guidelines and Pool Policy, accepted server-side and enforced by role permissions
Placement accidental	The review and verification system
Value leaked out	A take rate on real work, and the Collective Pool, instead of course fees
Training did not fund itself	Training is not the product. Reviewed work is
A list, not a community	Application, vetting, cohorts, pods, and a hard cap on the first intake
Co Ops lived in WhatsApp	Circles as first-class objects with seats, charters and cadence

There is one governing constraint over all of it, and it is the thing most likely to be got wrong later:

When verification feels slow, the temptation is to lower the thresholds. Do not. The difficulty is the product.

A verification that is easy to obtain is worth nothing to the person hiring. Hard to obtain is the entire asset. Every mechanism in this build adds reviewed work, raters, or captured evidence. None of them touch the standard.

The architecture

A Go and Postgres API, layered cmd/ into pkg/{server,app,repository,models,database,services}: handlers, then business logic, then repository interfaces over sqlx. Migrations are go:embed-ed and run in order on boot, so a deploy and a schema change are one event and there is no separate migration step to forget. Vue 3, TypeScript, Tailwind and Pinia on the front, served from Cloudflare Workers. Identity through self-hosted Zitadel, driven headless so the auth surface stays ours and the login page is not somebody else’s brand. systemd on Hetzner behind Caddy, and a push to main deploys over SSH.

45   tables across ten domains
170  API routes
26   migrations, 001 to 026
57   pages across 59 routes, guarded at five permission levels

The ten domains: identity, skills, scouts, job board, client and internal reviews, the engine, work, programmes and projects, verification, circles.

The five guard levels are worth naming, because permissions are where a community platform usually rots: public, authenticated, approved, community-lead, admin, plus a scout role that cuts across. A pending applicant holds an account and can reach almost nothing. requiresApproved is what separates a person who applied from a member, and it is checked in the router and again on every route on the server.

From registration to paid work

This is the flow the platform exists to run, end to end. Every arrow below is a state change the database records.

APPLY ──► DECISION ──► COHORT ──► INDUCTION ──► POD ──► WORK
                                                          │
                        ┌─────────────────────────────────┤
                        │                                 │
                   TASKS + PROGRAMMES              PROJECTS (teams)
                        │                                 │
                        └────────► REVIEW ◄───────────────┘
                                     │
                                 SKILL SCORES
                                     │
                        claimed ► nominated ► verified
                                     │
                              VERIFIED BENCH
                                     │
                        ┌────────────┴────────────┐
                   JOB BOARD                CLIENT ENGAGEMENT
                   (member applies)         (Senpai signs, staffs, delivers)
                        │                            │
                        └────────► CLIENT REVIEW ◄───┘
                                     │
                              back into the record

1. Apply. A six-step application. Applying creates an account and deliberately not a membership: the Terms are explicit that membership does not exist until we accept, and pending users are walled at /pending until they are. On submission the applicant accepts the Terms of Membership, the Privacy Policy and the Community Guidelines, and that acceptance is recorded as an activity, not a checkbox that disappears.

2. Decision. Approve or decline, with a decline reason stored. Approval assigns the member to the current cohort and generates their Senpai ID, firstname@senpaicollective.com, held back for the reveal at induction.

3. Induction. Induction is not a welcome email, it is the first programme: an ordered series of tasks with unlock scheduling and a real completion state. Finish its required tasks and the system itself flips the member to inducted. Matriculation becomes something the platform knows instead of something an admin eyeballs, and every later programme reuses the same object. The content is deliberately not technical. It is the mindset and culture track, which is the part that made the old course stick, now run peer-to-peer with no mentor.

4. Pod. Auto-formed per cohort, ten to sixteen people, mixed by discipline so every pod has builders and writers and designers, and clustered by timezone so synchronous contact is possible. A rotating host handles logistics. Pods have no mentor.

5. Work. Two primitives, deliberately kept separate. Tasks are the unit of individual accountability: a task is a definition, and task_assignments is one person’s copy of it with its own status and hand-in. That split is why a single task fans out to a person, a pod, a cohort or everyone without duplicating anything, and it is what makes an open task board possible, where members claim work instead of waiting to be given it. Projects are member-proposed and founder-approved, open-join with a team cap of two to five, scoped globally so the best team assembles across pods and cohorts, and they end in shipped with an outcome link or parked.

6. Review. Every completed unit of work has a named reviewer, decided when the work is created. Review produces per-skill scores, and those scores are the only thing that moves a member’s record.

7. The bench. Verified skills roll up into verified job roles, and the directory becomes queryable by them.

8. Paid work. Two routes out. A client posts on the public job board at /submit-job, it passes through pending_approval before it is visible to members, and moves active → assigned → in_progress → completed. Or Senpai signs the client directly and staffs the engagement from the bench.

9. Client review. On completion the client receives a tokenised link at /review/:token, with no account required, and their review is admin-verified before it counts. A client’s judgment is the highest quality signal in the system, and it is the one signal we cannot generate ourselves.

The loop closes: paid work produces a client review, which feeds the record, which is what got the member the work.

The bird’s eye view

The founder’s stated failure was that he could not see his own community. So seeing it is a first-class feature, not an admin afterthought, and it is several surfaces working together.

The member directory at /members is the direct answer to “who is good at X”. It is open to every approved member, always, not only to admins: free-text search across name and bio, filtered by skill and by experience level, with a 300ms debounce and server-side pagination, and it renders verification state on the result. That is the thing that did not exist in 2017, in the most literal possible sense. A member can now answer the founder’s old question themselves, in about four seconds, without asking him.

Public profiles at /m/:id are the outward face of the same record: identity, cohort, roles, contributions, writing, portfolio, verified skills. A member’s proof is a URL they own and can send to anyone. The writers programme was the 2017 version of this, built by hand on Medium. This is the same idea with the evidence attached to the person.

The activity log is one append-only table with a free-text verb column, so a new kind of event needs no migration. Around thirty verbs are seeded, from applied and approved through task_claimed, peer_reviewed, published and became_scout.

The idleness detector runs over that log, and its single most important design decision is a subtraction. Some verbs record things done to a member: being assigned a task, being reviewed, being approved, being scouted. Those are excluded from the query.

SELECT m.id FROM members m
WHERE m.status = 'approved'
AND NOT EXISTS (
    SELECT 1 FROM activities a
    WHERE a.member_id = m.id
      AND a.created_at > ?
      AND a.verb NOT IN (?)   -- RecipientVerbs
)

Without that exclusion, a member who is assigned a task every week and does nothing with it never registers as idle. The metric would have been wrong in exactly the direction that flatters us, which is the direction bad metrics always fail in. “No spectators” is a nice line in a manifesto. This query is what makes it enforceable.

Admin analytics and the member performance page put the same data in front of the two people who need it: the operator, and the member themselves. A member can see their own progress toward each unverified skill, so verification is a distance they can measure instead of an opaque event that happens to them.

Skill verification

This is the heart of the build, and the part that would be hardest for anyone else to copy, because it cannot be shortcut with software. It has to be run for years.

The unit of reputation is the skill, not the job title

A job role is an admin-curated recipe of skills, each marked required or bonus. A member holds that role only by being independently verified in every skill it requires. It is a computed rollup, never a credential anybody granted.

Systems Architect  =  Systems Thinking     (required)
                   +  Backend Engineering  (required)
                   +  UI/UX                (required)
                   +  Infrastructure       (bonus)

verified(role) = every required skill is independently verified

The reason for that shape: job titles are the least portable thing in tech. A “senior developer” at one Lagos agency and a “senior developer” at a US startup are not comparable, and both are self-declared often enough to be worthless as signal. Skills are comparable. Roles built from skills inherit that.

Every skill moves through a state machine

Self-assessed seniority from the application form has no effect on anything at all. It is stored, because it tells us what a member believes about themselves, and it moves nothing.

claimed ──► nominated ──► verified ──► dormant
   ▲            │             │
   │            │            admin confirms
   │            │            (the vouch is the company's name)
   │       thresholds trip
   │
 self-declared, OR observed in a review
 outside the seat's recipe

That second entry into claimed matters more than it looks. If a reviewer scores someone on a skill outside the recipe they were working under, the platform opens a claim on it. People turn out to be good at things nobody hired them for, and a record that can only confirm what it already expected is a worse record.

The thresholds, and why they are constants

VerificationMinContributions = 3     // distinct reviewed pieces of work
VerificationMinAvgScore      = 4.0   // out of 5, weighted
VerificationMinRaters        = 2     // distinct raters
VerifiedRaterWeight          = 3.0   // a proven person's judgment counts more
UnverifiedRaterWeight        = 1.0

They live as named constants in pkg/models/review.go because we do not yet know the right values, and pretending otherwise would be the first lie the system tells. They are calibrated against the founding cohort’s data, and tuning them is a one-line change with a migration behind it, not an archaeology expedition through the codebase.

Weighting verified raters at 3× is the mechanism that makes the network self-reinforcing. A newcomer’s opinion counts. A proven person’s counts more. Nobody’s counts for nothing.

The gates are structural, not policy

Every constraint below exists because of a specific way this system could be gamed, and each one is enforced in the handler, not in a guideline.

Constraint	Why it exists
Only people who shared the work can review	An endorsement from someone who never worked with you is worthless
Verified raters weighted 3×	A proven person’s judgment should outweigh a newcomer’s
Off-platform work does not count	You cannot vouch for what nobody accountable reviewed
A named reviewer is required when work is created	No reviewer, no accountability, no evidence
The system nominates, an admin confirms	The vouch is the company’s name, and someone signs for it

A task review requires the rater to be that task’s named reviewer and the assignment to be complete. A project review requires the project to have shipped and both parties to have actually shared the team roster. These are checked server-side on every submission, because a rule that lives only in the interface is a suggestion.

One review carries three things at once

Per-skill scores from 1 to 5, an in_recipe flag per skill so we can tell expected competence from discovered competence, and three fixed soft dimensions present on every single review: collaboration, communication, reliability.

Those three are identical everywhere precisely so they aggregate across a member’s entire record regardless of what the review was otherwise about. Being easy to work with is a portable fact about a person, and it is usually the thing a client is really asking about when they ask something else.

Bootstrapping is a real problem with a real answer

On day one nobody is verified, so the verified-rater condition cannot be satisfied and the normal path is mathematically closed. A seed-verify override hand-verifies founding members. It is not a convenience, it is the ignition.

Which creates a measurement problem, solved in migration 026: every verification records its verification_source as reviewed or seeded. Without that column, the number that is supposed to prove the loop closes would be quietly inflated by the bootstrap that made it possible.

Verification propagates, and staffing is the lever

The binding constraint is “at least one rater already verified in that skill”. So make it true by construction:

Every project team includes at least one member already verified in the relevant skill.

Verification then spreads outward from the seeded members like a spanning tree. Each newly verified member becomes a qualified rater for the next team, and broad coverage arrives in a few project cycles without weakening the standard.

There is a second lever, and it is arithmetic. Team projects verify far faster than solo tasks. A solo task produces one review from one rater. A shipped four-person project produces up to twelve review pairs and gives every member three distinct raters at once, clearing the threshold in a single cycle that solo work would take three cycles to reach. When verification pace is the constraint, the answer is more small team projects, never a lower bar.

Task sizing is the third. Three contributions is three months if a task is a month of work and three weeks if it is a week of work. Spec small, independently reviewable units. Identical rigour, far more repetitions, and it costs nothing but discipline in how tasks are written.

The leak

The cheapest available improvement is not a feature. Any completed task with no role tag, no named reviewer or no submitted review is verification paid for in real effort and never banked. We track it as record conversion rate: of all completed work, what share produced at least one skill score. Measured at 25% in development, and five of six leaked items were simply untagged.

The rules are documents, and the documents are enforced

The 2017 community died partly of unwritten rules. So every rule a member is held to is now a published document with a URL, accepted server-side, and backed by something in code.

Document	What it governs
Terms of Membership	The governing agreement: acceptance, IP, confidentiality, non-circumvention, removal, disputes
Community Guidelines	Conduct, accepted on first login and logged as an activity
Privacy Policy	What we hold, and what members can see of each other
The Collective Pool	How contribution converts into ownership
The Manifesto	What the thing is for, in public, before anyone applies

Two of those carry real mechanism behind them.

The Pool is the answer to “why would anyone build for free”. A defined 20% of the collective enterprise, earned in units through recorded contribution, computed from the same task assignments, project seats and reviews the verification system already uses. No new tracking, because the record is already the ledger. Where a project spins out, the originating member takes a 12% founder’s allocation off the top of the founding team’s share, then competes for the remainder on recorded contribution like everyone else. The worked example in the policy is deliberate: on a four-person team the lead who did the heavy lifting still ends up ahead of the originator, 24.6% to 20.7%. Execution outranks ideas, and the arithmetic says so instead of the values page.

The paperwork boundary is the one that would sink us if we got it wrong. Three paths through the platform, and mixing them up is the main legal risk in the entire model.

Path	Document	Signed	Paid
Collective Project, our idea	Project brief and seat record	Nothing	Pool units
Member Project, their idea	Same brief, founding team recorded	Nothing	Pool units, plus equity on spinout
Client engagement	MSA, SOW, Contractor Agreement, Project Assignment	All four, in that order	Cash, less WHT

Sign them in that order, always. The client commits first, then you commit to the member. Issuing a project assignment before the SOW is signed means promising someone payment for work nobody has yet agreed to fund.

Underneath that sits the misclassification trap, which is why the bench model is contractor-shaped by design: engaged per project with defined deliverables and an end date, paid against output, controlling their own method and hours, free to work elsewhere, re-papered each engagement. Calling someone a contractor does not make them one, and a reclassification finding against a company with no cash buffer is existential.

Decisions worth defending

Pods have no mentors. The mentor groups belonged to Design 101, which was a course, and a course needs mentors. What a mentor supplied at that scale was attention, and attention is what the platform now provides across every member at once. Run a course again and its pods get mentors.

Pods never do client work. Belonging and delivery are different jobs and mixing them corrupts both. Delivery happens in project teams that assemble for one outcome and dissolve.

An account is created at application, and it is not a membership. This felt wrong for a while, and the fix was to reframe instead of re-architect: call it an application in the interface, let the password secure the application, and wall everything behind requiresApproved. Ripping out account-on-apply adds friction for almost no gain.

Circles were a free-text string, and that was a bug. A circle existed only while it had open tasks and vanished when it did not, because the filter derived the list from whatever strings happened to be on tasks. "content" and "Content" were two different circles. Migration 022 makes them real objects with seats, charters, cadence and a metric series, so a standing team has somewhere to hang its history. This is Co Ops, finally given a schema.

Metric collection is deliberately manual. The circle lead posts a monthly figure and the system stores the series. Automating capture per metric is a much larger job and it is not what makes a circle feel real.

The credential must always show its evidence. A shareable verification view says “SENPAI FUTURES LTD verifies this member as a Backend Developer, from N reviewed contributions across M shipped projects since [date]”, with the reviews underneath visible. Anyone can print a badge. The reviews are the receipt, and they are the part nobody can fake without running the same machine for the same number of years.

What is live, and what is not

Live in production: everything through the review and verification system, migrations 001 to 021 plus 026, on senpaicollective.com and api.senpaicollective.com, with continuous deployment on both.

Built, not yet shipped: circles as first-class objects with seats, charters, cadence events and metrics, migrations 022 to 025.

Designed, not built: skill levels. The state machine stops at verified and does not distinguish entry from senior. And the public credential view: the record is real, and it is not yet externally inspectable by a founder who is evaluating a developer. That gap is the difference between a working system and a system that changes anyone’s price.

Deliberately absent: any payment, invoice or payout infrastructure. budget_range is a free-text string on a job posting. The job board lists and matches, it does not transact. The take rate, the Pool’s cash mechanics and spinout equity are prose with no machinery behind them, and it would be dishonest to imply otherwise.

The first thing to build there is a ledger, not a payment processor. SENPAI FUTURES LTD is already the contracting party, so money already flows from client to Senpai to member. The platform simply does not record it. Three tables, engagements, engagement_members and payouts, would make the take rate computed instead of remembered, put lifetime earnings on a member’s own profile, and solve attribution permanently: self-reported “did this come through Senpai?” is weak evidence, and money Senpai actually paid is not.

One hard constraint on that build: record and pay out, never hold member balances. Accumulated member funds is deposit-taking, and deposit-taking is regulated.

What we are testing, and what success looks like

The founding cohort is forming. Its targets were written down before it started so the results cannot be reverse-fitted afterwards, and each one carries the point at which it counts as a failure. In 2017 success was “people are enrolling”, which is a number that can only go up and therefore proves nothing.

	Measures	Target	Failure
A1	Members non-idle through the cohort	80%	below 60%
A2	Assigned or claimed tasks completed	70%	below 50%
A3	Completed work that receives a review	90%	below 75%
B1	Members verified via the normal path, not seeded	5	0
B2	Median days from first review to verified	45 or fewer	over 90
B3	Projects shipped rather than parked	4	below 2
C1	Members reporting a rate increase at +6 months	30%	0
C2	First foreign-currency income at +12 months	5	0

B1 is the primary criterion. If it comes out zero, either the thresholds are wrong or work volume is too low. Both are findings, and neither is visible unless the target was set in advance.

One expectation is pre-registered. The pool of qualified raters only grows as people get verified, so pace is slow and then sharply faster. Cohort one will produce few verifications and take a long time doing it. That is the shape of the function, not a failure of the design, and the fall in median days-to-verification between cohort one and cohort three is the network effect expressed as a number a client can read.

At n of about twenty, these are calibration numbers and not statistics. One member leaving moves A1 by five points. The founding cohort’s real job is to produce the baseline cohort two is judged against.

And the honest benchmark is the first attempt. 78% of the people who finished Design 101 went on to earn in dollars, with no platform at all. If this does not eventually beat four cohorts run out of a WhatsApp group by a committed founder, the platform was not the thing that mattered.

What we learned building it

Community is a product, and it has to be designed like one. The Slack group failed because it was launched instead of designed. Three hundred signups felt like traction and were noise. Onboarding, culture and recurring value are features, and they are features you build before you open the door.

Start with the people who care most. Co Ops was the accidental discovery that changed the growth model: you do not build a community by broadcasting to everyone, you go deep with the few who care and let them pull the rest in. The platform’s founding cohort, scout roles and circle seats are all that insight, given a schema.

Reviewing has to be tracked work. It produces value for somebody else and, until it is recorded as a contribution, nothing for the reviewer. Untracked work gets deprioritised, and that is simply how people behave. Treating it as a motivation problem instead of a design error is how reviewer supply becomes the bottleneck.

Leakage is the cheapest fix and the easiest to miss. The work already happened. Failing to bank it is the only avoidable loss in the system.

The exclusion in a metric is usually the whole metric. The idleness query is four lines of SQL and one NOT IN, and the NOT IN is the part that makes it true.

Placement will eat the machine that produces it, eventually. Placing the most-verified members removes the people who are also 3×-weighted raters, and rater availability is the binding constraint on verification pace. It is not urgent until placement is real, and it will be structural the moment it is.

Visibility is infrastructure. The most expensive mistake of the first four years was not the pricing and not the placement. It was having no way to see two thousand people. Effort does not fix that. Only a system that makes the invisible visible does.

When verification feels slow, the temptation is to lower the thresholds. Do not. The difficulty is the product. A verification that is easy to obtain is worth nothing to the person hiring, and hard to obtain is the entire asset. Raise throughput, never lower the bar.