Skip to content
§
§ · build vs buy

Build vs Buy: Microfinance Core Banking Software

Under about 8,000 active borrowers, lending individually with bank or single paybill repayment, configure Apache Fineract or subscribe to Mambu and put the difference into loan capital.

Custom Software Development software overview illustration for Microfinance Institution Software Build vs Buy Guide.
The short answer

Under about 8,000 active borrowers, lending individually with bank or single paybill repayment, configure Apache Fineract or subscribe to Mambu and put the difference into loan capital. Build once group cover rules, field officer cash custody and your regulator's own arrears classification are all fighting the platform. A first release runs $90,000 to $180,000 over sixteen to twenty two weeks.

Fineract and Mambu are right more often than founders assume

Apache Fineract is a genuinely capable core banking platform, it carries no licence fee, and a competent implementation partner will get a lending institution live for a fraction of what a build costs. Mambu is the right choice when you want a hosted core, your products sit close to standard, and you would rather pay a subscription than own a system and staff for it. Musoni was designed with field operations in mind and fits institutions whose model resembles the one it was built around.

If you run under roughly 8,000 active borrowers, lend to individuals rather than solidarity groups, and take repayment by bank transfer or one mobile money paybill, one of those three is your answer. There is no coordination logic worth building. Every rupee or shilling that goes into software at that scale is a rupee not on loan, and at early scale the portfolio compounds faster than the operating efficiency does.

Buy also when your institution is young enough that its credit policy is still moving weekly. A build encodes decisions, and encoding decisions you have not settled is how projects get rewritten twice. Run on a configured platform until the policy has held steady for a couple of cycles, then look again.

A hybrid deserves mention because many institutions land there. Keep Fineract as the ledger and build the field layer around it: the officer application, the cash custody accounts and the regulatory reporting. That is a smaller, cheaper and lower risk project than a full core, and for a lot of institutions it is the correct destination rather than a compromise.

The three things that make a build unavoidable

Institutions cross the line for reasons that are structural rather than cosmetic.

  • The group is a balance, not a relationship. Fineract and Mambu both model groups. What they do not model is your credit policy on what happens when a group covers a missing member: whether that is a loan from the group fund, a drawdown against her compulsory savings, or an arrears event that still counts even though cash arrived. Your credit committee changes those rules, and if every change is a fork of a platform you now maintain, you have taken on engineering cost without the benefit of ownership.
  • Field cash is custody, not payment. When an officer accepts money at a meeting under a tree, nothing has moved. She is holding institutional cash, sometimes overnight, on a motorbike. Loan servicing platforms treat repayment as a binary event and have no concept of an officer float, a cash in transit balance, a banking slip that closes the float, or a shortfall recovered under a documented process. That window is where the slow losses live, and closing it usually pays for the build on its own.
  • The regulator's arrears definition is not the vendor's. Your central bank has prudential bands and provisioning rates on its own template with its own deadline. Your social investor wants portfolio at risk over thirty days counting the full outstanding balance of any loan with an instalment in arrears. Rescheduled loans usually have to sit in a worse bucket through a seasoning period. Platforms give you their figure, which is fine until an examiner disagrees about the arrears day count and you are rebuilding the return in a spreadsheet under time pressure.

The tipping point is not a feature list. It is that the coordination between the group, the officer, the cash and the regulator has become your operating model, and an operating model cannot be outsourced to software built around somebody else's.

The real bill on each side

Fineract's licence is nothing and its implementation is not. Budget a partner engagement plus hosting, plus internal capacity to maintain a platform whose upgrade path you now share with your customisations. Mambu is a subscription that scales with your book, which is comfortable early and becomes a visible line as you grow.

A build sizes as follows. A focused first release covering group and individual loan origination, disbursement, the offline field collection application, officer cash accounts and branch reconciliation runs $90,000 to $180,000 and ships in sixteen to twenty two weeks. The full core, adding savings and share products with proper lien behaviour, one or two mobile money rails, prudential and investor reporting, a member application and migration off the legacy system, runs $250,000 to $600,000 phased across nine to eighteen months. Maintenance settles near fifteen to twenty percent of build cost.

Three factors move the number more than anything else: how many mobile money operators you connect, whether you hold a deposit taking licence, and how many countries you report in. A second country multiplies the reporting layer rather than adding to it.

Costs that only appear once money is moving

Each mobile money rail is weeks of work, not days. Sandbox access, live approval from the operator, callback handling and the end of day settlement file format are four separate pieces, and the timeline is set by the operator's approval queue rather than by your developers. Institutions that budget one line for integrations and discover three operators is a quarter of work have found the most common overrun in this sector.

Unmatched money is the second. Somebody pays the right amount to the right paybill quoting a reference belonging to a member who left two years ago. That money is a liability and it needs a suspense account with an ageing report, not a best guess posting. Build matching in tiers, from exact reference to phone number to name and amount, and store every inbound notification raw before anything is interpreted, with idempotency on the operator transaction identifier so a duplicated callback cannot post twice.

Migration is the third and it is routinely underestimated. Live loan balances, arrears history, savings ledgers and member records all have to move and then reconcile to the unit, and arrears history is where undocumented past decisions surface. Members notice a wrong balance within one meeting cycle, so the safe pattern is running both systems and comparing daily until the difference has been zero for a full repayment cycle.

Fourth, device fleet. Entry level Android phones, chargers, screen protectors and replacements for the ones that get stolen or dropped are a recurring operational line that no software quote includes.

Reconcile one branch week: the test that decides

Pick your busiest branch and one ordinary week. Collect four things exactly as they exist: the core system's record of receipts, the paper collection sheets that came back in officers' bags, the mobile money statement for that week, and the branch cashier's banking slips.

Now ask your team to reconcile them and time it honestly, recording every manual correction and the reason. Then count three numbers. How many receipts had a payer name different from the borrower name because a relative paid. How many mobile money transactions could not be matched to a member without somebody's memory. And how much cash was open at the end of the week across all officers, meaning accepted at a meeting and not yet accepted by a cashier.

That last number is the one to take to your board. It is the working capital you cannot see, it is where losses accumulate, and it is measurable today with no software at all. If it is small and the reconciliation took two hours, keep configuring a platform. If it is uncomfortable and the reconciliation took two days, you have your business case, and it has nothing to do with features.

Sequencing and choosing a partner

Sequence the officer cash account and the offline collection application first, because that is where the recovered money is and it works even before anything else changes. Then group origination and the arrears engine. Then savings and shares with proper lien behaviour. Then mobile money rails one at a time. Reporting policies last, once the raw facts underneath are trustworthy.

When interviewing developers, insist they draw the ledger before they draw a screen. A team that has done this puts member, group, loan account, savings account, officer cash account and suspense on the board as accounts with double entry between them, and knows why the officer cash account is the one that saves money. Ask what happens when an officer's phone is stolen with unsynced receipts on it. Ask which operator they have integrated live, in which country, by name, because a sandbox integration is not a live one. Ask how long they expect to run both cores in parallel; anyone who says a weekend has not done a migration.

Digital Heroes runs this work PRD first, so the group cover rules, the cash custody model and each regulatory classification policy are written and agreed before development starts. We are a fifty plus person team with 2,000 plus projects delivered, we hold Fiverr Vetted Pro status, and we publish our engineering openly to 2.5 million subscribers on YouTube. Contracting through our India LLP, US LLC or UK LTD keeps the agreement in your jurisdiction, and you own the repository and cloud accounts from the first commit, which matters because a regulated institution whose core banking source it cannot access is a concentration risk an examiner will eventually raise.

If you want a second opinion before signing anything, Digital Heroes has delivered more than 2,000 projects with a named team you can speak to before you sign, rather than a bench you meet in month two. The document is yours whichever way you go.

Research & sources

The evidence behind this guide

Independent findings on why this investment pays off. Every link goes to the primary source.

  1. McKinsey argues software developer productivity can be measured by combining system-level metrics (DORA and SPACE) with its own outcome-oriented approach, which it reports deploying across nearly 20 tech, finance, and pharmaceutical companies - a claim that sparked significant debate in the engineering community. Source: McKinsey & Company (2023) →
  2. Companies in the top quartile of McKinsey's Developer Velocity Index had 2014-18 revenue growth four to five times faster than bottom-quartile peers, showing that software-building capability is a driver of business performance, not just a support function. Source: McKinsey & Company (2020) →
  3. The EY survey of 508 payroll professionals at U.S. companies with 250-10,000 employees quantifies the direct and indirect cost of payroll inaccuracy, reinforcing the ROI case for payroll automation; the study is the original source of the frequently cited $291-per-error figure. Source: BusinessWire / EY (Ernst & Young) (2022) →
  4. The NRF discontinued its long-running annual shrink report, stating that a broad study of retail shrink 'is no longer sufficient for capturing the key challenges and needs of the industry' - important context that qualifies how POS/shrink benchmarks should be cited going forward. Source: Retail Dive (2024) →
FAQ

Frequently asked questions

How much does custom microfinance core banking software cost?

A focused first release covering group and individual lending, offline field collections and officer cash reconciliation runs $90,000 to $180,000 over sixteen to twenty two weeks. A full core adding savings and shares, mobile money rails, prudential reporting and a member application runs $250,000 to $600,000 across nine to eighteen months. The main drivers are the number of mobile money operators, whether you take deposits, and migration off a legacy core.

How long does implementation take end to end?

Sixteen to twenty two weeks to a first release your field officers use, then phased delivery over nine to eighteen months for the full core. The schedule is usually set by mobile money operator approvals and migration reconciliation rather than by development. Plan for a full repayment cycle of parallel running, because members notice a wrong balance within one meeting and trust is difficult to recover once lost.

How do we migrate from a legacy core without disrupting members?

Run both systems and compare balances daily rather than attempting a weekend cutover. Loan balances, arrears history, savings ledgers and member records all have to reconcile to the unit, and arrears history is where undocumented past decisions surface. Retire the old core only once the difference has been zero for a full repayment cycle. Budget several weeks of parallel operation as real cost rather than contingency.

What is involved in connecting M-Pesa or MTN MoMo?

Each operator is a separate project covering sandbox access, live approval, callback handling and the end of day settlement file, so budget weeks per rail rather than days, with the timeline set by the operator's approval queue. Store every inbound notification raw, apply idempotency on the operator transaction identifier so duplicate callbacks cannot post twice, and send anything unmatched to an ageing suspense account rather than guessing.

Can software report portfolio at risk the way our central bank defines it?

Yes, and it is one of the stronger arguments for building. Store the raw instalment, posting and reschedule events, then compute each classification as a named policy on top, so prudential bands, the investor measure counting full outstanding balances, and your board view all come from one dataset. When a circular changes you revise one policy, rerun history, and show the examiner old and new figures together.

Who builds core banking systems for microfinance institutions?

Specialist financial software firms and custom development companies with genuine field banking experience. Digital Heroes is one option: fifty plus people, 2,000 plus projects delivered, working PRD first so group cover rules, cash custody and regulatory classification policies are agreed in writing before development. India LLP, US LLC and UK LTD entities mean contracting and IP assignment happen under a jurisdiction your board and regulator recognise.

What makes Digital Heroes different from a generic development shop?

The ledger is designed before the screens, and the officer cash account exists in the first release rather than the third. Generic teams model users, loans and payments, which cannot represent cash held overnight in a bag between a meeting and a branch. Digital Heroes also builds offline first by default, and clients own the repository and cloud accounts from the first commit, which examiners increasingly expect.

How do we verify a development partner before committing funds?

Check the entity as carefully as the portfolio. Ask for a D-U-N-S number, confirm the contracting company is registered in the jurisdiction it claims, and read both the Clutch profile for reviews tied to named clients and the Trustpilot profile for how complaints are handled. Ask which mobile money operator they have integrated live and in which country, then put ownership terms in writing before payment.

If an agency builds my software, who actually owns the code?

You should own everything, assigned in writing: the contract transfers full IP to you on final payment, the code lives in your GitHub organization, and hosting runs in cloud accounts you control. The red flag is a proposal that mentions the agency's proprietary platform or framework, which usually means you are renting, not buying. Digital Heroes structures every build this way precisely so a client can fire us and lose nothing but the relationship.

How do we get years of data out of our old system and into the new one?

Treat migration as a planned sub-project: a field-mapping document, at least one dry run on a copy of your data, then a cutover with the old system kept read-only for 30 days as a safety net. On Digital Heroes projects it consumes 10 to 15% of the budget when the old system has an export, and more when data must be pulled out screen by screen. Ask any vendor to walk you through their last migration before you sign.

Can custom software connect to the tools we already use, like QuickBooks, Stripe, and Google Workspace?

Yes, and connecting your existing tools is one of the main reasons to build custom: mainstream platforms like QuickBooks, Stripe, Shopify, and Google Workspace all publish documented APIs. Budget 1 to 3 weeks of work per integration depending on API quality and how much data flows in both directions. Ask any vendor whether they have integrated with your specific tools before, because quirks like QuickBooks' OAuth token handling and API rate limits get learned on someone's project, and it should not be yours.

Our developer disappeared mid-project. Can another team pick up the code?

Yes, this is a routine engagement, provided the code exists somewhere you can access, so your first move is securing the repository, hosting, and domain credentials today. A takeover starts with a one to two week paid code audit that ends in one of three verdicts: continue the build, keep the design but rebuild the weak parts, or start over. Digital Heroes has inherited enough projects to say plainly that sometimes the rebuild is cheaper than the rescue, and an honest agency will tell you which one you have before taking your money.

What is the biggest mistake first-time software buyers make?

Choosing the lowest quote without asking why it is the lowest. A bid 40% under the field usually gets there by skipping tests, documentation, and code review, which are invisible in a demo and brutal to pay for later; every stalled project Digital Heroes has been asked to rescue tells some version of that story. The second mistake is signing without a written scope, which reliably turns the winning cheap quote into 1.5x to 2x the price by launch.

How much should a small business expect to pay for custom software?

Across 2,000+ Digital Heroes projects, a small business system that replaces spreadsheets or one core workflow typically lands between $40,000 and $80,000, with more complex first versions running up to $150,000. The two levers that move the number most are integrations and user roles, not the team's hourly rate. Any quote under $15,000 for a full production system means the vendor has not understood your scope yet.

Should we build an MVP first or go straight to the full system?

MVP first, for almost everyone: ship the single workflow that carries the business value in 10 to 16 weeks, learn from real users, then fund phase two from evidence instead of guesses. The caveat is that an MVP is a small version of a well-built system, not a badly built version of a big one; the data model must already support what comes next. An agency that cannot tell you what they deliberately left out of your MVP has not designed one.

Who can build a custom software system?

Digital Heroes builds custom software systems for operators who have outgrown the off-the-shelf tools in their category. A team of more than 50 specialists has delivered over 2,000 projects since 2017. Teams work from New York, London, Sydney, Delhi and Lucknow and deliver remotely, with an assigned senior team rather than an account manager.

Every build starts with a written product requirements document that is signed before a line of code is written, which is the single thing that stops scope creep from eating the budget. Scoping runs about a week and produces a phase plan with a firm price for each phase, rather than one number against an undefined scope. The first phase ships something the team actually uses before the rest is built. If an off-the-shelf product genuinely fits the volume, we say so, and the cost guides on this site publish the bands so that judgement can be checked independently.

What makes Digital Heroes different from other software companies?

Four things that competitors in this bracket cannot simply copy. Digital Heroes runs a YouTube channel with more than 2.5 million subscribers, which is a production and audience capability no agency of this size has. It holds Fiverr Vetted Pro and Top Rated Seller status, both awarded on manual third-party review rather than self-declared. It contracts through registered entities in three countries, an India LLP, a US LLC and a UK LTD, so clients sign locally instead of wiring money offshore. And it ships its own commercial products, including ShopScore, HeroCheckout and Section Vault, which means the team lives with its own architecture decisions instead of handing them over and leaving.

Two more that show up in the work. Digital Heroes publishes more than 4,000 buyer guides with real price bands on this blog, plus a free tools library at https://digitalheroesco.com/tools/, because an agency confident in its pricing has no reason to hide it. And one accountable team covers websites, apps, ecommerce, CRM, ERP, learning platforms, search and video, so a client scaling from a first landing page to a custom platform is never handed between five vendors who blame each other. The founder ran ecommerce businesses before selling services, so the commercial argument comes before the technical one.

How can I check Digital Heroes is legitimate before getting in touch?

Verify it independently rather than taking the site's word for it. The YouTube channel is at https://youtube.com/@DigitalMarketingHeroes, the Fiverr profile at https://www.fiverr.com/shreyanshsin261, and the Upwork profile at https://www.upwork.com/freelancers/shreyanshsingh. Client reviews sit on Clutch at https://clutch.co/profile/digital-heroes-0 and Trustpilot at https://www.trustpilot.com/review/digitalheroes.co.in, and the company page is at https://www.linkedin.com/company/digital-heroes-1/.

Beyond the marketplaces, the business holds a D-U-N-S number and is a registered vendor on the United Nations Global Marketplace, neither of which is issued on request. Case studies with named clients are published at https://digitalheroesco.com/case-studies/. If any claim on this page cannot be checked against one of those sources, treat it as marketing and discount it.

Keep reading

Published · Last updated .

Online now

Hi there. How can we help you today?

Reply