HighestBidders is an auction management platform for institutional auctioneers, banks and insurance companies. Think of it as the "Shopify" for local auctioneers, enabling them to quickly set up a "store" with the infrastructure to run auctions and a visibility plane for principals such as banks and insurance companies.
HighestBidders is currently in stasis, pending individual institutional approvals and backing auctioneer integration.
Problem
Most auctions in Kenya are done physically, on site. The few that run online:
-
Use tools unintended for auctions. One auction company I embedded myself in to observe their processes used a WordPress site, creating lots as blog posts, requiring bidders and auctioneers alike to refresh the page to get bidding updates, and manually copying final results into an external Google Sheet or Excel document to prepare reports for principals after auctions terminated.
-
Have fragmented payment infrastructure. Bidders need to pay a bid security to participate in an auction. This is mostly done through banker's checks, which bidders have to submit on site, or mobile money transfers through M-PESA. The auction house then manually compiles the list of authorized bidders, and an intern or employee does name-matching and manually approves bidders in the system.
-
Provide almost no visibility for principals during live auctions. They typically receive a report after the fact. In one auction house, their version of visibility involved giving a bank or insurance representative login credentials that provided unfettered access to the entire system, including the ability to mutate reserve prices, lots, bids, and other data. There was zero RBAC, leaving principals exposed to a high surface area of risk.
The problem wasn't simply that these auctions were offline. The bigger problem was that the software surrounding them wasn't designed around how auctions actually work.
The idea
The opportunity was to build a platform specifically around the auction workflow: auction management for the auction house, real-time bidding for buyers, automated bidder authorization, and a dedicated visibility layer for the institutions that own the assets being auctioned.
Instead of stitching together WordPress, spreadsheets, payment workflows and manual processes, HighestBidders would give auction houses a single platform for running the auction from listing through settlement while giving principals visibility into the process without exposing them to unnecessary operational access.
My role
I built HB as the technical third of a trio: myself, a marketer and brand specialist, and an auction industry insider with 20+ years of experience.
I owned the design, component architecture, and fullstack development of the platform end to end.
To start, I gathered as much information about the auction process as I could. Discussions with my auction industry partner, combined with embedding myself in an auction house's workflow, formed the basis of the MVP.
Approach
My approach was simple: build, test, and iterate in tight cycles.
After every significant build, I scheduled a demo call to test the feature with my partners and had them play around with it. I wanted to see where they understood the product immediately, where they hesitated, and what they expected to happen when the interface didn't behave the way they assumed it would.
Once we got the product to a usable state, we invited relevant external stakeholders to try it out in demo calls, carefully examining both their explicit feedback and their implicit expectations.
This became an important part of the product development loop. Rather than trying to design the perfect auction platform upfront, I kept putting working software in front of people who actually understood the workflow and iterating based on what I observed.
Architecture
Two groups interact with HB in fundamentally different ways.
Auctioneers need to manage the auction: create and manage lots, register bidders, monitor bidding activity, and manage auction outcomes.
Principals — banks and insurance companies — primarily need visibility. They need to know what is happening during the auction without having the ability to mutate the data they're monitoring.
That distinction shaped the access-control architecture. Instead of giving principals broad access to the same system auctioneers use, I built dedicated, read-only visibility surfaces with granular RBAC and audit trails for important actions.
Real-time bidding was another important architectural concern. An auction changes constantly: a new bid changes the current price, the leading bidder, and potentially the state of the auction itself. I used Ably to propagate those state changes to connected clients, giving bidders and observers sub-second updates without requiring them to refresh the page.
Bidder authorization was also tied directly into the payment workflow. I integrated M-PESA Daraja so that successful bid-security payments could feed into the authorization process instead of requiring someone to manually reconcile payments and approve bidders. Twilio handled OTP verification and 2FA.
Technology
Frontend
Next.js 16 · TypeScript · Tailwind CSS · Base UI · shadcn · Zustand · Zod · Cloudinary · Ably
Backend
Node.js · Express · TypeScript · Prisma · PostgreSQL / Neon · Zod · Ably · Twilio · M-PESA Daraja
Outcomes & impact
Testing HB with an auction-house partner produced several measurable improvements:
-
1.5×–3× productivity boost: significantly improved UX for auction managers, bidders, and principal representatives, cutting post-auction report turnaround times from hours to seconds.
-
~80% inefficiency reduction: automated much of the manual overhead surrounding item listing, bidder registration, live monitoring, and report generation.
-
Sub-second real-time bidding: delivered instant bid-state updates across the client interface using Ably.
-
Automated security and verification: integrated M-PESA Daraja and Twilio so bidders could receive automated account authorization after depositing security funds.
-
Institutional-grade RBAC: replaced shared administrative credentials with granular, read-only monitoring dashboards for bank and insurance representatives, alongside immutable audit trails of important actions.
Lessons
The biggest lesson was that embedding myself into the workflows of my target users and actually doing what they do was crucial.
There are things users can tell you about their workflow, and then there are things you only notice when you're sitting beside them and watching them work.
In HB's case, some of the most important product decisions came from seeing where people were wasting time, where responsibilities were unclear, and where existing software forced them to work around the system.
It reinforced something I now try to carry into every product I build: before trying to build the solution, understand the workflow deeply enough that the problems become obvious.