Case studyApplication Build
The Collective Local: building a social network where people meet up in person
Built from scratch, with the safety decisions settled before any code
Consumer social · Next.js · Supabase · Drizzle · Vercel
thecollectivelocal.co.uk
The Collective Local helps remote and solo professionals find people near them. Which means the whole product depends on knowing where its members are, and on never telling anyone.
That is the hard part, and most apps get it wrong the same way. They send your exact position down to the app on your phone, then draw a fuzzy circle over it. The circle is only a picture. Your real position went down with it, and anyone who knows where to look can read it straight off.
This was built from scratch, so there was a choice about where that rule lived. It went into the foundations, underneath the app, where nothing built later can undo it.
There are two gates in front of every member. Your photo has to be verified before you can reach anybody at all, and once you are in, other members are told a rounded distance rather than where you are. Neither is something the app decides at the time. Both are settled underneath it, which is why they hold however the product grows.
And it is not one audience. Members are the point, but venues and practitioners each get their own way in, with their own things they can see and do. Three doors into one network is three sets of permissions to get right, which is a great deal easier to do at the start than to retrofit.
Design before code
Every screen was wireframed in-house before any code was written, drawing on over twenty years of building interfaces. Not just the flows: an empty list, someone who has blocked you, a request nobody has answered.
Those are the screens that normally turn up halfway through a build, when changing them costs the most. Agreeing them first meant the database could be shaped around what the screens needed, rather than the other way round.
How it was built, step by step
- 1
Work out what it must never do
Before anything else, the list of things that would be a disaster. For a product built on knowing where people are, that list starts in an obvious place and gets longer than you expect.
- 2
Wireframe every screen
Including the awkward ones: an empty list, somebody who has blocked you, a request nobody has answered. Drawn and agreed before a line of code existed.
- 3
Build the rules into the foundations
Each of those never-do rules became something the app is physically unable to do, rather than something it is supposed to remember not to do.
- 4
Then build the product on top
Profiles, finding people nearby, requests, messages, meetups, and separate ways in for venues and practitioners. All of it sitting on foundations that were already safe, so no feature could quietly undo the rules.
- 5
Check the things nobody checks
Going back through the default settings the platform had handed out, one of which turned out to sit outside every protection we had put in.
The default setting that could have wiped everything
When you set up somewhere to store data, the platform hands out a set of default permissions. Most are harmless, and almost nobody reads the list.
One of them was not. It allowed everything held in one place to be wiped in a single move, and it sat outside every protection we had put in. The data could not have been read by anyone, but it could have been deleted, and none of the safeguards would have stopped it.
It was removed, and the setting changed so that anything added later does not quietly get it back.
Nobody would find this by using the app. It only turns up if someone goes through the platform’s defaults line by line, which is the check that gets dropped when a launch date is close.
Building something where getting it wrong actually matters?
Constraints like these cost very little at the start and are expensive to retrofit. We can work out which ones your product needs before any code is written.