Enactus SAMS
The Enactus chapter at Sadat Academy for Management Sciences in Maadi: six student teams, one social venture a year, and a board that hands over every season. A site that has to recruit, and a panel that has to outlive the people who asked for it.
Industry
Student organisation, social entrepreneurship
Scope
Design, public site, management platform — recruitment and referrals, roles and permissions, content, forms, gallery
Stack
C++20 on Drogon and anvil, MongoDB, Redis, a React admin, and a server-side image pipeline
Homepage — the claim, the chapter, and two ways in
Where it started
A club whose board graduates.
A student chapter replaces most of the people who run it every year. Whatever we built would be operated by people who were not in the room when it was designed, and handed on by people about to leave.
And the site has two readers who want opposite things: a student deciding whether to give up their evenings, and the judges, sponsors and academy checking that the chapter is serious. One page had to persuade the first without embarrassing itself in front of the second.
The structure
Shaped by the season, not the org chart.
One project, told in full
The year’s venture gets a section of its own — the problem, how it works in four steps, and where it went — instead of a logo in a grid of past projects.
Six teams, six doors
Presentation, Project Management, HR, External Affairs, Social Media and Media Production each say what the work is. The application starts from the team, because that is the question an applicant arrives with.
Recruitment has a switch
Open, with a deadline; or closed, with a waitlist and a note on when the next season starts. The board flips it from the panel and the join section changes its call to action with it.
Roles that survive a handover
Seven roles from super admin to member, and permissions per panel. A team manager sees their own applicants and their own roster, so a new board can be given exactly what it needs on its first day.
The call we argued about
Whether the teams on the homepage should be the teams in the database.
The obvious build is one list: create a team in the panel and it appears on the homepage, in the application form and in access control. Tidy, and wrong — a team renamed for recruitment on a Tuesday would rewrite copy the media team had written, photographed and approved.
So there are two. The operational teams drive recruitment choices, manager assignments and rosters, and stay in sync with each other automatically. The homepage cards are copy, edited in the content panel and never touched by a rename. One more thing to maintain — and the public page only changes when someone means it to.
Build choices
A panel for a board that changes every year.
What it needed
The real product is behind the login: applications with accept, reject and refer-to-another-team, rosters that update when someone is accepted, a form maker, CSV exports, and an activity log of who changed what. A C++20 server on Drogon and anvil, MongoDB and Redis behind it, a React admin in front.
What we left out
A framework on the public site. It is one page, read mostly on phones over campus data, so it ships as plain HTML, pre-compressed, with photographs downscaled and re-encoded on the server the moment they are uploaded.
Outcome
Live at enactussams.org. The chapter carried Tafrah to the Enactus Egypt national competition, and recruitment, content and rosters now run from the panel — by whoever is on the board that year.
Next case study
Yard Club