Snapshot
Namibia's first online auction platform for everyday buyers and sellers.
JuggleBee was built to give everyday buyers and sellers a structured way to auction goods or sell them directly online instead of relying only on informal channels.
The platform combined timed auctions, fixed-price listings, and escrow-style transaction handling to offer a more trustworthy and structured alternative to Facebook Marketplace.
That mattered in Namibia because most auctions were still physical, the population is spread across large distances, and there were very few digital options for general-purpose online trade.
The Business Problem
Demand for auctions already existed. The digital equivalent did not.
Namibia already had an active auction culture. Physical auction houses were familiar, trusted, and regularly used for everything from household goods and collectables to vehicles and estate stock. The gap was not demand for auctions, but the lack of a convenient digital equivalent for general consumer goods.
In practice, most person-to-person selling online happened through informal channels such as Facebook Marketplace, where listings were easy to post but transactions relied heavily on trust. There was no structured online auction environment for people who wanted more than a classified-style listing.
JuggleBee was created to close that gap by bringing auctions and direct purchases into a single online platform built for ordinary Namibians. Focused mainly on second-hand goods, collectables, and general peer-to-peer trade, it created a safer and more structured alternative to informal online selling while adding convenience to a market still shaped by physical auctions.
My Role
End-to-end technical ownership from first release onward.
I served as co-founder, lead developer, and technical owner of JuggleBee. My business partner handled the operational side of the marketplace, while I was responsible for designing, building, and evolving the platform itself.
From the initial implementation onward, I led virtually all technical work on the product. That included application architecture, Ruby on Rails development, database design, infrastructure planning, deployment, maintenance, upgrades, and ongoing production support.
JuggleBee was built primarily by me as a solo developer, and I remain responsible for investigating issues, delivering fixes, and extending the platform where needed. That meant full technical ownership of a real production system across initial build, ongoing operation, maintenance, and later modernisation.
The Platform
A full marketplace, not just an auction listing site.
JuggleBee was built as a full online marketplace rather than a simple auction listing site. Users could create listings for timed auctions or fixed-price products, upload images, add descriptions and item details, and manage their activity through a profile area that tracked listings, purchases, and auction participation.
On the buyer side, the platform supported bidding workflows, outbid notifications, direct purchases, and a shopping cart for fixed-price items. On the operational side, it included moderation and administration tools for reviewing listings, editing or unpublishing problematic submissions, managing users, and maintaining standards across the marketplace.
Auction fairness
I implemented automatic auction extensions to prevent last-second bid sniping, giving other buyers a fair chance to respond and making the experience feel closer to a live auction.
Local-market payments
JuggleBee generated transaction data internally and pushed it to a third-party invoicing service via API, which issued the final invoice and payment instructions to the buyer.
Original stack
The platform was built in Ruby on Rails with jQuery on the front end, PostgreSQL throughout, Docker from the beginning, and production infrastructure built around AWS Lightsail, Sidekiq, Redis, and AWS SQS.
Key Challenges
The difficult parts were commercial, operational, and technical at the same time.
Trust in a new marketplace model
The platform introduced a more structured payment-handling process into an environment where many people were used to informal person-to-person selling, so legitimacy and reliability had to be earned.
Fair auction behaviour online
Physical auctions allow room for last-minute competition. Online auctions are vulnerable to bid sniping, which is why I implemented automatic extensions whenever bids arrived close to the end time.
Local market constraints
Off-the-shelf online payment flows were not a straightforward fit for the Namibian market, so the purchasing process had to be designed around invoice generation and controlled payment handling instead.
Long-term continuity
The platform had to keep serving real users while its technical foundation aged, which meant modernisation had to be handled as an operational risk, not just a coding exercise.
Modernisation Work
A production-safe rebuild and migration rather than a risky in-place upgrade.
Modernising JuggleBee meant more than upgrading a framework version. The platform had been running live in production for years, so the work had to improve the system without disrupting users. Rather than attempting a risky in-place upgrade through multiple generations of the stack, I treated it as a broader modernisation effort by building a fresh Rails 8 application, migrating the platform forward, and swapping it over with minimal visible disruption to the live service.
Framework and language upgrades
I upgraded the application from Rails 4.2 on Ruby 2.3 to Rails 8 on Ruby 3.4.3, while also moving the database from PostgreSQL 9 to PostgreSQL 17.
Modern Rails patterns
Older patterns and dependencies were replaced with current Rails conventions, including a move away from CarrierWave toward S3-backed ActiveStorage and from older secrets handling toward Rails encrypted credentials.
Operational simplification
I removed Sidekiq, Redis, and AWS SQS, migrated background jobs onto Solid Queue and more Rails-native patterns, and reduced the overall infrastructure and maintenance footprint.
Deployment modernisation
Hosting moved from AWS Lightsail to Hetzner, manual SSH-script deployment was replaced with Kamal, and the Docker-based approach already in use was retained and modernised.
Outcomes
A durable production platform with real commercial usage and a leaner technical foundation.
Since launching in 2014, the platform has remained consistently available in production, with only rare short-lived disruptions during deployment issues.
Just as importantly, JuggleBee showed that an online auction and second-hand marketplace model could work in Namibia, creating a structured online space for buying and selling in a market still shaped largely by physical auctions and informal person-to-person trade.
Why This Matters
The value was not just in building the platform, but in evolving it responsibly over time.
JuggleBee reflects the kind of engineering work many businesses actually need: building useful software, operating it in the real world, and continuing to improve it as the product, users, and technical demands evolve.
That included greenfield product development, long-term ownership of a live production system, and later modernisation work carried out without losing sight of stability, continuity, or the commercial realities behind the platform.
That experience maps directly to the work Red Oryx now focuses on: helping organisations build new software on solid foundations, improve long-lived Ruby on Rails systems, and make safer technical progress over time.