Taking Yepic from MVP to thousands of tradespeople

The problem

Tradespeople don't lose money because they're bad at their trade. They lose it in the gaps between jobs — chasing invoices, hunting through text threads for a customer's address, writing the same job notes twice. Yepic wanted to close those gaps with one app: mobile-first, and good enough to actually use standing in a van between jobs, not just in a product demo.

The brief wasn't "build an app". It was build it fast, on a startup budget, and don't paint yourself into a corner the moment it takes off.

Talking to tradespeople before writing a line of code

We started by sitting down with electricians, plumbers, decorators and builders and asking them to walk us through an ordinary Tuesday. Every feature we shipped afterwards had to earn its place against that conversation: did it save time, or did it just look good in a demo?

That discipline mattered more than any technology choice we made.

Shipped in weeks, not months

The first testable version was in tradespeople's hands within weeks. One Flutter codebase gave Yepic an app that feels native on both iOS and Android, without maintaining two separate builds. The backend ran entirely on AWS serverless — Lambda, DynamoDB and S3, with Rekognition moderating anything users uploaded and SNS/SQS handling notifications. No servers to patch, no capacity planning, and a bill that scales with usage instead of with headcount.

Job folders, automated invoicing, payment reminders, quote approvals, and collaboration for firms with more than one contractor all went in on top of that foundation, each one judged against the same question: does this save a tradesperson time on a Tuesday.

What happened

Thousands of active users within months of launch. Tradespeople reporting time saved that's real, not the sort of number you have to squint at. More jobs converted, because quotes went out faster and nothing fell through the cracks of a group chat.

And no dedicated support team, because the app just works.

Why it worked

We didn't just write code against a spec. We acted like co-founders — pushing back on scope creep, saying no to features that would have been nice to have and useless to ship, and keeping the user experience in front of every technical decision instead of behind it.

That's the difference between a dev shop and a team that's actually invested in whether the thing works.