Every founder evaluating custom software eventually asks the same question, usually in the same slightly apologetic way: is there something off the shelf that does this?
It’s a good question and the honest answer is often yes. Plenty of businesses that commission custom builds shouldn’t. But the reverse mistake is more expensive, because buying a platform that nearly fits and then discovering the gap at scale means paying twice.
UK prize competition platforms make a useful case study for working through the decision, because they sit at an awkward intersection. Superficially they’re ecommerce. Underneath they carry regulatory logic, a specialist payment path, real-time inventory contention and a traffic pattern that would embarrass most hosting setups. If you can reason about build vs buy for this category, the framework transfers to most regulated transactional software.
Table of Contents
Where Buying Genuinely Wins
Start with the case for SaaS, because it’s stronger than custom software vendors like to admit.
Speed to launch is the obvious one. A hosted competition platform can have you taking payments in days. A bespoke build takes weeks. If the goal is validating whether anyone wants to enter competitions for the prizes you can source, weeks of development time is a poor use of runway.
Cost profile matters too. Monthly fees mean no capital outlay, which suits a founder testing an idea rather than committing to a business. And someone else carries maintenance, security patching and platform updates, which is real work that founders consistently underprice when they compare a one-off build cost against a subscription.
There’s also a compliance argument in SaaS’s favour that gets overlooked. A platform serving hundreds of operators in one regulated category has usually encountered the regulatory edge cases already. That interpretation may be conservative and generic, but it exists, which is more than a generalist agency building its first one in the category can say.
If you’re pre-revenue and testing, buy. That’s not a compromise, it’s the correct answer.
Three Signals You’ve Outgrown It
The decision changes with scale, and the signals are fairly consistent across regulated categories.
The first is that the economics invert. Monthly fees plus per-transaction cuts are trivial at low volume and material at high volume. There’s a crossover point where the annual cost of renting exceeds the one-off cost of owning, and past it you’re paying a tax on your own growth.
The second is that you start hitting the roadmap. You need a mechanic, an integration or a compliance feature that isn’t there, and you’re in a queue behind every other customer. For a business whose competitive advantage depends on that feature, waiting is not a neutral outcome.
The third is that something breaks under load and you can’t fix it. On shared infrastructure you don’t control the database configuration, the caching layer or the resource allocation. When a draw closes and the checkout degrades, your escalation path is a support ticket.
Any one of those is a conversation. All three at once is a rebuild.
What Actually Has To Be Custom
This is the part worth getting specific about, because “we need a custom build” is a conclusion, not an argument.
Compliance is a data model problem, not a content problem. Under Section 14 of the Gambling Act 2005, a UK prize competition is lawful without a gambling licence if entry requires genuine skill, or if a free entry route of equal standing exists alongside the paid route. That has structural consequences. The skill question has to be enforced server-side at checkout on every paid entry. Free entries have to be logged and enter the same draw as paid ones, with an audit record you could hand to a regulator. Postal entries have to reconcile into the same draw. None of that is a page you write. It’s schema, validation and business logic, and it cannot be layered onto a system designed without it.
Concurrency against finite inventory is the hard engineering problem. A competition has a fixed ticket allocation and per-customer entry caps. In the final hour before a close, hundreds of concurrent sessions are competing for the same remaining units. A naive read-then-write stock check oversells, and reconciling an oversold draw after the fact is a trust problem rather than a technical one. Getting this right means row-level locking or atomic decrements, careful transaction boundaries, and load testing that simulates the actual event rather than steady-state traffic.
The API layer determines your future options. If a mobile app is anywhere on the roadmap, the platform needs to expose entry state cleanly enough that app and web reconcile in real time. An entrant who buys in the app and checks their account on the site should see identical numbers immediately. Retrofitting that onto a platform designed as a monolithic website is significantly harder than designing for it.
The Migration Cost Nobody Prices
If you do decide to build a competition website after starting on a hosted platform, budget for the move rather than just the build.
Entry history and draw records have to transfer, and they’re often the data a hosted platform exports least helpfully. Customer accounts need migrating without forcing a password reset that kills half your list. URL structure needs mapping and redirecting, because organic traffic in this category takes months to rebuild. And your merchant account may need reapplying, which means a gap, which means missed draws.
Specialists in the category treat this as distinct work. Nera Marketing, which builds UK competition and raffle platforms exclusively, handles data and draw-history transfer plus replacement of at-risk merchant accounts as part of a migration project, and their observation is that operators past roughly £10,000 a month tend to move within twelve months of launching on a builder. That timing is worth planning around rather than discovering.
A Framework, Briefly
Buy when you’re validating demand, when volume is low, and when the constraints of a shared platform don’t touch your differentiator.
Build when the economics have inverted, when a capability you need sits outside someone else’s roadmap, when regulatory logic has to live inside your transaction flow, or when load behaviour is commercially critical and you need control of the stack.
And whichever you choose, choose it knowing the trade-off. The projects that go badly are rarely the ones where someone picked the wrong option. They’re the ones where nobody realised there was a choice being made.
Join The Logo Community
We hope this article has been helpful. If you would like more personal tips, advice, insights, and access to our community threads and other goodies, join us in our community.
You can comment directly on posts, access our community threads, have a discussion and ask questions with our founder Andrew.
Tired of clients questioning your logo design prices? Our new eBook gives you the exact scripts, objection handlers, and confidence to communicate your value. No more awkward pricing conversations—just more high-paying projects.
Get it Now!
