The startup that survived
two failed software builds.
MePass had built its platform twice before BSP. Both times the project failed for different reasons. Both times the founder lost control of the product they'd paid to build.
The third time, they owned the code before a single line of code was written.
18,600+ organisers • 1.88M+ attendees • Zero user complaints during a 10-day DDoS attack
Two agencies. Two failed builds. The same ending.
The idea worked. The market showed up. The technology partner didn't.
Twice before BSP, MePass hired teams that couldn't deliver what the business actually needed. And both times, the moment the platform started proving itself, the relationship turned. Pricing shifted, ownership got murky, and the founder ended up locked out of their own product.
The first build validated the concept but couldn't scale once real users arrived. The second collapsed under live traffic. Different technologies. Same outcome.
By the time they came to BSP, MePass didn't need another software company. It needed a partner it could trust with the product it had already lost control of twice.
Trust over technology
When you've been burned twice, the technology stack is the least of your concerns.
The biggest risk wasn't if it could be built, but who controlled it once it was.
Without full ownership of the codebase and transparency on infrastructure, any success would just lead to another hostage situation. The foundation had to be trust, secured before development started.
Success started before the first line of code
The third build started with a different order of priorities. Not technology first. Trust first.
The first thing to change wasn't the code. It was ownership. The founder held the codebase from day one, before development began. Not a reward for good behaviour later, not something to be negotiated once the platform looked valuable.
Commercial surprises disappeared before development started. Fixed pricing, with the recurring infrastructure and support costs laid out up front instead of buried until it was too late to walk.
And the technology choices were made around the business, not the budget. The cheapest option rarely survives two years, and that got said out loud rather than discovered later.
Those decisions didn't change the technology. They changed the relationship around it. It's the entire reason the third build is the one that lasted.
Built to survive success.
Every technical decision came back to one question. What happens if MePass actually works? That single question changed every technical decision that followed.
Components could scale on their own, so growth never meant starting over. Infrastructure expanded automatically when traffic from popular event launches spiked, with no manual intervention. Search visibility was engineered into the platform from the start instead of added afterwards, and it compounded into millions of Google impressions with no paid spend.
Security was designed before the first attack, not after it. When a sustained 10-day DDoS hit, a million requests a minute, not one user reported downtime.
And the product never stopped moving. Close to 5,000 production deployments in twelve months kept it evolving every week.
The Results
The founder finally owned the product they had set out to build, and the business gained a platform that could keep growing instead of needing another rebuild.
8.71M
Google Search Impressions
231K
Organic Clicks
18,600+
Active Organisers
3,252+
Events Hosted
1.88M+
Event Attendees
0
User Complaints During a 10-day DDoS
We had been burned twice. Not because our product didn't work, it did. We were burned because the teams we trusted held our own code against us the moment we showed commercial promise. BSP was the first team that gave us the code before we gave them the contract. That one act of transparency changed everything.