Closed project · no success claim
BeeBusy: the group stayed, the platform did not.
A task waited on an agreed number of bees, a contract, and nectar. That shape is in the code. Beside it, Sina tells what it meant to lead people who were counting on him when the product still stopped.
What this page is, and what it refuses to invent
BeeBusy is a closed platform. It cannot be ordered and it is not running. Two public repositories belong to it: talent_buzz, last commit read on 3 June 2024, 25 commits from one account, and talent_buzz_mvp1, with commits through 15 September 2024. That second repository shows 110 commits from sadeghesfahani and 18 from the omnitechs account.
The PowerPoint and the meeting notes were not found on this machine, so they are not quoted. The sentence that the group stayed friends and later worked together again is the founder's account. Those names are not authors in the public commit list.
The shape in talent_buzz_mvp1
What a task held onto
The names come from the Django models. This is a map of the code, not a screenshot and not a user count.
| Model | What it records | What it does not prove |
|---|---|---|
| Hive, Bee, Membership | A hive, a person who takes work, and the membership between them | No member list and no team size |
| Task | Title, description, priority, urgency, status, due date, and the required number of bees | No evidence that tasks were posted |
| TaskAssignment | A separate acceptance step: assigned, accepted, or still active | No count of accepted work |
| Contract and Nectar | The agreement and the return, kept beside the task | No price and no payment |
| Assistant | A later addition that tried to fill a profile, education, experience, and certificates from a CV | No evidence that CVs were processed |
June to September 2024
Gigs first, then a hive
talent_buzz is the earlier tree. It has apps for users and finance, and a commit on 3 June 2024 fixes a filter on gigs. One GitHub account holds those 25 commits.
talent_buzz_mvp1 pulls the picture apart: hive, bee, nectar, contract, task, communication, helpdesk, and feedback. In July 2024 an assistant arrives that tries to set profile fields from a CV. In September 2024 the last read commit is about what happens when no skills are found. The history that was read stops there.
Why the shape is heavy
A task that waits on several bees is waiting on a market
The model says so. A task has a required number of bees. The assignment is only done when someone accepts. Without enough people on both sides, that status stays pending, however tidy the schema is.
That is the old lesson, now tied to the code: a wide marketplace needs repeated demand, enough density, and a sharp first task. More apps — a helpdesk, feedback, a CV assistant — do not create that density.
What Git does not show
People were counting on a lead, and the product stopped
Sina describes BeeBusy as the place where he learned to lead a group that was counting on him. The project did not make it. The group stayed friends and later worked together on other projects. That is not in the commit list. The public authors are two accounts, and omnitechs is the studio account.
The deck that would have shown the meetings was not found in Documents, the desktop, Downloads, or the project folders. This page does not invent those slides. Another angle of the same kind of lesson — a small team, a failed attempt, and what stayed useful — is in the essay on building systems around AI. That essay does not name this repository.
For a buyer
This is a closed lesson, not a package
BeeBusy shows that the founder modelled a many-sided marketplace and then watched it stop. It does not show adoption, revenue, or a method for making a team succeed.
A comparable question starts smaller: one task, one acceptance step, and a group that knows what happens when the other side does not show up. Custom software is the route used to investigate that now.
Do you recognise the density, not the metaphor?
Describe who posts the task, who has to accept it, and what happens when that second side stays away.