Grab A Great Deal

In Spring 2024, I was living in London for a brief period with my dad. I mostly spent my time finding cool coffee shops to frequent, visiting Museums and the British Library; but around the same time, I also spoke to a former colleague, Chris Marsden of Minster FM, YO1 Radio and BBC Radio fame, admittedly, you've probably heard his voice on other projects, like Harry Potter video games or in Hollywood films.

We got talking about a software package that was being discontinued by one of the largest software vendors for the radio industry. The software package managed voucher deals and sales for the majority of stations nationwide. Many stations were turning to self-hosted Wordpress sites with WooCommerce as an alternative.

Some of these stations unfortunately lacked the experience and knowledge to properly manage these sites - which isn't a critique. Some stations are run by volunteers or non-technical people whom may not have day to day knowledge of Wordpress and the ongoing requirements to maintain it. Indeed, whilst Wordpress is one of the most wildly used CMS tools available, it is also one of the most exploited, so for small teams and/or volunteers, these sites most definitely would become "set and forget".

"Setting and Forgetting" is dangerous because over time attack vectors and technical debt accrue weakening the infrastructure and exposing the organisation and its data. Wordpress also allows plugins (third party code which is installed to add functionality) which from experience can become unruly and also expose the CMS to unknown attack vectors or supply chain risks - e.g. the third party developer supplying the plugin might supply "working code" but that code might be flawed, or use infected dependencies resulting in the Wordpress installation or its data being compromised.

To Chris and I, this seemed like the opportunity for a good partnership. I had the ability to create a software package that could be supplied to radio stations nationwide which negated the need for Wordpress, and Chris could do much of the sales/promotion - so we started planning "Grab A Great Deal".

The Business

The premise behind the voucher scheme is fairly simple. A radio station approaches vendors with the idea of exchanging advertising for vouchers, the sales of which pay for the advertising; but no money is exchanged upfront. In effect, radio stations make money on the voucher sales, and the vendors get advertising and money from any subsequent upselling on the deal they're offering (and, one would hope, repeat business).

Our hope was to sit bang in the middle, acting as a marketplace and advertising agency, like a niche Wowcher. The idea was that stations would be charged an initial fee to join, and then we would take a cut of monthly sales.

See, the other problem with individual Wordpress sites is that none of them are connected creating a uniform experience, so whilst it was possible for listeners to buy hyper local vouchers (with the addition of some "big names" in certain cases), customers would have needed to create multiple accounts to access discounts, which becomes tiresome and ultimately, a barrier to purchasing. From a cyber security perspective, it also spreads customers data around lots of little sites which are easier to exploit and therefore makes the risk to both business and customer greater.

That's where Grab A Great Deal came in, as it created a marketplace where vouchers were listed from all over the country, by all stations. Our hope was that as more stations joined, we would also be able to mitigate the fact that some stations had small listening numbers, and wouldn't ordinarily be able to attract larger brands/businesses for their voucher schemes; in essence, Grab A Great Deal would arrange the deals and sell stations air time.

Maybe customers could find a restaurant offering 2-4-1 and a Hotel offering 25% off when looking to take their partner on a spur of the moment romantic trip. Maybe they also found it precisely because it wasn't hidden on a Wordpress site only known to a subset of a subset of people in the general public. Same principle applies to every situation you can think of.... school holidays and treats for the kids, family meals, trips with friends, treating yourself, every day essentials....

So, with all that said, we registered Genesys Worldwide Ltd and software development started.

The Software

Deciding how to build the software was quite straight forward, I thought we should have an API which fed a website and mobile applications.

I made this decision for practical reasons because an API is like a contract for a website or app to follow, so when a new version is released it is easy to add/remove features, or extra data points instead of duplicating code in separate code bases. An API also meant if the website hosting service went offline, the apps still kept working and vice versa because they're separate services; but it also gave the project scalability,

I also recognised that many radio stations, who had already setup their Wordpress sites probably wouldn't want to ditch it (sunk cost fallacy) and, we could populate their Wordpress site with vouchers via a plugin, fed from the API, offering them an extra source of income (and further expanding our reach). I know I've just written about plugins being a security risk, but it does work both ways.

Unfortunately, "Internal Politics" and the "Magpie Effect" led to the API being ditched completely, in favour of Blazor Server. Don't get me wrong, Blazor Server is a fair choice for an MVP, I even used it for my University Dissertation project - Parentull - but it's not quite the vision I had for this project.

If I put my "Director" hat on for a second, I also think the wider business suffered because of the decision (not made entirely by me) to ditch the API because promises that had been made couldn't be properly fulfilled without an API and it also led to revenue avenues closing which would have brought money into the business.

Regardless, .NET provided a solid base for functionality we needed in identity and role management, but also in connecting out to make payments via Stripe. The database of choice was MySQL primarily because the objects we used were relational in nature and there wasn't a technical reason to move a different database type.

I'm now going to present screenshots of the software at various stages and talk about them. Let's start with the below screenshot of an early implementation of the category page.

This early concept shows how vouchers would be listed with an example title, description, price and category. This was later expanded to be much more visual.

In the backend, Partners would have a dashboard to manage their client vendors and vouchers. Again, this early screenshot demonstrates how a single station could have multiple vendors and multiple vouchers. It's also possible to see the formation of early statistics and data which I was also working on.

In order to sign up as a "Partner", users would need to complete a form as per the below screenshot. This unlocked the ability to create vendors and vouchers for sale, though obviously, during the early stages, we were only inviting a select people to join the platform.

What's interesting about the above screenshot is that it contains a "Banned Handle. This event has been logged." notification. I had envisioned that the application would be subject to malicious data entry, including users trying to create profiles with swear words and other profanity or abusive/harmful wording. This is not ideal given we were in the process of forming partnerships with large brands, so I created middleware to censor any profanity and keep the brand clean and wholesome. The middleware also used regex to avoid substitutions being used. Any attempt to circumvent this mechanism was also logged for review.

The screenshot below demonstrates the concern I had -

And the screenshot and video below formed part of the "badwords" middleware -

Throughout development, the partner dashboard got persistently better with improvements to show commission earned and which voucher codes had been sold. The theory being that if a Partner received a query or were running a live event, they would be able to identify the code easily from the dashboard. There was a plan to implement a function to allow client vendors to also see this information and have the ability to denote when a voucher had been used. A good case study being Doncaster Racecourse which was running live events and could have scanned a QR code or swiped an end customers code to highlight its use and prevent use again in the future.

Separately from the Dashboard, Partners were also given profiles. The idea behind the profiles was that that Partners could have an entry point to send their customers, in this case, domain.co.uk/partnerusername. When a customer visited the link, they would be shown the partners vouchers and any vendors that they were working with... but there remained a problem - each partner station came with its own branding and personality and this needed to be reflected on the Grab A Great Deal.

The solution came to me as I remembered a social networking site from my teen years, Bebo. Bebo had a feature which allowed users to change the css to create "skins" for predefined sections of profiles, but it led to a lot of creativity. To allow Partners to edit their respective profiles to suit their brand, I created a mechanism which allowed CSS overrides and refreshed the css for visitors based on the relevant partner.

Screenshots of profiles and the editor can be seen below in various stages -

For payments, I integrated Stripe and we did take payments through that integration. During testing, I conducted some tests which can be seen below.

Conclusion

Grab a Great Deal was deployed for a few months during 2025 and attracted multiple Radio Stations as partners from around the UK. Those stations additionally signed up vendors, including Doncaster Racecourse.

When Grab A Great Deal was launched, we were featured on Radio Today, the radio industries news source. This generated a fair few leads and it was an electric feeling for all of us running the business.

Unfortunately, the business didn't generate enough revenue to warrant keeping it live. That may have been different if the business had been marketed in a more understandable way, or sales had been conducted in a more coherent manner but ultimately those areas were delegated to the other directors. I was responsible for the software and technical areas of the business which arguably did succeed.

An example of how I know they succeeded is that I was approached by a competitor shortly after leaving the business who specifically referenced their interest in the software I'd built. During the conversations, I found bugs with said competitors software but they declined to pay for them to be fixed and to my knowledge haven't fixed them.

Overall though, Grab A Great Deal was an interesting and challenging project which I really enjoyed building even if it ultimately wasn't live for a long time.

Below is a picture of my workspace for most of that time, although I usually worked on the desktop as opposed to the laptop.

Interested in building a project with me?

If you'd like to hire me to build software for you or your business, get in touch by emailing hello@freelanceguy.co.uk.