I built an "Agentic Accountant" to stop African merchants from matching bank alerts in Excel at 11 PM
Hey Indie Hackers! 👋
I'm Jeff, a solo developer building KoboSync (https://kobosync.com).
I wanted to share why I built this, the technical hurdles of building financial automation for the African market, and get your honest feedback.
THE PROBLEM: E-COMMERCE IN NIGERIA IS FRAGMENTED
If you run a business or sell digital/physical products in Nigeria, your checkout stack is fragmented. Customers pay across multiple payment rails—Paystack cards, Flutterwave links, Monnify bank transfers, and direct alerts.
When I talked to local merchants, Instagram vendors, and creators, I noticed a painful pattern:
• Midnight Bookkeeping: Business owners spend 5–10 hours every week manually matching SMS bank alerts to spreadsheets.
• Missing True Net Margins: Payment processors charge complex fee structures (like Paystack's 1.5% + ₦100). Merchants see gross sales on their dashboard, but have no idea what actual cash settled in their bank account after fees and 7.5% VAT.
• The USD Exchange Rate Trap: Global automation tools like Zapier or Make charge $30–$50+/month. With local currency devaluation, paying for software in USD is a massive drain on small business margins
THE SOLUTION: KOBOSYNC (AN AGENTIC COMMERCE OS)
I built KoboSync to serve as an automated financial intelligence layer between local checkouts and business records:
• Real-time Multi-Gateway Sync: Ingests webhooks from Paystack, Flutterwave, and Monnify, verifies HMAC signatures, and logs reconciled transactions to Google Sheets in under 3 seconds.
• Fee Intelligence & Net Profit: Automatically calculates exact gateway fees down to the last kobo and separates 7.5% VAT for audit readiness.
• Duplicate Shield: Detects network retries from gateways and blocks double-entry before it corrupts books.
• Front-Office Revenue Engine: Connects to the Google Merchant Center API to automatically sync available inventory to Google Shopping as Free Listings, and auto-marks items as out of stock when inventory hits zero.
• Flat Naira Pricing: ₦10,000/month flat fee with zero USD currency surprises.
THE TECH STACK & LESSONS LEARNED
As a solo dev, I opted for a monorepo setup to manage the web dashboard and background workers smoothly:
• Frontend & API: Next.js (App Router), Tailwind CSS, Framer Motion .
• Database & Auth: PostgreSQL, Drizzle ORM, Supabase Auth.
• Async Workers & Queues: BullMQ, Redis, Node.js worker threads.
One technical bug I ran into during development: When generating automated PDF receipts in Node.js worker threads, standard PDF fonts failed to encode the local Naira symbol (₦) properly. I had to inject a custom font engine with native Unicode TrueType fonts so customer receipts rendered crisp symbol output.
WHAT I'M LOOKING FOR
We are currently onboarding our first cohort of merchants and creators.
Since many of you have built SaaS products, managed webhook pipelines, or integrated OAuth/Google Sheets APIs, I'd love your feedback on:
Onboarding UX: How do you make connecting OAuth scopes (like Google Sheets or Google Merchant Center) feel friction-free for non-technical users?
Product-Led Growth: For a tool that saves hours of manual work, what visual hooks or "aha moments" have worked best for your landing pages?
Check out the platform at https://kobosync.com.
I'd love to answer any questions about the architecture, building for emerging markets, or bootstrapping SaaS in Africa!
For the landing page visual hook, don't just show static dashboard screenshots. Show an interactive "Before vs. After" GIF: on the left, a merchant manually cross-referencing messy SMS bank alerts with Excel at 11 PM; on the right, a Paystack webhook hitting KoboSync and instantly updating net profit after fees and 7.5% VAT in 3 seconds. When a local vendor sees their exact gateway fee headache solved on screen, that's an instant conversion moment.
Haven't thought about this, but I think this concept will look cool in the demo section of the landing page. Thanks
Hey, congrats on building KoboSync — reconciling Paystack/Flutterwave/Monnify into proper accounting is genuinely painful and you've nailed the problem.
I'm the founder of Zarek (https://zarek.tech/), an AI launch co-pilot for indie founders. I used it to build a full launch roadmap for KoboSync as a demo — here's what Zarek produced, step by step:
Phase 1 — Foundation (before anything goes public)
Lock one-line positioning. Example: "KoboSync automatically reconciles Paystack, Flutterwave, and Monnify transactions into Google Sheets, Xero, and QuickBooks in real time — built for Nigerian merchants."
Landing page with one clear CTA + email capture. Example: a single "Start free reconciliation" button above the fold, no distractions.
Record a 30–60s demo video. Example: screen-record a merchant pasting a Paystack CSV and watching it appear live in their Google Sheet, VAT line and all.
Phase 2 — Warm-up (the week before)
Find 5 communities where your users are. Example: Nigerian fintech Slack groups, r/Nigeria, local SMB Facebook groups, Techpoint Africa Discord.
Warm up 20 early users. Example: DM 20 Lagos-based shop owners or freelancers and offer free setup in exchange for honest feedback.
Tease with build-in-public posts. Example: "Our VAT parser now handles kobo-level rounding correctly — this was the hardest part to build."
Phase 3 — Listings (directory backlinks + discovery)
Zarek queued up and wrote copy for 15+ directories: DevHunt, BetaList, SaaSHub, Peerlist Launchpad, AlternativeTo, AppSumo, Startup Stash, and more. Example AppSumo tagline: "Commerce OS for Nigerian Merchants — Paystack + Flutterwave + Monnify → Google Sheets / Xero / QuickBooks, automated."
Phase 4 — Launch day
Product Hunt post (12:01am PT). Example headline: "KoboSync — Real-time payment reconciliation for Nigerian merchants"
Show HN on Hacker News. Example title: "Show HN: I built automated VAT reconciliation for Paystack/Flutterwave/Monnify → accounting"
X/Twitter thread, LinkedIn post, launch email to waitlist — all drafted and timed.
Reddit posts to r/Nigeria, r/smallbusiness, r/fintech — value-first framing.
Phase 5 — Post-launch compounding
YouTube tutorial: "How to reconcile Paystack transactions into QuickBooks in 5 minutes"
Blog posts: "KoboSync vs manual reconciliation", "How Nigerian merchants can automate FIRS VAT tracking"
Short-form clips (Reels/Shorts) of the reconciliation flow in action.
Zarek does all of this — builds the plan, drafts every piece of copy, schedules it, and tracks what's live. It knows Nigerian commerce specifics (kobo fee parsing, FIRS VAT, Naira pricing) because it carries product context across every session.
If you want to see it in action for KoboSync or any of your other projects, feel free to reach out: wangc2016217@gmail.com
bro i'd lose my mind doing that. i can barely balance my own wallet. hope ur tool helps those merchants stop crying over spreadsheets.
i would love to work with you
That's cool, let's connect on twitter, link in my bio
Really like this idea — getting books onto a Kobo wirelessly removes a surprisingly annoying bit of friction. Progress/annotation syncing would make it even more compelling. Nice focused product.
Thanks for your reply. Would definitely look into the Progress/annotation syncing and see how it fits into KoboSync's architecture.
The local payment rails make this really interesting. A lot of tools built for US or European markets probably miss these kinds of details completely.
I also like that you’re solving a very specific pain instead of trying to be another general accounting tool. Since you’re building this solo, have you thought about getting an intern to help with some of the research, testing or merchant outreach? Could free up some time for you to focus on the product itself. SpiderSkill could be useful for finding students looking for this kind of experience.
You are right, a lot of these tools focus on the US and European markets. They don't really know the details of how these local markets work or maybe they care less, and this was one of the biggest factors that influenced my decision in building KoboSync for local merchants over here. And an intern at this point would be very useful for the task you've raised, so thanks for bringing up SpiderSkill, I'll check it out.
The local-market constraint is what makes this particularly interesting; KoboSync isn't just automating bookkeeping, it's dealing with a payment environment that global tools don't fit neatly.
That's right. Thanks for the feedback
Makes sense. I’d be curious to see what you learn once you have more usage across those local payment workflows.
The five to ten hours is the visible cost. The quieter one is that manual matching trains people to trust the gross figure, because fees and VAT stay buried in the processor dashboards. In the finance workbooks I build, the fix that stopped that was one 'settled to bank' number next to gross and fees, so every cut is visible without hand math. On onboarding, the scariest part of OAuth is not knowing what a tool can touch. One plain line before the connect screen, like 'reads transactions, writes only to the sheet you choose,' removes most of the hesitation. Good luck with the merchant cohort.
the duplicate shield is the part I'd want to understand best, since blocking a double-entry automatically means the system decided something on its own with real financial consequences if it's wrong. do merchants ever see what got blocked and why, or is it silent unless they go looking? that's the same tradeoff I keep hitting building something that acts on someone's behalf, full autonomy is faster but a wrong silent call erodes trust way more than a slow correct one
also curious how you validated the fee calculations are actually correct down to the kobo before merchants started trusting the numbers, since that's the kind of thing where one visible mistake probably kills adoption fast in a market this price-sensitive
That is a profound trade off to tackle. When building systems that act on behalf of user's finances, silent autonomy is indeed a trust killer.
Here is a summary of how KoboSync handle all the concerns you raised above. And permit me to use these concerns you've raised as the basis of my next article.
1) The duplicate shield: This part is fully Autonomous, but it is highly visisble. You are 100% correct that blocking a transaction automatically has consequences if the system gets it wrong, and because of this awareness, KoboSync's duplicate shield is never silent. If the system blocks a transaction, it immediately leaves a prominnent trail. There is a webhook inspector built into the merchants dashboard which displays a log of all the merchants payloads that hits KoboSync servers. If a duplicate webhook is fired by a gateway, the merchant can look at this inspector and see the reason why it got blocked. In the transaction history table, a blocked transaction is logged here too with an ignored or blocked status badge next to it, KoboSync also attaches a detailed Agent Note in respect to this action as well. There are also proactive system alerts that gets triggered for example if a merchant uses KoboSync's outbound webhooks to power their own internal systems, the background worker enqueues and broadcasts a dedicated buildTransactionDuplicateEvent ensuring their custom backends are instantly notified that a duplicate was caught and filtered.
2) In a price sensitive market like Nigeria, even a microscopic calculation error will surely destroy adoption. To prove to merchants that the software is accurate down to the Kobo, KoboSync resolves this through both backend arithmetic contraints and frontend validation loops. JavaScript natively uses binary flaoting-point numbers and this means that simple equations like 1.005 * 100 compute as 100.49999999999999 and round down incorrectly to 1.00 instead of 1.01. To keep books perfectly balanced with actual bank statements, KoboSync replaces naive arithmetic with a custom, exponent based roundMoney rounding utility to maintain absolute precision.
PostgreSQL Decimal Prescision is also used in the database schema, all monetary values (gross, fee, net, and VAT) are stored using highly precise decimal types rather than floats or real numbers.
Kobosync also relies heavily on gateway Webhook Truth: To keep calculations foolproof, KoboSync strictly relies on the rawFee reported directly by the gateway payload and only uses manual calculators as a safe channel aware fallbacks.
genuinely didn't expect this level of detail, and yeah, feel free to use the questions for the article, glad they were useful for more than just my own curiosity
the "Agent Note attached to the blocked transaction" detail is the part that stands out most, that's the difference between "the system did something" and "the system explained itself while doing something." most autonomous systems skip that second part because it's more engineering work for no functional benefit, but it's exactly the thing that makes silent autonomy feel less silent
the floating-point rounding bug (1.005 * 100 → 100.49999...) is a great, concrete example of why "just use JS math" fails at scale for anything financial. good reminder that the boring infrastructure choices (decimal types, custom rounding) are usually what actually earns trust, not the flashy agentic parts
This comment was deleted 13 days ago
Thanks for the feedback, I agree on every point you've raised, and surely I will be applying them.