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, selling tickets through the usual platforms, watching a slice of every event disappear before it reached an artist or a venue. We replaced the lot 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.
Start with what the options actually cost. These are public numbers.
In Czechia, the total take on a ticket is now about a tenth of its price. Karel Sasín, co-founder of Smsticket, breaks the dominant platform down as roughly 7-8% charged to the organiser plus about 3.5% added to what the buyer pays. His own platform charges organisers up to 5% and the buyer a flat 10 crowns. For comparison, he puts the US and UK at 20-30% once service fees and surcharges are stacked — which is the direction this market is moving, not away from.
Eventbrite publishes its rates: in the UK, 6.95% plus £0.59 per ticket. You can absorb that or pass it to the attendee, which is a choice about who sees the number, not whether it is paid.
Resident Advisor doesn't bill the promoter at all — and this is the one worth understanding properly, because "free for promoters" is doing a lot of work in that sentence. RA charges your audience instead. In the example on their own fees page, the buyer pays £8.50 and the promoter receives £7.50. That pound is not free; it is a 13% price increase on your event, set by someone else, paid by your fans. It comes out of the same wallet either way, and it constrains what you can charge before anyone has bought anything.
Then the local context. In May 2026, GoOut, Ticketportal and Ticketstream merged under the Estonian group PLG. Czech ticket prices are up roughly 33% over seven years. Government cultural subsidies are down. The competition office declined to intervene. And Lukáš Jandač, who runs PLG in the Czech Republic, described the merger like this: "I think it's healing the market, because the competition that was here, we were giving out super low commissions. That system wasn't sustainable in the long term."
That is your supplier telling you, on the record, that low commissions were the problem and that there is no longer a competitor positioned to bring them back down.
Against that, here is what the collective's own infrastructure costs: around $2/month right now — just the domain. Vercel, Supabase, Resend and Upstash all sit inside their free tiers at this volume. Even after outgrowing those thresholds, the total peaks around $70/month.
Stripe still takes its standard transaction fee (1.4% + €0.25 for European cards), but that is the unavoidable cost of accepting money anywhere on earth. My own fee for running and supporting the system is a flat 3% of ticket sales, on top of a one-off setup — I would rather put that number in the article than have you find it in a contract. The point is not that percentages are evil. It is the difference between three per cent you can see the value of and roughly ten that nobody will explain to you, decided by a group that has just told the press the old rates were too low.
Now substitute "music collective" for any business with the same shape: an e-commerce store paying a percentage on top of payment processing, a coaching practice paying per session, a membership site, a class-based business. The percentages vary, the pattern doesn't — a layer taking a recurring cut of your transactions in exchange for infrastructure that has largely become a commodity.
The first event the collective ran on the new system, no platform took a cent — from them or from the people who came. 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.
Fee figures: Expats.cz on Czech ticketing consolidation, Euro.cz on platform margins, Eventbrite's published organiser fees, RA's fees page. Correct as of August 2026.
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.