CMBS and Commercial Mortgage Servicing: Keep STRATEGY, and Build Only the Shadow Layer
Trust count decides this, not loan count. If you hold a few hundred straightforward whole loans on your own balance sheet with no securitised reporting obligation, buy a servicing system, keep disciplined workbooks, and spend nothing on custom software.
On this page
Trust count decides this, not loan count. If you hold a few hundred straightforward whole loans on your own balance sheet with no securitised reporting obligation, buy a servicing system, keep disciplined workbooks, and spend nothing on custom software. If you report into several trusts, act as master servicer, or allocate whole loans split across securitisations in a spreadsheet, build. Either way you keep the servicing system: what you build sits beside it and replaces the shadow layer, never the system of record.
When is off the shelf genuinely the right call here?
McCracken STRATEGY is the system of record across most of this market and it earns that position. Payment processing, escrow administration, investor accounting and the general ledger are exactly what it should be doing, and SS and C Precision LM occupies similar ground with different strengths on loan accounting. Backshop is genuinely strong on origination and asset management workflow, particularly for debt funds and life companies underwriting their own paper, and for some operators it removes part of the case for building at all.
Buy or outsource, and stop reading here, if this describes you:
- A few hundred whole loans held on your own balance sheet.
- No securitised reporting obligation, so no monthly determination date and no investor package.
- A book originated by one lender to one credit template, so debt service coverage means the same thing on every deal.
- One competent analyst who normalises borrower financials inside the quarter without heroics.
- No reserve draw administration beyond tax and insurance escrow.
We say this to life company and bank clients regularly. At that shape a servicing system plus workbooks plus a good analyst is genuinely enough, and a build would be an expensive way to organise a manageable problem. There is a second thing nobody should build at any size: the payment and escrow engine. Ripping out a working servicing system buys you nothing and costs a year.
When does a custom build actually pay off?
Commercial servicing does not scale the way residential servicing does, because every loan is a negotiated document and the document is the specification. Two loans on identical office buildings in the same submarket, closed three months apart by the same lender, will define coverage differently, deduct different reserves and trigger cash management on different tests. There is no standard product to configure against.
Build when two or more of these hold:
- Your covenant math lives in a workbook per deal and only one person can explain it.
- You report into multiple trusts, or you are a master servicer with sub servicers feeding you.
- Borrower financial normalisation consumes weeks of analyst time each quarter and still runs late.
- You hold whole loans split pari passu across securitisations and allocate them in a spreadsheet nobody re derives.
- Your process for producing the reporting package cannot survive a servicing criteria attestation without a heroic individual.
That last one is a control weakness dressed up as a good employee, and it becomes a real number the day they resign. The workbook per deal is the same problem earlier in its life. Both are the reason the covenant engine, at around $46,000 in a typical build, matters more on the budget sheet than it looks.
How do they compare on the things that matter in this industry?
Covenant definitions as data. Ask any vendor or developer to represent a debt service coverage test. If the answer is a dropdown of standard calculation methods, they have not read a loan agreement. One deal uses net operating income, another net cash flow after a stated replacement reserve, another imposes a management fee floor the borrower does not actually pay, and the period basis can be trailing twelve months, annualised quarter or year to date annualised. That belongs in a structured definition per loan with components, deductions, period basis, threshold and cure terms.
Borrower document intake. Operating statements arrive as a property manager export, an owner spreadsheet with a bespoke chart of accounts, a scanned document and a rent roll with merged cells and a totals row in the middle. Extraction with an analyst confirming moves the team from typing to reviewing, which is what makes the quarterly cycle fit inside the quarter. Ask what accuracy was achieved on real files rather than clean samples.
The data model. Someone experienced draws property, then loan, then note, then trust, and immediately asks how a whole loan splits across notes and how intercreditor terms govern allocation. Someone who draws loans and payments has built consumer lending software, and you will discover it in month five.
Reproducibility. Every generated package should be reproducible from stored inputs, with an audit trail showing who confirmed which normalisation and which inputs produced each computed test. Retrofitting that costs several times what designing it in costs, and it is what your accountants test against during attestation.
Ownership of the abstracts. The structured loan abstracts represent the work of reading every document. They are arguably worth more than the code, and they should be in your name from the start.
What does total cost of ownership look like at your scale?
On the build side, from Digital Heroes delivery experience, a first release runs $120,000 to $250,000 over 14 to 20 weeks: borrower financial intake with extraction and normalisation, the per loan covenant definition engine, watchlist rules with variance flags, and generation of the investor reporting package with validation run before submission. A full platform adding reserve and draw administration, cash management triggers, whole loan and trust allocations, advancing with recoverability tracking, a borrower portal and investor distribution runs $300,000 to $700,000 phased over 9 to 18 months.
A worked example: a servicer with about 180 loans reporting into four trusts, a mixed book from several originators, keeping the incumbent as system of record. Discovery and data model $16,000, borrower financial intake with extraction and normalisation review $52,000, the covenant definition engine $46,000, watchlist rules and variance flags $18,000, package generation with validation $44,000, and read integration with the system of record $21,000. That is $197,000 of software in nineteen weeks.
The line that surprises people sits outside the software number. Document abstraction is legal and asset management work, not engineering, and it is on the critical path. In that engagement the client's own counsel priced it at $600 a loan, so 180 loans came to $108,000 phased across three waves. The programme as approved was $305,000, of which just over a third was legal work. Any proposal that buries abstraction inside a software figure is understating what you are committing to.
After go live, servicers budget 16 to 22 percent of build cost per year, roughly $32,000 to $43,000 on a $197,000 build, covering hosting, support, extraction maintenance when borrowers change property managers or chart of accounts, template changes when reporting formats are revised, and audit trail storage for years rather than months. Abstraction of newly boarded loans sits on top and is driven by your origination volume rather than by the software.
On the buy side, the comparison is unusual because you are not replacing the servicing system. Price the shadow layer instead: analyst days normalising borrower financials each quarter, days assembling and checking the package each month, and the single person dependency on covenant math.
What does the hybrid look like, and when is it the honest answer?
The hybrid is the answer here for essentially everyone who builds, and framing it correctly is what keeps the number near $197,000 rather than near $700,000.
- Keep the system of record. Payment processing, escrow administration, investor accounting and the general ledger stay exactly where they are. Read from it rather than replacing it, at around $21,000 of integration.
- Build only what is specific to your documents. Covenant definitions, borrower financial normalisation, reserve conditions, trust allocations and package generation. These are not product features anyone can sell you, because they are your loan agreements expressed as executable rules.
- Sequence extraction and package generation first. Together they were $96,000 of the worked example, roughly half the software, and they are what turn a multi day monthly assembly exercise into a generated artefact.
Two further choices keep the cost down. Start with the loans generating the most reporting pain rather than the whole book, because a covenant engine proven on eighty conduit loans configures the next two hundred quickly. And abstract in waves sequenced by reporting obligation and risk, so legal spend follows the same phasing as the software rather than arriving as one bill at the start.
Which should you choose, by operator size and stage?
- Life company or bank, a few hundred balance sheet whole loans, no securitised reporting. Buy a servicing system and keep workbooks. Do not build. We would tell you that on the call.
- Debt fund originating its own paper, growing, no trusts yet. Look at Backshop before commissioning anything. Origination and asset management workflow is a product problem, not a bespoke one, at that stage.
- Servicer reporting into one or two trusts with a book from one originator. Borderline. Abstract twenty loans first as a paid exercise and see how much variety you actually have. If coverage means the same thing on most of them, workbooks will hold a while longer.
- Servicer reporting into three or more trusts from a mixed originator book. Build the covenant and reporting layer, $120,000 to $250,000, and price abstraction separately with your own counsel.
- Master servicer with sub servicers, or holding whole loans split pari passu. Build toward the full platform, sequenced: intake, covenants and package generation first, then reserves and cash management triggers, then trust allocations and advancing. Phase two was scoped at $260,000 in the worked example and none of it was needed to make the monthly cycle work.
Two conditions apply to every build row. Start abstraction in week one, because it is the critical path rather than a preamble, and portfolios that already maintain abstracts move noticeably faster and pay far less. And put the repository, the infrastructure accounts and the structured abstracts in your name before anyone starts, since a developer holding that data in accounts you do not control is building a dependency rather than a system.
If you want a second opinion before signing anything, Digital Heroes contracts through India LLP, US LLC and UK LTD entities, so the agreement and the intellectual property assignment sit under law your own advisers already read. 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.
- 76% of developers are using or planning to use AI tools in their development process in 2024 (up from 70% in 2023), with current active use rising to 62% from 44%; 81% agree increasing productivity is the biggest benefit of AI tools. Source: Stack Overflow (2024) →
- 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) →
- In the Flexera 2025 State of ITAM report, respondents reported roughly 33% of SaaS spend is wasted, underscoring how paying for off-the-shelf seats and tiers that go unused erodes the supposed cost advantage of generic SaaS. Source: Flexera (2025) →
- One in four US employees report lacking career advancement opportunities; 48% of employees who participated in mentorship programs report high job satisfaction versus 29% of non-participants, and access to advancement opportunities ranges from 33% at organizations under 10 employees to 74% at those with 1,000+. Source: Gallup (2025) →
Frequently asked questions
Do we have to replace McCracken STRATEGY to modernise servicing?
No, and we would advise against it as a first move. Payment processing, escrow administration, investor accounting and the general ledger are exactly what it should be doing, and rebuilding them gains you nothing while costing a year. SS and C Precision LM occupies similar ground with different strengths on loan accounting.
The custom layer sits beside the system of record and owns what is specific to your documents: covenant definitions, borrower financial normalisation, reserve conditions, trust allocations and package generation. That framing is what keeps the number near $200,000 rather than near $700,000.
What does it cost to switch servicing systems or developers?
Switching the servicing system is a year of work with little upside, which is why the answer is usually not to. Switching developers is a different question, and it depends entirely on whether you hold the repository, the infrastructure accounts and the structured loan abstracts.
The abstracts are the expensive part to recreate. They represent reading every loan agreement and turning covenant definitions, reserve conditions and trigger terms into executable form, so a firm that holds them in its own accounts holds your ability to change firms.
What if our servicing system vendor changes pricing at renewal?
Run the arithmetic at double your loan count before renewal rather than during it. That is a fair exercise with any per loan or per module arrangement, and it is better done from a position where you are not mid implementation on anything else.
The structural point is that you are keeping the system of record either way, so the question is how much bargaining power you have elsewhere. Owning the covenant engine, the abstracts and the reporting package means your dependency on the incumbent is payments and accounting rather than your whole operation.
How long until our team can use a custom servicing layer?
Fourteen to twenty weeks for a usable first release, nineteen in the worked example. The largest schedule risk is not engineering. It is abstraction, so start it in week one and sequence it by reporting obligation.
Feed real borrower documents into extraction from about week four. Rent rolls with merged cells and a totals row in the middle are the reality, and accuracy only improves against real files rather than clean samples.
Why is loan document abstraction priced separately from the software?
Because it is legal and asset management work rather than engineering, and it sits on the critical path. Someone has to read every loan agreement and turn the covenant definitions, reserve conditions and trigger terms into structured form before any engine can be configured.
In the worked example the client's own counsel priced it at $600 a loan, so 180 loans came to $108,000, phased across three waves. Any proposal that buries this inside a software figure is understating the programme by a third.
Would Backshop remove our need to build anything?
Possibly, and it is worth checking before you commission work. Backshop is genuinely strong on origination and asset management workflow, particularly for debt funds and life companies underwriting their own paper, and for operators whose pain is pipeline and asset management rather than trust reporting it may cover the ground.
Where it stops is the same place every product stops: per deal covenant definitions as executable data, borrower financial normalisation from arbitrary formats, and pari passu allocation under your intercreditor terms.
Does this help with servicing criteria attestation?
It should, and that belongs in the business case. The attestation regime examines your process, and a process whose only control is a careful individual is difficult to attest to honestly.
A generated package with validation rules, plus a reproducible audit trail showing which inputs produced each computed test and who confirmed which normalisation, gives your accountants something to test against. Design that reproducibility in from the start, because retrofitting an audit trail costs several times what building it in costs.
We hold 300 whole loans on balance sheet. What should we spend?
Probably nothing on a build. With straightforward whole loans, no securitised reporting obligation and a competent analyst, a servicing system plus disciplined workbooks is genuinely enough.
If you want to prepare cheaply for a future where that changes, abstract twenty representative loans now and see how much variety your book actually carries. If coverage and reserve conditions mean roughly the same thing across most of them, workbooks hold. If twenty loans produce twelve different definitions, you have your answer early and at low cost.
What does a $50,000 custom software budget actually buy?
One core workflow done properly: 10 to 15 screens, two or three user roles, a couple of integrations, an admin panel, and automated tests, delivered in roughly 12 to 14 weeks. What it does not buy is that workflow plus a mobile app plus AI features plus five more integrations. The discipline of picking the one workflow that matters is what separates $50,000 projects that ship from $50,000 projects that stall at 70% complete.
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 small can the first version of my software be and still be worth building?
One workflow, end to end, for one type of user: the single process that currently burns the most hours or loses the most money. In Digital Heroes delivery experience, first versions scoped to 6 to 10 weeks of build time ship, get used, and generate the feedback that makes version two obviously right, while 9-month first versions routinely launch with features nobody touches. Everything you cut from v1 gets cheaper to build later, because real usage reorders the roadmap for you.
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.
Who owns the code when an agency builds my software?
You should, completely, through a written intellectual property assignment that transfers everything on final payment; without that clause, copyright stays with whoever wrote the code by default. Insist that the repository lives in your own GitHub organization from day one and that hosting, domains, and third-party accounts are registered to you. Also check for licenses to the agency's proprietary frameworks buried in the contract, because those can make switching vendors practically impossible even when you own your own code.
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.
Will an app built for 10 users survive growing to 500?
Yes, if it is built on standard cloud infrastructure with a sound data model, because moving from 10 to 500 users is a hosting configuration change, not a rebuild. The scaling decisions that actually hurt are made early and invisibly: how the database is structured, how accounts and permissions are modeled, and whether background work is queued properly. Ask your agency how the system would handle ten times the load; the right answer is boring and specific, and a promise to cross that bridge later means you will pay for the bridge twice.
How long does it take to build a custom web or mobile app from scratch?
Plan on 8 to 16 weeks for a focused first version and 4 to 9 months for a larger platform, which is the typical spread across Digital Heroes builds. The first 2 to 3 weeks go to discovery and design before any production code ships. The two things that stretch timelines most are integrations with legacy systems and slow feedback from your side, not developer speed.
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.
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.
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.
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 .
