If your business runs on a SaaS platform that takes a percentage of every transaction, the math you did when you signed up is probably out of date.
Three years ago, "build your own" meant a multi-month engagement with an agency, €30,000+, and a maintenance contract you couldn't get out of. Buying was the obvious answer. Today, the same build is a fraction of that — and runs for the cost of a domain name. The platforms haven't lowered their fees; the cost of replacing them has collapsed.
This post is about one project where that math became impossible to ignore: a small music collective in Prague that was hemorrhaging money to Eventbrite and Resident Advisor on every event they sold. We replaced both with a system they own and run themselves. The result is now live at hereandthe.re.
But the interesting story isn't the build. It's what the build implies for any small business currently paying a percentage to a SaaS layer.
The brief
The collective needed something simple on the surface and complete underneath:
- A public website where people could discover events and buy tickets
- Direct payment via Stripe, with no middleman taking a cut
- Tickets delivered automatically by email — properly designed PDFs, not just a confirmation
- A QR code on each ticket that staff could scan at the door to check people in
- An admin panel the team could use themselves, without ever opening a database or asking me to deploy code
- The ability to handle multi-tier pricing (early bird → pre-sale → general admission) with stock automatically transitioning between waves as each tier sold out
They had an event coming up. The clock was the constraint.
Why this is now a fast build, not a multi-month one
The reason this project was even possible to scope tightly comes down to four things that have quietly become commodities:
Payments. Stripe Checkout handles the entire payment flow. We never touch card details, never deal with PCI compliance, never write a credit card form.
Backend. Supabase gives you Postgres, auth, and file storage on a free tier that comfortably covers a small operation. No DevOps, no provisioning.
Frontend + deployment. Next.js 15 with the App Router on Vercel. Server actions handle the form-heavy admin work; static rendering handles the public pages. Deploys on git push, with preview environments firing automatically on every branch.
Email. Resend handles transactional email with reliable deliverability after a 20-minute DNS setup.
Add pdf-lib for ticket generation (A5 landscape, custom typography, QR rendered in white on a side panel for easy scanning), and that's the whole stack.
None of these tools are new. What's new is the combination — and the fact that the boring, well-documented path through them is now the default. Boring is what ships fast. Boring is what a small team can maintain themselves afterward.
What was actually built
When the collective announces an event, they go to a single admin page. They fill in a form: name, date, venue, lineup, a paragraph or two of description, the schedule for the day. They upload a poster image. They define their ticket waves: an early bird at one price with a fixed cap, a pre-sale at a higher price, then general admission. They click save.
That's it. The public event page renders automatically. The Stripe products are created on the fly when someone buys. The webhook handles everything else.
When a ticket sells, the system:
- Confirms the payment with Stripe via webhook
- Writes the order and the ticket record to the database
- Generates a PDF with a unique QR code
- Emails the buyer the PDF as an attachment, plus a hosted ticket page link
- Updates the wave's stock counter; if the wave is now sold out, automatically activates the next tier
At the event itself, door staff use a phone-based scanner page. Point it at a QR code, get a green flash if the ticket is valid, red if it's already been used or doesn't exist. No app to install — just a URL with a secret key.
The math, plainly
Here's where it gets interesting for anyone reading who isn't running a music collective.
The collective was paying 7-9% in platform fees on every ticket sold. For a small operation doing a handful of events a year, that's thousands of euros annually — money that left the scene before artists or venues saw it.
Their new infrastructure costs around $2/month right now (just the domain). Vercel, Supabase, Resend, and Upstash all sit comfortably in their free tiers at this volume. Even when they outgrow those thresholds, total infrastructure cost peaks around $70/month — a fraction of what they were paying before.
Stripe still takes its standard transaction fee (1.4% + €0.25 for European cards), but that's the unavoidable cost of accepting cards anywhere. There's no platform on top of that.
Now substitute "music collective" for any business with the same shape: an e-commerce store paying Shopify a percentage on top of payment processing. A coaching practice paying a booking platform per session. A small membership site paying Patreon. A class-based business paying ClassPass or Mindbody. The percentages vary, but the underlying pattern doesn't — a SaaS layer extracting a recurring tax from your transactions, in exchange for infrastructure that is now mostly commoditized.
The first event the collective ran on the new system, the platform didn't take a cent. That's the headline.
Things I'd do differently
A few honest reflections, for anyone considering similar work:
Plan the admin UX as carefully as the public UX. The public site is what users see. The admin panel is what the team uses every week, forever. If it's clunky, it makes a bad impression on the people who decided to trust you with their business. Spend time on it.
Cache invalidation is still hard. Static rendering is great for performance, but the moment admins start editing data, you need explicit revalidation hooks everywhere. I missed a few on the first pass. The poster upload feature ended up requiring a manual redeploy on production to refresh the cache. Now it doesn't, but learning that took longer than building the feature.
Stripe webhook secrets are stricter than they look. Whitespace in environment variables is an invisible enemy. If your webhook is returning 400s for no apparent reason, copy-paste the secret again, somewhere with a monospace font, and look for the trailing character.
The file size ceiling on serverless platforms is a real planning constraint. Vercel's Hobby tier caps server action bodies at 4.5MB. For most use cases that's fine. For poster uploads, it isn't. The right architecture is to upload directly from the browser to object storage, bypassing the server entirely. I shipped the easy version first; the proper version is a follow-up.
When this math applies to your business
I'm not arguing every SaaS subscription should be replaced with a custom build. Most shouldn't. The math only flips when:
- You're paying a percentage of revenue, not a flat fee. Percentage fees scale linearly with your success; flat fees don't.
- Your use case is well-served by commodity primitives (payments, auth, storage, email). If you need something genuinely novel, the build cost is still high.
- You have enough volume that the percentage actually adds up to real money. Below a certain threshold, the SaaS fee is cheaper than your time to maintain anything.
- You can find someone who can build it boring — meaning fast, reliable, and handed off cleanly so you're not dependent on them forever.
If three of those four are true for your business, the build-vs-buy conversation is worth having again. It probably wasn't worth having two years ago.
If you want to talk through whether it applies to your situation, book a discovery call. I'll tell you honestly if the math works or doesn't.