One gift-card platform since 2007: how it was kept running, then rebuilt
GiftBucks has been a client since 2003. The gift-card platform we first built for it in 2007 still runs today, rebuilt on current technology rather than abandoned. Here is the account, and what it means for a business that depends on an older system.
GiftBucks has been a client of ours since 2003. The gift-card platform we first built for it, in 2007, still runs today. It is not the same code. We rebuilt the platform in 2016 and again in 2022, and the latest version, built in 2026, runs on WordPress with custom plugin code. This is the longer account of that work: what the platform is, why software that works can still reach the end of its life, and what to take from it if your own business depends on a system that was built years ago.
What does the GiftBucks platform consist of?
It has three parts. There are two public websites, giftbucks.co.za and giftcardsandvouchers.co.za. There is a private Card Management System, which has no public access. And there are white-label reward platforms, which GiftBucks’ own clients run under their own names. Together they are a business system, a membership system and a website.
The Card Management System is the part you cannot see, so there is no link to it here. A gift card is money a customer has already paid, which is why the record behind it has to be exact. Our article on loyalty programme examples explains how a gift card works as a loyalty programme.
The white-label part deserves a note. A white-label platform is built once and then run by other companies under their own brands. GiftBucks is one of several clients we have built this kind of system for. We do not only build one-off systems: we build systems that are turned into a product and deployed again, under a different brand or for a different market. Others are described in our loyalty programme guide and in the Network Dynamics case study.
How has one platform stayed in use since 2007?
By keeping the same studio responsible for it, and by rebuilding it as the technology underneath moved on. We first built the GiftBucks platform in 2007, and the latest version was built in 2026. The table below gives each date.
| Year | The platform |
|---|---|
| 2007 | First built |
| 2016 | Rebuilt |
| 2022 | Rebuilt again |
| 2026 | Latest version built, running on WordPress with custom plugin code |
The relationship is older than the platform. GiftBucks has been a client since 2003, and our work with it has been continuous since then and is still active in 2026. GiftBucks began as Creative Incentives, the same company, which still trades under that name too. The company is the same one. The code its platform runs on is not.
As a studio, we have been building custom business systems since 2001, and we have changed technology three times without changing what we do. In 2006 our work was custom web applications, content management systems, database-driven sites and e-commerce, alongside Flash and CD-ROMs. By 2021 it was web systems and apps, including progressive web apps and API integrations. Today it is custom WordPress plugins.
A platform that lasts has to cross changes like these, and it does not cross them on its own. Someone has to know what the system does, why each rule in it exists, and which parts the business cannot do without. That knowledge is what a long relationship keeps. It is also what is lost when a developer moves on and nobody else has seen the code.
Why does software that works stop being maintainable?
Because everything underneath it keeps moving. A system is written in a programming language and runs on a server, and both are updated on their own schedule. Older versions stop receiving fixes. Code written for them may keep running for a while, but every change becomes slower and riskier, until nobody can change it safely.
Languages publish these schedules. PHP is a clear example. WordPress’s plugin handbook says WordPress plugins are made up of PHP code. PHP’s supported versions page says each release branch is fully supported for two years from its first stable release, and then for two more years for critical security issues only. After those four years the branch reaches its end of life and is no longer supported. The page warns that users of an end-of-life release may be exposed to unpatched security vulnerabilities.
WordPress’s requirements page says the same from the other side. WordPress also works with older versions of PHP, it says, but those versions have reached their official end of life and may expose your site to security vulnerabilities.
So a system can work and be at the end of its life on the same day. “Deprecated” is the word for a feature its makers have marked for retirement. The original GiftBucks code base had deprecated to the point of being unmaintainable. A business in that position has three choices: patch the system, replace it or rebuild it.
Why rebuild, and not patch or replace?
We rebuilt it, in 2016 and again in 2022, and the latest version, built in 2026, runs on WordPress with custom plugin code and current security. In general, patching code that can no longer be maintained postpones the problem and adds to it, and replacing a custom platform with a rented product means fitting the business to the product.
Whether a rented product could do the job is a fair question for any business, and the answer is often yes. Our comparison of loyalty programme software, off-the-shelf or custom, sets out how to test it. Build only when the product cannot carry your rules.
GiftBucks is not the only system of ours to be rebuilt this way. Network Dynamics, a client since before 2005, runs its business on a logistics management system we originally built and have since rebuilt as a fully custom WordPress plugin with security hardening. That account is in a logistics system that outlived three technologies. We also rebuilt the websites of Tin Soldier in April 2025 and Something Fab in 2025. Both have been clients since 2005.
What is a custom WordPress plugin, and why build a platform as one?
A plugin is code that adds to WordPress without altering it. WordPress’s plugin handbook defines plugins as packages of code that extend the core functionality of WordPress. A custom plugin is one written for a single business, so the platform’s rules are its own and not a vendor’s.
The separation is the point. The introduction to the same handbook gives the rule: do not touch WordPress core, because WordPress overwrites its core files with each update. Anything you add belongs in a plugin. For an owner this means WordPress can be kept up to date while the platform’s own code sits apart from it, in one place, where it can be read and maintained.
Security is part of the same upkeep. Wordfence runs on every site, sites run on current PHP versions, and our servers are hardened, from locked-down file access to bot protection.
Most of our newer work has some custom plugin development in it. That ranges from a plugin for a simple animation to an entire website built as a custom plugin.
What can you take from this for your own system?
Five things, and none of them needs technical knowledge. Find out what the system runs on, treat slow changes as a warning, plan the rebuild before a failure forces it, choose a supplier for the long term and settle ownership in writing. They apply to a gift-card platform, a booking system or a database that one person understands.
- Ask what it runs on. Your developer or host can tell you the language and the version, and whether that version is still supported. If nobody can answer, that is the answer.
- Working is not the same as maintainable. Ask when the system was last changed, and how long the change took. A small change that takes weeks is the early warning.
- Plan the rebuild before it is forced on you. A rebuild chosen in a quiet month is a project. A rebuild after a failure is an emergency, with the business waiting.
- Choose for the long term. A system like this outlasts the technology it was first written in. Ask any supplier who will look after it in five years, and what happens to it if they stop.
- Settle ownership in writing. Before any build, with us or with anyone, ask who owns the code and what your licence allows. Our own answer is in our guide to running a loyalty programme in South Africa.
If you plan to offer your platform to other businesses under their own names, say so at the start. It changes how the system is built.
The next step
A platform like this falls under our Custom & Systems work, which is from R65,000 incl. VAT and is quoted only. The first discovery and quote are free. If you go ahead, the build starts with a detailed scoping phase, included in the price. Our custom business systems page explains how we scope and build one, and the GiftBucks case study has the short version of this story.
If you have a system that still works but that nobody wants to touch, tell us what it does and what it runs on.