Common Custom Software Mistakes Banks and SACCOs Make — and How to Avoid Them

Mistake 1: Automating the Process You Have Instead of the Process You Need

A SACCO in Mbale approached us after spending six months digitising their loan approval workflow. The digital version mirrored every paper step: the branch manager printed the application, walked it to the credit officer, who walked it to the manager for signature, who walked it back. The only difference — a PDF replaced the paper form.

The problem wasn't the technology. It was that nobody had asked whether the process itself made sense. When we mapped the actual flow, three approval layers existed because of a fraud case from 2019. The risk had been addressed by a new scoring engine, but the approval chain remained.

What to do instead: Before writing a single requirement, map the current state with the people who execute it daily — not just the department head. Ask "why" at every handoff. If the answer is "that's how we've always done it" or "the regulator required it in 2018", verify whether that's still true. The Bank of Uganda's guidelines evolve; your workflow should too.

Mistake 2: Treating Mobile Money Integration as an Afterthought

A microfinance institution in Jinja built a beautiful member portal. Loan applications, savings balances, repayment schedules — all worked perfectly in testing. Then they went live and discovered that 78% of their members repay via mobile money, but the portal only showed "payment received" after manual reconciliation by the finance team each morning.

The integration had been scoped as "Phase 2". Phase 1 launched without it. Members saw outdated balances. Field officers spent hours on WhatsApp confirming payments. The portal became a source of friction rather than trust.

What to do differently: In Uganda's financial sector, mobile money isn't a feature — it's the primary rail. Scope the integration (MTN MoMo, Airtel Money, and any aggregator you use) into the first usable increment. Define the reconciliation logic upfront: real-time callbacks, batch fallback, dispute handling, and what the member sees at each stage. If your vendor treats this as a simple API call, they don't understand the operational reality.

Mistake 3: Building for Today's Regulatory Report, Not Tomorrow's

A commercial bank's compliance team requested a custom regulatory reporting module. The vendor delivered exactly what the current BOU returns required — down to the specific CSV format. Six months later, the central bank introduced a new granularity requirement for agent banking transactions. The module couldn't accommodate it without a rewrite.

Regulatory reporting in Uganda changes. The Data Protection and Privacy Act, the National Payment Systems Act, and BOU circulars all create moving targets. Software that hardcodes today's format becomes technical debt the moment the next circular lands.

How to avoid this: Design reporting as a configurable layer, not hardcoded logic. Separate data collection, transformation, and output. Build a rule engine that compliance officers can adjust without code changes — new fields, new aggregations, new submission schedules. Your vendor should demonstrate how a non-technical user modifies a report definition. If they can't, the solution will age poorly.

Mistake 4: Excluding Branch and Field Staff Until User Acceptance Testing

A SACCO in Gulu commissioned a field officer app for group lending. The project team — IT, credit, and management — designed screens in a Kampala boardroom. Field officers saw the app for the first time during UAT, two weeks before launch. They rejected it: the group meeting workflow required internet connectivity that didn't exist in their parishes; the client search used national ID numbers that members rarely carried; the offline sync logic conflicted with their actual visit sequence.

Two weeks wasn't enough to fix fundamentals. The launch delayed by three months.

The fix: Involve end users from day one. Not as "stakeholders" who sign off requirements, but as co-designers. Shadow a field officer for a full day. Watch how they handle a group meeting with 30 members, intermittent signal, and a dying phone battery. Build the offline-first architecture around that reality. Test prototypes on the devices your staff actually use — not the latest Samsung in the IT lab.

Mistake 5: Underestimating Data Migration and Historical Context

A bank migrating from a legacy core banking system assumed data migration was a technical ETL exercise. They allocated two weeks. Six months later, they were still reconciling discrepancies: loan balances that didn't match because of manual interest adjustments made years ago; dormant accounts with no KYC documents that the new system rejected; guarantor links broken by a branch code restructuring in 2015.

The data wasn't just rows — it carried institutional memory. The migration failed because nobody had documented the "why" behind the exceptions.

Practical approach: Treat migration as a business project, not an IT task. Assign a data steward from each product line (loans, savings, fixed deposits, treasury). Catalogue every exception, workaround, and manual process that touches the legacy data. Build a migration dashboard that shows record counts, exception rates, and reconciliation status by product and branch. Run at least three full dress rehearsals with production-scale data before cutover. Budget time for the business to validate — not just IT to verify row counts.

Mistake 6: Choosing a Vendor Who Builds and Leaves

A Kampala-based NGO SACCO selected the lowest bidder for a member management system. The vendor delivered on time, handed over code and credentials, and became unresponsive. When the SACCO needed to add a new savings product six months later, they couldn't find a developer who understood the codebase. The original vendor had used a proprietary framework with no documentation.

Custom software in financial services isn't a deliverable — it's a capability you need to evolve. BOU circulars change. Product lines expand. Integration points multiply. If your vendor treats handover as the end of the relationship, you own a depreciating asset.

What to look for: A partner who demonstrates phased delivery with working increments every 2–4 weeks, not a big bang at month six. Source code ownership from day one, stored in your repository. Architecture documentation written for developers, not sales decks. A support SLA that covers production incidents, not just "bugs". And critically — a track record of staying with Ugandan clients through regulatory changes and product evolution. Ask for references you can call, not logos on a slide.

Mistake 7: Ignoring the "Last Mile" — Agents, Branches, and Partners

A bank launched a digital onboarding platform that reduced account opening from 45 minutes to 8 minutes — for walk-in customers at the main branch. But 60% of their new accounts came through agents in rural trading centres. Those agents still used paper forms, photographed them, and sent them via WhatsApp to the branch for entry. The digital platform didn't support agent-initiated onboarding, biometric capture on shared devices, or the commission workflow the agents expected.

The "last mile" in Ugandan financial services is often an agent, a field officer, or a partner SACCO — not your own branch staff. If your custom software doesn't serve them, you've digitised only the easy part.

How to address it: Map every channel that originates business for you. Agents. Field officers. Partner SACCOs. Digital lenders you white-label for. Each has distinct constraints: shared devices, intermittent connectivity, different KYC requirements, commission structures. Your software should either support them natively or expose clean APIs so they can build on top. Don't assume they'll adapt to your workflow — design for theirs.

Mistake 8: No Plan for the First 90 Days After Launch

Go-live is treated as the finish line. The project team disbands. The vendor moves to the next client. Three weeks later, the branch in Fort Portal reports that the new loan restructuring workflow crashes when a client has more than three active loans — a scenario that never appeared in test data. The only person who knows the code is on annual leave.

The first 90 days post-launch are when real usage exposes the gaps no test case caught. This is when you need the vendor most, not least.

Structure for success: Negotiate a 90-day hypercare period into the contract. Define response times by severity: production-blocking issues within 2 hours, functional gaps within 24 hours. Assign a product owner on your side who triages feedback from branches and feeds it to the vendor in weekly sprints. Budget for 20–30% of the build cost to cover this period. Track adoption metrics that matter: not logins, but loan applications submitted, accounts opened, reports generated. If adoption stalls, you have a process or training problem — not a software problem.

A Practical Checklist for Your Next Custom Software Initiative

Area	Question to Ask	Red Flag
Process	Have we mapped and challenged the current workflow with frontline staff?	Requirements come only from department heads
Integration	Is mobile money reconciliation in the first increment?	"We'll integrate in Phase 2"
Regulation	Can compliance modify report definitions without code changes?	Hardcoded CSV formats
Users	Have field officers and agents co-designed the workflow?	First user sighting is UAT
Data	Do we have data stewards documenting every exception?	Migration scoped as pure ETL
Vendor	Do they own the code in our repo from day one?	Proprietary framework, no documentation
Channels	Does the solution serve agents and partners, not just branches?	"Agents can use the branch portal"
Launch	Is there a funded 90-day hypercare plan with SLAs?	Vendor disengages at go-live

Moving Forward

Custom software works when it reflects how your institution actually operates — across branches, agents, field officers, and the regulatory environment you navigate daily. The mistakes above aren't theoretical. They're patterns we see repeatedly across Ugandan banks, SACCOs, and microfinance institutions.

The good news: each mistake is avoidable with the right approach and the right partner. Start by mapping your real processes with the people who execute them. Scope mobile money and regulatory flexibility into the first increment. Choose a vendor who stays.

Explore Custom Software & Business Automation →