WeSherpa: concept to MVP as PM + lead dev
A founder came to me with a buzzword-heavy idea, blockchain and a decentralised back-end, for helping people in need through local shops. I cut it down to a working MVP and built it, acting as product owner and lead developer for a small team.
The idea
A way to help people in need in your own area. You donate, your money joins a pool at a local business (a supermarket, a library), and vetted recipients, certified as in need by the authorities, draw on it to buy essentials at 50–60% less. The idea underneath is simple: people who give often want their money to land in their own community, where they can see it. So the product made giving direct and local.
how a donation reaches a neighbour
The recipient's side, from the working MVP. Say what you need and set a budget, and the shops with credit to draw on appear. On this card you pay CHF 8.33 for CHF 18.33 of goods, a 54% saving. The "50–60% less" is the number on the card.
The hard part
Turning the founder’s vision into something viable. The early pitch was wrapped in trendy tech: blockchain, a decentralised back-end, the language of the moment. The idea underneath was sound, but a decentralised back-end did nothing for the person receiving groceries, and what the product needed was to be transparent about where the money went. So I cut the blockchain and the decentralised parts to reach a working MVP. They weren’t wrong, exactly; they were a step you take once there’s a product to hang them on. Maybe later.
The work was cutting the hype back to something that worked for a donor and a shopkeeper alike.
Around forty partner shops across Ticino took part in the pilot, one magenta pin each, and the pool can be spent at any of them. Giving that stays in your own area was the whole concept, and the map is that concept made real.
My role
Product owner and lead developer, with a small team behind me. I sat with the founder, who was effectively my customer, pinned down what the thing had to do, and turned his vision into the app’s processes and data types. I built it on Bubble, the no-code platform. That was a deliberate trade: less time writing code, more time on architecture and on keeping a shared picture with the founder as it grew. The front-end I built too, with a designer close at my side.
Architecture first, on Bubble. The data types and processes (communities, donations, shops, receptions, requests) modelled as the real backbone. This is where the founder's vision turned into structure he could watch take shape, sprint by sprint.
The front-end, with the designer at my side: adding to a shop's pool in a couple of taps, and redeeming credit at the till by code or QR. Those were the two moments that had to feel effortless.
Result
A working MVP, start to finish. When the funding round didn’t close by our deadline, I made the call to step away. I handed the CEO full access to the application and the documentation; he’d followed the build closely enough to find his way around it himself.
I’m of two minds about the no-code bet. It bought real speed and kept me aligned with the founder, which is what the MVP needed. But it landed just as AI-assisted coding took off, and if I were starting today I’d probably write the code myself.
Some of it I over-built. The clearest case: I gave every shop its own money bucket, when a single shared bucket would have been faster to build and looked identical from both the donor’s and the recipient’s side. Chasing the product cost me some sight of scale.
The shipped home screen, and these are the real pilot numbers from Ticino: the pool, the CHF 104,000 target sitting at 39.2%, the count of donors and of families being helped, and one clear button to add to it.