Cash and Voucher Assistance Platforms: Build or Buy, and the Two Features That Decide It
The threshold is roughly 20,000 households moving through more than one implementing partner.
On this page
The threshold is roughly 20,000 households moving through more than one implementing partner. Below that, in a single response with one payment partner and no cross agency deduplication requirement, buy: RedRose or Last Mile Mobile Solutions will get you registering and paying quickly and the money belongs in the transfer value. Above it, when duplicates are a live disagreement between organisations and reconciliation happens by exporting operator statements into spreadsheets, a first release at $90,000 to $180,000 over 14 to 20 weeks starts to earn its place. Most agencies reading this are somewhere in between and should buy the platform while building only the two things no product handles for them: idempotent payment handling and privacy preserving matching across partners.
When is off the shelf genuinely the right call here?
If you are running a single response with fewer than about 5,000 households, one payment partner and no requirement to deduplicate against another organisation caseload, buy. RedRose covers registration through payment and has been used at scale. Last Mile Mobile Solutions was built inside a large operational agency and is genuinely designed for field conditions and offline enrolment. Segovia was built around payment orchestration and has real strengths in getting instruction files to operators. Any of the three will get assistance moving faster than a build can.
Speed is the argument, and it is the strongest one in this sector. A slow build during an acute onset response is a failure whatever the code quality, because the measure is whether households received money in the window when it mattered. The delay is paid by people rather than by a budget line.
There is a second reason to buy that has nothing to do with caseload. Funding here is annual and teams rotate. A build has to remain affordable in a year where a grant does not renew, and if the ongoing figure cannot be covered from indirect cost recovery on a bad year, buy instead and revisit when the funding base is steadier. An unmaintained platform holding beneficiary data is worse than a subscription you can cancel.
And buy if what you need is payment orchestration rather than programme management. If registration already works and the pain is getting instruction files to three operators reliably, that is a narrower problem than a platform.
When does a custom build actually pay off?
Two features justify a build in this sector. Everything else is configuration. The first is idempotent payment handling, meaning a deterministic key derived from beneficiary, tranche and attempt, applied when the instruction is created rather than checked afterwards. That makes double payment structurally impossible instead of dependent on somebody remembering to filter a resubmission at three in the morning during a partial failure. The second is cross agency matching, meaning a privacy preserving layer where partners exchange salted hashed identifiers rather than names and numbers in the clear, with a human review queue for near matches.
Those two exist because of how the failures actually happen. In the cash and voucher work we have delivered, three recur: duplicates discovered after payment, failed transactions reissued without a reliable idempotency check, and a donor report that cannot be traced back to named beneficiaries without a week of manual work. The first two cost money directly. The third costs the next grant, which is a larger number than the whole platform.
The build case is live when two or more of these hold. You operate across a consortium and duplicates are a live disagreement rather than a theoretical one. You run in more than one country with different expenditure baskets and identity regimes. Your reconciliation happens by exporting operator statements into Excel. Your entitlement formula has been revised more than once and you cannot reproduce which version paid which tranche. Or a donor has already raised a finding on traceability.
A first release covering offline household registration, versioned composition, an entitlement engine with effective dated formulas, deduplication with a partner matching layer, and payment instruction generation with reconciliation runs $90,000 to $180,000 in 14 to 20 weeks in Digital Heroes delivery experience. A full platform adding multi country configuration, vulnerability scoring, electronic voucher redemption, grievance handling, sanctions screening workflow and donor tranche reporting runs $250,000 to $600,000 phased over 9 to 15 months.
How do they compare on the things that matter in this industry?
Reissue behaviour. This is the question to ask in every demonstration, and the answer should come immediately. What happens when a batch is resubmitted after a partial failure. A correct answer involves a deterministic idempotency key and an explicit unknown status that is never treated as failure until reconciled against the settlement report. An answer that involves checking for existing payments before sending is a check rather than a guarantee. If a demonstration spends forty minutes on dashboards and four on this, you are watching the wrong demonstration.
Deduplication across organisations. Inside one agency this is difficult. Across agencies it is a coordination problem wrapped in a data protection problem, because the duplicate you need to catch sits in somebody else list and you cannot pool beneficiary data in a displacement setting. Products can deduplicate their own tenant. Matching without sharing personal data is a design that has to be agreed between organisations, and the engineering is the cheap half.
Entitlement versioning. Transfer values derive from a minimum expenditure basket that gets revised when prices or the exchange rate move, and household composition changes between tranches. Ask whether revising the formula in March corrupts February records, and whether each payment stores the formula version and the composition snapshot that produced it. That is what makes a donor question answerable in one query.
Device data scope. Offline enrolment is a protection decision before it is a sync problem. A tablet carrying a full beneficiary list through a checkpoint is a hazard. The test is whether a device holds only the caseload assigned to that enumerator for that period, encrypted at rest, with remote revocation that has actually been tested.
Exit and residency. Beneficiary data should never sit in a tenant you cannot leave, and several operating contexts carry data residency requirements that constrain where it can be hosted at all.
What does total cost of ownership look like at your scale?
Take an agency moving cash to about 50,000 households in one country through a single mobile money operator, inside a consortium of three implementing partners. The registration to payment core lands around $155,000 over about eighteen weeks. Phase two, adding an agent network as a second payment partner, multi country configuration, vulnerability scoring, electronic voucher redemption, grievance handling, screening workflow and donor tranche reporting, adds about $245,000. Programme total $400,000 across roughly thirteen months.
Household count is not what moves that number. Payment partner count is. Budget $28,000 to $40,000 per additional operator or bank for file format, status code mapping, settlement report ingestion and test environment access, and $40,000 to $60,000 for the first additional country. Paying 50,000 households through one operator is a smaller build than paying 8,000 through three.
Running cost stacks rather than sits in one line. Support and enhancement at 15 to 20 percent of build, so $60,000 to $80,000 on a $400,000 programme. Then $7,000 to $18,000 per payment partner per year for interface upkeep, because operators change formats, status codes and settlement timing and a drifting interface produces payments you cannot reconcile rather than payments that fail visibly. Then $12,000 to $35,000 for the device fleet, since tablets are consumables in field conditions. Then $10,000 to $30,000 for hosting that may have to sit in a specific region. Then $10,000 to $25,000 for recurring independent security testing, because a system holding beneficiary data should be tested by people other than those who built it.
On the buy side, pull the agreement and read what it scales on. Pricing in this sector commonly tracks beneficiary numbers, programme count or deployment, which means the line grows exactly when your caseload grows and your budget is already stretched. Model it against your expected caseload three years out, and check whether a new country or a new payment partner sits inside the fee or beside it.
What does the hybrid look like, and when is it the honest answer?
For most agencies between 5,000 and 40,000 households, the hybrid is the right answer. Keep the platform for the parts that are genuinely commodity: household registration forms, offline enrolment, media capture, case lists, basic reporting. Build the two things that decide whether money goes to the right people once, which are the two things a shared product has no reason to hold on your behalf.
In practice that is a payment instruction layer sitting between the platform and the operators, generating instructions with deterministic idempotency keys, ingesting operator responses as structured statuses with an explicit unknown state, and reconciling against the settlement report on a schedule with an owned unmatched queue. Alongside it, a matching service that exchanges salted hashed identifiers with partner organisations and feeds candidate pairs into a human review queue.
That is a much smaller commitment than a platform and it carries the highest return. It also survives a change of platform, which matters when funding is annual and a consortium lead may switch tooling between grants.
One design rule if you take this route. Build the matching layer with the intention of switching it on for one partner first, and run it in review mode for a full tranche before it influences any exclusion. Let it produce candidates, have programme staff resolve them, and measure how often it was right. A wrongly excluded household is a protection incident rather than a data quality issue, and that distinction belongs in the workflow rather than in a policy document.
Which should you choose, by operator size and stage?
Under 5,000 households, single response, one payment partner. Buy. RedRose or Last Mile Mobile Solutions, deployed this month. The build case does not exist and the delay is paid by households.
5,000 to 20,000 households, one country, one operator. Buy, and add discipline rather than software. Agree the entitlement formula and its effective dates in writing, and insist your operator supplies the settlement report format, which is the half people forget to request.
20,000 households and up inside a consortium. Hybrid. Keep the registration platform, build the payment instruction layer and the partner matching service. This is the largest group and the case is usually easy once someone prices a duplicate discovered after payment.
Multi country, multiple payment partners, recurring programmes. Build the full platform, phased. Start the operator conversation in week one even though the integration ships in week fourteen, because operators control test environment access and that calendar is the most common cause of a missed date.
Acute onset, first ninety days. Buy, without exception, and reassess at the transition to a protracted response rather than in week three.
Any size where a donor requires biometrics. Neither, until there is a documented risk assessment and a data minimisation design. Biometric enrolment creates a permanent, non revocable identifier held about people who often cannot meaningfully refuse, and token or card identity with strong deduplication solves most of the same operational problem.
If you would rather scope this before committing budget, Digital Heroes writes a product requirements document before any code exists, so the scope is fixed and priced rather than discovered later at a day rate. You keep the specification either way.
The evidence behind this guide
Independent findings on why this investment pays off. Every link goes to the primary source.
- 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) →
- Across more than 5,400 IT projects studied by McKinsey and the University of Oxford BT Centre, large IT projects ran on average 45% over budget and 7% over schedule while delivering 56% less value than predicted. Source: McKinsey & Company / University of Oxford (BT Centre for Major Programme Management) (2012) →
- PMI's Pulse of the Profession research found organizations waste an average of roughly 9.9% of every dollar invested in projects due to poor performance - equivalent to about $1 million wasted every 20 seconds collectively worldwide. Source: Project Management Institute (PMI) (2018) →
- Qualtrics research (Q3 2023 survey of ~28,400 consumers across 26 countries) estimated bad customer experiences put roughly $3.7 trillion in global revenue at risk annually, a 19% jump from the prior year's $3.1 trillion; 64% of customers say they will switch companies over poor service regardless of how much they like the product. Source: Qualtrics XM Institute (via Forbes) (2024) →
Frequently asked questions
At what caseload does building beat buying a cash transfer platform?
Around 20,000 households is the usual line, but caseload is a weak proxy. The real test is whether you need to deduplicate against another organisation and whether reconciliation currently happens in a spreadsheet. A 60,000 household programme in one country through one operator with no consortium requirement can stay on a product indefinitely. A 12,000 household programme across three partners where duplicates are a live disagreement cannot.
Payment partner count matters more than household count for cost too. Paying 50,000 households through one operator is a smaller build than paying 8,000 through three.
Is RedRose or Last Mile Mobile Solutions enough for our programme?
For a single response under roughly 5,000 households with one payment partner, yes, and building your own would delay assistance for no operational gain. RedRose covers registration through payment and has been used at scale. Last Mile Mobile Solutions was built inside a large operational agency and is designed for field conditions and offline enrolment.
They become a poor fit when deduplication has to happen without sharing raw personal data between organisations, when you run several countries with different expenditure baskets and identity regimes, or when you cannot reproduce which entitlement formula version paid which tranche.
What does it cost to switch off a platform once beneficiary data is in it?
The engineering is usually manageable and the governance is not. Budget for a full export of household records, composition history, entitlement decisions and payment status in a structure you can actually load, then a reconciliation period where both systems hold the same caseload while you prove the numbers match before the next tranche.
The larger cost is the data protection work. Moving beneficiary data between systems needs a documented basis, a retention decision on the old tenant and evidence that deletion actually happened. Settle that with your legal and compliance function before the migration rather than during it, and never plan a switch inside a payment cycle.
What if the platform changes its pricing at renewal?
This is worth modelling before you commit rather than after. Pricing in this sector commonly scales on beneficiary numbers, programme count or deployment, so the line grows exactly when your caseload grows and your budget is most stretched. Model the fee against your expected caseload three years out and confirm in writing whether a new country or a new payment partner sits inside the fee or beside it.
Owning the payment instruction layer changes your position at renewal, because the part that carries the most risk is no longer inside the agreement you are renegotiating.
How long does a build take before the first household is paid?
Fourteen to twenty weeks for a first release covering one country, one programme model and one payment partner. The schedule risk is rarely software. It is programme leadership agreeing the entitlement formula, the payment partner supplying an integration specification and a test environment, and consortium partners settling the deduplication agreement.
Start all three conversations in week one even though the operator integration ships around week fourteen. Ask for the settlement report format at the same time as the instruction format, because reconciliation is the half people forget to request and it is the half that stops duplicates.
Can we keep the platform and build only the payment layer?
Yes, and for most agencies between 5,000 and 40,000 households that is what we would argue for. Keep registration, offline enrolment and case lists where they are. Build a payment instruction layer that generates instructions with deterministic idempotency keys, ingests operator responses as structured statuses with an explicit unknown state, and reconciles against the settlement report on a schedule with an owned unmatched queue.
Add the partner matching service beside it if you work in a consortium. Together those two are a fraction of a full platform and they carry most of the return, and they survive a change of platform between grants.
How much does cross agency deduplication add to a build?
About $37,000 in our worked example, covering deduplication inside your own caseload plus a privacy preserving layer that exchanges salted hashed identifiers derived from a jointly agreed key set, with a human review queue for near matches. Fuzzy matching across transliteration variants earns its place here because exact comparison misses those pairs.
The engineering is contained. The calendar cost sits in agreeing the key set, the governance and the data protection position between organisations, so start that conversation before you scope the build rather than after.
Should biometrics change the build or buy decision?
It should stop the decision until there is a documented risk assessment and a data minimisation design. Biometric enrolment creates a permanent, non revocable identifier held about people who often cannot meaningfully refuse, and the field failure modes include worn fingerprints, poor capture in bright sun and dependence on a specific device.
Token or card identity with a strong deduplication layer solves most of the same operational problem with far less protection risk and far less build. If a donor requires biometrics, expect the compliance and testing overhead to exceed the enrolment feature itself, on either side of the build or buy line.
Will custom software work with the tools we already use, like QuickBooks and Stripe?
Yes, and this is one of custom software's genuine advantages: QuickBooks, Stripe, Shopify, and most mainstream business tools publish documented APIs built for exactly this. Expect each standard integration to add one to two weeks of build time, and be suspicious of any quote that lists five integrations without asking what data flows in which direction. The hard cases are legacy systems with no API, which is a question to raise in discovery, not in week nine.
Can I build my product on a no-code tool like Bubble instead of hiring developers?
For testing whether anyone wants the product, yes, and Bubble's paid plans start at $29 a month, which is the cheapest validation you will ever buy. The ceiling arrives with complex data relationships, heavy integrations, performance at a few thousand users, and the fact that you cannot export a Bubble app to servers you control. A path many Digital Heroes clients take: prove demand on no-code, then rebuild custom once revenue justifies it, treating the no-code version as a paid prototype rather than a foundation.
How many SaaS seats do we need before building custom becomes cheaper?
The crossover usually shows up between 20 and 50 seats on premium tiers. Salesforce Enterprise lists at $165 per user per month, so 40 users cost about $79,000 a year in subscriptions, which is real money against a custom system you would own outright. Run the comparison over three years: if subscription spend beats the build cost plus 15-20% annual maintenance, custom wins on price before you even count workflow fit.
How much should a small business budget for its first custom app or website?
For a focused first build, most small businesses land between $8,000 and $60,000: roughly $8,000 to $45,000 for a custom website and $25,000 to $60,000 for an internal tool or simple web app, based on Digital Heroes delivery across 2,000+ projects. Customer-facing products with payments, logins, or a mobile app start around $40,000. Quotes far below these bands usually mean a template with your logo on it, not software shaped around your workflow.
What should I have ready before I contact a development agency?
Three things, none of them technical: a one-page description of the problem in your own words, a list of the tools and spreadsheets the new system must replace or connect to, and a must-have versus nice-to-have split of features. Add a budget range, even a wide one, because it changes the conversation from fantasy to engineering. You do not need a formal specification; producing that is what a discovery phase is for.
How long does it take from first call to software my team can actually use?
Plan for four to six months: two to three weeks of discovery, two to four weeks of design, then a 10 to 16 week build with testing. In Digital Heroes delivery experience the schedule killer is not engineering speed but decision lag; a client who takes two weeks to approve wireframes adds two weeks to launch. Book a weekly 30-minute decision slot before kickoff and most of that risk disappears.
We run everything on spreadsheets and Airtable. How do we know it's time for custom software?
The reliable signals are re-typing the same data into multiple tools, one employee acting as human middleware between systems, and errors appearing in handoffs between teams. Hard limits force the issue too: Airtable's Team plan caps at 50,000 records per base, and Business costs $45 per seat per month, so a 20-person team pays about $10,800 a year for a tool it has already outgrown. When workarounds consume more hours than the tools save, the spreadsheet era is over.
Does the tech stack matter, and which one should I ask for?
It matters less than agencies imply, provided it is boring. A mainstream stack, something like React or Next.js on the front end, Node.js or Python behind it, and PostgreSQL for data, means thousands of developers can maintain your system if you ever change vendors. Apply one test: ask how hard it would be to hire a replacement developer for the proposed stack, and walk away from anything built on an agency's in-house framework.
Couldn't I just build my app in Bubble or another no-code tool instead of hiring an agency?
For validating an idea with real users, yes, and we tell clients that honestly. The walls come later: Bubble apps cannot be exported as code to run anywhere else, performance drops on complex data operations, and usage-based pricing climbs as you grow. A meaningful share of Digital Heroes custom builds are rebuilds of no-code MVPs that proved the business worked, which is the system operating as intended: validate cheap, then build the version that scales.
How do I make sure custom software is secure and compliant with rules like HIPAA?
Start with the baseline every business system should have: encryption in transit and at rest, role-based access control, and audit logs. If HIPAA applies, the hosting provider must sign a Business Associate Agreement, which AWS, Azure, and Google Cloud all offer, and access controls have to be designed in from day one, not bolted on. SOC 2 certifies a company's operating practices, not a codebase, so ask vendors what they have shipped in your regulated domain rather than which logos are on their website.
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.
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.
Related guides
Published · Last updated .
