BLOG
backNobody sets out to build an Enterprise Resource Planning (ERP) system. You set out to solve a problem, a specific, painful, recurring problem that's costing people money and sleep. The ERP is what happens when the problem turns out to be bigger and more stubborn than you expected.
That's the honest story behind Monieoook, Moniepoint's in-house enterprise resource planning platform. It started with a busted reconciliation flow and a lot of dissatisfied merchants.
The problem that wouldn't go away
Back in January 2023, my co-founder and I were running an online storefront business. We were watching merchants, people selling on Instagram, through Shopify-style links, across multiple delivery platforms, lose their minds trying to figure out where their numbers went wrong.
When payments didn't add up, they had nowhere to look. Was it the POS? The payment gateway? One of the three delivery apps they were juggling? The complexity made it almost impossible to run a clean operation. Every discrepancy became a detective exercise, and most merchants didn't have the bandwidth to handle it.
So we built a fix. We called it Grocel, a point-of-sale system designed to simplify reconciliation across channels. We moved fast. Too fast. Two of us, both software developers, with two extra contract hands to help. Within months, we had something running. That speed cost us reliability.
Every day brought new complaints: card transactions failing, the system going down, and merchants caught mid-sale with a broken terminal. It was demoralising. We'd deployed a product that was supposed to solve problems, but instead created new ones. I remember looking at Moniepoint. Their terminals just worked. Consistently.
The conversation that changed everything
We almost walked away from payments entirely. We considered narrowing the scope, stripping Grocel down to pure software. But we knew what that meant: we'd be building just another POS system. The thing that made our product worth building, automatic reconciliation across payment channels, required the payment infrastructure to actually be part of the solution.
So my co-founder, who happened to know someone at Moniepoint from a previous job, reached out to explore a collaboration.
The response was honest: they didn't have the bandwidth to build a plugin for a third-party product. Fair enough. But we reached out again. And this time, the conversation shifted. Moniepoint was actually thinking about building something like this internally, an ERP system for their merchants. They were open to a partnership.
There was one significant obstacle: Grocel was built in JavaScript; Node.js, React, the works. Moniepoint's entire engineering stack was Java. A rebuild wasn't just likely, it was almost certain. We were potentially signing up to start from scratch. I thought about and sometimes you have to kill your darlings, and in the end, this was never really about the code. It was about solving a real problem for real people. If rebuilding from scratch was the price of doing that properly, it was worth paying.
I joined Moniepoint in November 2023.
The long runway to the actual build
The first three to four months after joining were consumed by research and planning. Working closely with Ravi, CEO of Moniepoint UK, we mapped out what this product needed to be, not just as a startup experiment, but as an enterprise-grade tool. We didn't really start building in earnest until Q3 2024.
When we finally got moving, it was a sprint. Small team; three backend engineers, two frontend engineers, and one mobile engineer. I also joined the frontend team, helping build the initial UI component library from scratch. The crew was lean but sharp: Mehmet, Bilal, Justin on frontend, Joshua, and Kem leading design.
We were moving fast and building a monolith: one codebase, everything in one place. That's often the right call for a small team trying to ship quickly. And we did ship. By December, we had our first working version, basic, no reporting, but functional.
The feedback that came back was instructive. The early complaints weren't about what was broken. They were about what was missing. Features that existing ERP systems (many of them founded in 2003 or 2004) had spent decades building. We were competing with legacy systems in our first year.
The five businesses and a proof of concept
I don’t need to sound salesy and say that Moniebook is a great product. It simply is. But to put this great product to work, we needed real users before we could claim we'd built anything worth using.
I went out and onboarded five businesses directly. It wasn't that different from what I'd done at Grocel: going out, pitching, and onboarding. They weren't getting a polished product; this they knew. They were getting a core system without full reporting, with rough edges, and with an implicit ask: help us understand what we're missing.
They said yes. They used it. And their willingness to commit, even to an incomplete product, was the signal we needed to start rolling it out more broadly. We leaned on the team to accelerate distribution, and they found exactly the right market segment.
The two architectural decisions that defined the product
Separation from the main app
Early on, we had to answer a deceptively simple question: who gets access to Moniebook?
Unlike Grocel, which had open onboarding, we restricted Moniebook to existing Moniepoint users. That was the easy call. The harder and more consequential decision was to keep Moniebook architecturally separate from the main Moniepoint application.
An ERP has a completely different permission hierarchy than a payments platform. If a business owner sets up their Moniebook account with their own staff roles and access levels, that shouldn't bleed into their Moniepoint account, and vice versa. Merchants want their inventory and financial systems to feel separate, even if they're connected under the hood.
I sat down and mapped it out. The solution we landed on: a Moniepoint business owner can sign up for Moniebook, and within Moniebook, create a completely separate set of staff and roles. Clean separation. No interference. It sounds straightforward now, but getting that architecture right was everything. It was a foundational decision.
From monolith to microservices
With a team of three back-end engineers, two front-end developers, and one mobile developer, we built the first version of Moniebook as a monolith. It was the right call for the timeline. It was the wrong long-term architecture. We knew this going in. The legacy systems carried the badge of monolithic design, tightly coupled services, deployment bottlenecks, and scaling nightmares. We didn't want to repeat that pattern.
The arrival of VP of Engineering, Pavan, was well-timed. He worked with back-end engineers to break down the system into microservices. A parallel team, including Justin and a front-end developer from MonieWorld, did the same on the client side.
The shift enabled independent deployment, allowing engineers to ship features without coordinating across the entire codebase. At scale, that matters enormously. Without it, we would have been fighting the system rather than building on it.
The Moniebook experience
Let me walk you through what a merchant actually experiences.
After verifying their email and linking their Moniepoint account, they first enter their business details: name, category, location, and branch. From there, they choose a plan that gives them access to a range of features.
Inventory and Pricing
For pricing, we support four models because businesses work differently. With fixed pricing, you set the price, and the cashier charges that price. With manual pricing, the cashier enters the price at checkout (useful for businesses where customers haggle). There’s margin pricing, where you set a margin percentage, and the selling price adjusts automatically when cost prices change; popular with larger supermarkets that receive stock frequently. And range pricing, with a minimum and maximum sell price, giving cashiers some flexibility within bounds
The Register
The cashier experience runs on two surfaces: the Moniepoint terminal (the physical device) or the web app (for businesses using standard computers at checkout). You name each register, "Cash Register 1," "Cashier," whatever makes sense, and the system generates a pairing code. The cashier logs in with a PIN and sees their view of the register. Every sale is recorded and attributed to the cashier who made it.
Reports
The reporting suite is where reconciliation comes to life. Sales by item, sales by category, top performers, lowest performers, average sale amount, discount tracking, payment method breakdown, and customer-level insights. It's all there. We also have an expiry inventory report that shows what's expiring and when, so merchants can push products before they spoil. And inventory valuation: at any point, a merchant can see exactly what their current stock is worth and what their potential profit would be if they sold it.
Production and recipes
With production and recipes, you define the ingredients for each dish (including quantities and units), and the system does the rest: it calculates the cost price of each plate, deducts ingredients from inventory when you produce a batch, and tracks how ingredient stock reduces over time. So if you decide to make 30 burgers, the system knows you've used 15kg of bread and 15kg of tomatoes, reduces both stocks accordingly, adds 30 burgers to your sellable inventory, and sets the cost price at whatever it costs to make one unit. It even handles expiry for produced items. If a burger expires in two days, the system tracks that.
Staff and roles
Merchants can add staff members with specific roles and permissions, and assign custom PINs. Every action in the system is attributable: stock history shows not just how much stock changed, but who caused the change. A cashier who processes a sale, an admin who adjusts inventory: all of it is logged against a name.
Multi-Branch
Merchants with multiple locations can manage them all from one account. Stock transfers between branches (or from a warehouse to a retail branch) are built in. Each branch has its own inventory, registers, and staff, but the owner sees everything from a single dashboard.
The Moniebook playbook
In February, Moniebook was processing thousands of transactions per day. Today, that number has grown by over 4000%.
The infrastructure decisions we made early, the microservices migration, the architectural separation, and the Java rebuild allow us to handle that volume without the system groaning under the load. We built the subscription system entirely in-house. No third-party plugins. It looks deceptively simple: choose a plan, pay, get access. But it's one of the hardest things we've built. Managing billing cycles, grace periods, plan upgrades, trial logic, debit authorisation: all of it custom.
ERP systems are not simple products, and we're not pretending we've solved everything. There are features we're still building. Accounting integration is coming. The roadmap is long and will continue to evolve as more businesses share what they actually need. What we do have is a system that works, a team that's moved fast without breaking the fundamentals, and a very clear understanding of the problem we're solving because we lived it before we built it.
We're still learning. But the team that built this, Bilal, Justin, Joshua, Mehmet, Ezekiel, Temilola, David, Kem, and the many others who joined along the way, they built something real in eleven months, and they're not finished.
It's still day one.
If you run a business in Nigeria and want payments and bookkeeping that actually work together, start HERE.
