Credit Union Core Banking Platform: Buy Digital Banking, or Build Your Own Service Layer Over Symitar, DNA or KeyStone?
Asset size decides the first cut and a core conversion decides the second.
On this page
Asset size decides the first cut and a core conversion decides the second. Under roughly $200 million in assets, buy: Banno, Alkami or Q2 alongside your core vendor's standard integrations will serve members properly, and a middleware programme at that size is a technology project in search of a problem. The build case appears around $500 million, and it becomes decisive if a core conversion is plausible within five years, because applications written directly against Symitar, DNA or KeyStone all have to be rewritten during the conversion while applications written against your own service layer can be repointed. A first release runs $90,000 to $200,000 over 14 to 20 weeks.
When is off the shelf genuinely the right call here?
Under roughly $200 million in assets, do not build, and be sceptical of anyone who tells you otherwise. Your digital banking provider, whether that is Banno, Alkami, Q2 or your core vendor's own product, plus the standard integrations, will serve members well at that size. A middleware programme would consume the technology budget that belongs in lending staff and branches, and the trade is not close.
Do not rebuild the core itself at any size. Share and loan accounting, teller operations, share draft posting and end of day are difficult work that Jack Henry Symitar, Fiserv DNA, Corelation KeyStone, CU*Answers and Sharetec all do reliably. There is no version of this project where replacing that is a good idea, and any proposal that includes it should end the meeting.
Buy, too, when your gap is a product rather than a data layer. If what you actually want is better online account opening, buy an account opening product and configure it. If what you want is card controls, your card processor probably sells them. Building a service layer in order to deliver one vendor feature is an expensive way to buy a vendor feature, and it is the most common way this category gets mis-scoped.
The honest test before anyone writes a proposal: ask what a member service representative sees at 4:15pm when a member made a transfer at 3:50pm. If the representative's screen, the mobile app and the fraud queue all agree, your estate is coherent and nothing on this page applies yet. At most credit unions above a few hundred million they do not agree, because the app reads a cache, the representative reads the live file and the fraud tool reads last night's extract. There are simply several versions of your member during business hours.
When does a custom build actually pay off?
The signals need to appear together, and the strongest one is not a pain point at all.
You are contemplating a core conversion within five years. This is the argument most boards underweight and it is the one that decides the money. Every application written directly against a core has to be rewritten during the conversion, inside the same window, by the same people. Applications written against your own service layer can be repointed, with the layer absorbing the change. Credit unions that built the layer first describe a conversion as difficult. Those that did not describe it in far stronger terms.
You are above roughly $500 million and adding member facing services faster than your vendor roadmap allows. The commercial layer makes this worse than it looks: core vendors meter access, charge per integration and per transaction, and each new partner triggers a fresh conversation about cost. So credit unions do the rational short term thing and build another nightly extract, and after five years the estate is a core surrounded by seventeen batch jobs, each with its own idea of what a member is.
You carry more than four partner integrations each with a bespoke data path. Six partners later, member data has left the building in six different shapes and nobody can produce a list of what each one holds.
Or you are a credit union service organisation. A shared layer amortises across several institutions, and for a group that individually could not justify $200,000 it is often the only version of this that makes financial sense.
How do they compare on the things that matter in this industry?
- Who owns the contract. Symitar exposes SymXchange, Corelation KeyStone was designed with an interface orientation, Fiserv DNA has its own extension model and CU*Answers provides access paths. The plumbing exists in every case. What does not exist is a stable contract for your organisation that survives a core upgrade or a conversion, and that is the only thing a build actually adds.
- Access economics. Core access is metered and each consumer of member data is a commercial conversation. That is a per connection cost that scales with how many things you want to build, which is a real ceiling rather than a technical one. Start the vendor negotiation before you commission a technical design, because the answer changes the estimate materially.
- Latency of the estate. Digital banking products refresh on their own cadence and your other tools read extracts. Nothing off the shelf makes your representative screen, your app and your fraud queue read the same number at the same moment, because no vendor owns all three.
- Event availability. Real time payments, card authorisations, share draft presentment and member transfers all create moments where something should happen immediately. Products give you notifications on their own terms. An internal event stream makes each new feature a subscriber rather than an integration, which is why the second and third product cost a fraction of the first.
- Partner governance. With bespoke file drops, answering what a given vendor holds is a research exercise. Behind one gateway with scoped credentials, rate limits, field level restrictions and request logging, it is a query, and ending a partner relationship is a configuration change.
- Examination evidence. Attributable logging of every read and write of member data is cheap to design in and expensive to reconstruct, and examination scope routinely reaches into third party technology relationships.
What does total cost of ownership look like at your scale?
From Digital Heroes delivery experience, a focused first release runs $90,000 to $200,000 and ships in 14 to 20 weeks. That covers a real time member and account service layer over your core, an event stream for posted transactions, authentication and authorisation, and one member facing use case actually live. A full platform runs $250,000 to $700,000 phased over 9 to 18 months, adding online membership and account opening, consumer loan application workflow, card controls, alerting, a staff console and a governed partner gateway.
A representative $700 million credit union on hosted Symitar with Banno lands at $164,000 for phase one: $44,000 for the member, relationship, account and balance service over SymXchange, $32,000 for the event stream with change capture and replay, $39,000 for authentication, attributable access logging and an idempotent write path, and the rest across discovery, real time alerting as the live use case, and a staff view reconciling the app and the representative screen.
Note that the idempotency and logging lines, $39,000 together, produce nothing a member will ever see. They are the difference between a layer you can put in front of an examiner and one you quietly stop using after the first duplicate posting.
Running costs are 15 to 20 percent of build cost a year, roughly $25,000 to $33,000 on that release. Your core vendor's access and transaction fees continue and can change at renewal. Your digital banking contract continues, because this layer sits beside it rather than replacing it. Cloud hosting is a few hundred to low thousands of dollars a month depending on event stream retention. The unbudgeted item is examination and audit work: access reviews, vendor oversight evidence and change management records all take staff time every year.
What does the hybrid look like, and when is it the honest answer?
The hybrid is the only sensible shape in this category, and it is worth saying plainly: you are not replacing anything. The core stays, the digital banking provider stays, the card processor stays. What you build is the contract between them and everything you want to add next.
Two decisions keep that hybrid affordable. The first is refusing to model the whole core. You do not need every field on every record. You need members, relationships, accounts, suffixes, balances including holds and available versus actual, transactions and cards, done properly. Everything else waits until a real use case demands it, and most fields never will.
The second is using change capture rather than waiting for a real time push. Reading the transaction file at short intervals is not elegant, but it turns a nightly world into a several minute world, and several minutes is fast enough for balance alerts, fraud rules, round ups, collections holds and courtesy pay decisions. Paying for a premium access tier to get true push is frequently the largest line in a proposal and the least necessary one for the use cases members actually notice. That choice alone can save a quarter of the integration budget.
Then sequence strictly. Phase one is the service layer plus one live member facing outcome, because a build that delivers infrastructure with nothing on top of it gets questioned at the next board meeting, fairly. Phase two is online account opening and loan workflow at $90,000 to $180,000, which is where the return compounds because a recovered application is directly measurable in a way infrastructure never is. Phase three is the partner gateway and card controls at $60,000 to $140,000. The staff console comes last, because internal tooling is where scope grows fastest.
Which should you choose, by operator size and stage?
Under $200 million in assets: buy. Banno, Alkami or Q2 with your core vendor's standard integrations, and put the difference into lending staff and branches. Nothing else here applies yet.
Between $200 million and $500 million, no conversion in view: buy, then measure one thing. Add up your per integration and per connection fees, the internal hours maintaining nightly extracts, and the member facing feature you wanted last year and did not ship. If that total is small, keep configuring. If it has become a permanent staffing line, you are already paying for the build.
Above $500 million, adding services faster than the roadmap allows, or carrying four or more bespoke partner data paths: build the first release. Service layer, event stream, idempotent writes, attributable logging and one live use case, at $90,000 to $200,000.
Any credit union with a plausible core conversion inside five years, at any size above the $200 million floor: build the layer first. Put the cost of rewriting every existing integration into the comparison, because it usually exceeds the entire build and it lands in the same eighteen months as everything else.
A credit union service organisation serving several institutions: build, and accept that the first release costs roughly a third more because data segregation, per institution configuration and per institution reporting touch every design decision. Against that, support becomes a real function answering to several boards, and the platform amortises in a way no single institution build ever does.
If you want that decision made properly rather than quickly, 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. Nothing about that commits you to the build.
The evidence behind this guide
Independent findings on why this investment pays off. Every link goes to the primary source.
- An independent Forrester Total Economic Impact study of OutSystems found a 363% three-year ROI with payback in under 6 months, illustrating that faster, lower-labor build approaches can materially shift the payback math. Source: Forrester Consulting (commissioned by OutSystems) (2024) →
- Senior executives report the highest average compensation among developer roles (e.g., $225K median in the US), and reported salary bands shifted downward year-over-year ($60-75K vs. $70-85K in 2023), underscoring how compensation varies sharply by role and location. Source: Stack Overflow (2024) →
- 88% of organizations are concerned about employee retention, and providing learning opportunities is respondents' #1 retention strategy; career progress is cited as people's top motivation to learn, yet only 36% of organizations qualify as 'career development champions.'. Source: LinkedIn Learning (2025) →
- 73% of surveyed businesses now use a headless architecture (up nearly 40% since 2019), and 98% of those not yet using it are evaluating or planning to evaluate headless within 12 months, with 82% saying it makes delivering consistent content easier. Source: WP Engine (2024) →
Frequently asked questions
What does it cost to leave our core later if we build a layer first?
Far less, and that is the strongest financial argument in this category. Applications written directly against a core all have to be rewritten during a conversion, inside the same window, by the same people. Applications written against your own service layer can be repointed, with the layer absorbing the change.
Put the cost of rewriting every existing integration into your comparison before you decide. For most credit unions above $500 million that single line exceeds the entire build, which is why we push the layer ahead of a conversion rather than after it.
What happens if our core vendor changes its access or transaction pricing?
Model it against how many consumers of member data you expect rather than today's invoice, because access is metered per integration and per transaction and that is what scales. Start the commercial negotiation before you commission a technical design, since the answer changes the estimate materially.
A layer does not remove the fees. What it changes is that your member model, your event stream and your partner governance live in software you own, so a repricing becomes a commercial decision rather than a hostage situation. Settle repository and cloud account ownership in writing before kickoff.
How long until members see anything from a middleware build?
Fourteen to twenty weeks for a first release, and that release should deliberately include one live member facing use case, usually real time balance and transaction alerting. A service layer with nothing running on it is very hard to defend at a board meeting.
Online account opening and loan workflow are phase two and typically land three to six months after that. Milestone the contract against demonstrable behaviour rather than dates: a correct member relationship set returned, a day of postings replayed without gaps, a write path proved idempotent under forced timeout, then the use case live.
Is this cheaper than adding features through Banno or Alkami?
It is not a substitute and any comparison framing it that way is misleading, because you keep your digital banking provider either way. What the layer changes is the cost of everything the provider's roadmap does not cover, and the cost of each new partner relationship.
Count your current per integration and per connection fees, the internal hours maintaining nightly extracts, and the features you wanted and did not ship. If that total is small, buy and configure. If it is a permanent staffing line, build.
Can we build real time services if our core only runs a nightly cycle?
Yes, and this is where most of the perceived cost disappears. Change capture against the transaction file at short intervals turns a nightly world into a several minute world, which is fast enough for balance alerts, fraud rules, round ups, collections holds and courtesy pay decisions.
It is not elegant. What matters is that once an internal event stream exists, each additional feature becomes a subscriber rather than a new integration, which is why the second and third product cost a fraction of the first. Waiting for a vendor to deliver true push is usually the most expensive line in a proposal.
How do you avoid duplicate postings when the core is unavailable?
Every write operation needs to be idempotent with a client generated key, so a retry after a timeout cannot post twice, and member initiated actions during the end of day window should be queued with a status the member can see rather than silently retried.
This sounds like a detail and is not. Duplicated postings against member accounts damage trust fastest and take longest to unwind, and they are the failure that ends projects. Ask any prospective developer how they handle it before you discuss features at all.
What does examination readiness add to the budget?
Roughly $15,000 to $25,000 inside a first release if it is designed in, covering attributable logging of every read and write of member data, documented access controls, a record of what each integration can see, and change management evidence.
Retrofitting the same thing after an examiner asks costs several times that, because you have to reconstruct history you never captured. National Credit Union Administration examination scope routinely reaches into third party technology relationships, so this is the clearest example here of a line that is cheap in week two and expensive in month twenty.
Does building as a credit union service organisation change the economics?
Substantially, in both directions. The first release costs roughly a third more because every decision becomes multi tenant: data segregation, per institution product configuration and per institution reporting all touch the design. Support also becomes a genuine function, because you are answering to several boards rather than one.
Against that, the build amortises across participating institutions and each additional credit union onboards against a layer that already exists. For a group of mid sized credit unions that individually could not justify $200,000, a shared platform is often the only version of this that makes financial sense.
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.
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.
What happens to my software if the agency shuts down or we stop working together?
Nothing dramatic, if the engagement was set up correctly: the code sits in your repository, hosting runs on your cloud account, and a handover document explains how to deploy and operate the system. Any competent replacement team can then take over in days rather than months. If the agency controls the repo, the servers, or the domain, fix that now, because renegotiating access during a dispute is the most expensive place to discover the problem.
Is it cheaper to customize Salesforce than to build a custom CRM from scratch?
If you use less than a third of what Salesforce does, a custom CRM is often cheaper by year three. Salesforce Enterprise lists at $165 per user per month, so 25 seats cost about $49,500 a year before admin and consultant fees, while a focused custom CRM runs $60,000 to $100,000 once plus 15 to 20% a year in maintenance. If you genuinely need Salesforce's ecosystem, reporting, and app marketplace, customizing it beats rebuilding it; the mistake is paying enterprise prices to use it as a glorified contact list.
If we build for 20 users now, will the software cope with 500 later?
It should, without a rewrite, if it was built on a standard cloud stack; going from 20 to 500 users is mostly a hosting configuration change costing hundreds a month, not a second project. What actually breaks under growth is sloppier work: database queries never indexed for volume and features designed assuming one office's worth of data. Before signing, ask the vendor what happens to the system at ten times today's data, and listen for a specific answer.
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 is a discovery phase, and is it worth paying for separately?
Pay for it, and treat the output as yours. A discovery phase runs two to three weeks, typically 5 to 10% of the eventual build budget, and produces a written scope, wireframes, and a fixed quote you can take to any vendor, including a competitor of the agency that wrote it. Skipping it is how projects end up quoted from a two-paragraph email and delivered at twice the price.
What happens if I stop paying for maintenance after launch?
Nothing breaks on day one, which is what makes it dangerous. Within 6 to 18 months, unpatched dependencies accumulate known vulnerabilities, an integrated API like Stripe ships a breaking change, and the first fix requires a developer to relearn a stale codebase at full price. Budget 15 to 20% of the build cost per year for upkeep; it is the difference between a $500 patch and a $15,000 emergency.
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 .
