- Sector
- Social · Community
- Year
- 2021
- Role
- Lead developer · team lead
- Outcome
- Built from scratch · team of 5 · QA/QC + CI/CD introduced · frequent releases
What needed fixing.
Building a social network from scratch is mostly a discipline problem disguised as a feature problem. Profiles, relationships, messaging and a feed are not individually hard; keeping them coherent and shippable, with a team of five and frequent releases, is where projects come apart. There was no QA process and no reliable release pipeline to hold it together.
How I built it.
I architected the platform on Drupal 8/9 with Apache Solr for search, Redis for caching, PostgreSQL for data and Stripe for payments. As team lead I introduced QA/QC and CI/CD with frequent, low-drama releases — the unglamorous scaffolding that lets five people ship a complex product without standing on each other's toes.
Profiles, friends, messaging, dating and forums — a full social network built from nothing, with a team of five and a release cadence that didn't set anything on fire.
- 01Build a social network with profiles, friends, messaging and dating from scratch
- 02Add community forums and the surrounding social features
- 03Lead a team of five (backend, front end, QA) to a steady release cadence
- 04Introduce QA/QC and CI/CD where there were none
- User profiles, friend system and direct messaging built from the ground up
- Dating capabilities and community forums
- Apache Solr search, Redis caching, PostgreSQL data layer
- Stripe payment integration
- QA/QC process and CI/CD pipeline introduced to the team
Two products wearing one login
A dating app and a community forum are not the same animal, whatever the pitch deck says. One wants you to find a single person and leave; the other wants you to stay and argue with hundreds. This platform — a US social network, built from scratch — had to be both at once, behind one account, without either side feeling bolted on. Profiles, friends, messaging, matching: the easy part to describe and the hard part to make feel effortless.
One-to-one, where the product wants you to find a person and leave.
One-to-many, where it wants you to stay and argue politely.The part users never see, doing the heavy lifting
A social feed is a deceptively expensive thing: every scroll is a fan of queries that all have to come back before the page feels alive. So the interesting work sat behind the UI — Apache Solr carrying search and discovery, Redis holding the hot paths so the database wasn't asked the same question a thousand times a minute, PostgreSQL keeping the relational truth, and Stripe handling the bit where the product has to actually make money. None of it is visible. All of it is why the thing felt quick.
Five people, shipping often
I led a team of five — two backend, two front-end, one QA — and the first thing we changed wasn't code, it was the cadence. QA and QC where there had been none, CI/CD where releases had been an event you scheduled around. Frequent, boring releases beat rare, heroic ones every time; the goal was to make shipping so routine nobody had to be brave about it.