Blog
Why Ground-Up Construction Loans Need Better Lending Software
I have spent the last several months looking at market data with our clients, and one trend keeps showing up in conversation after conversation with COOs and Heads of Lending at private and specialty lending shops: ground-up construction lending is accelerating fast. Year-over-year volume in construction loan originations across private lending markets is up well north of 100 percent in a number of states. Florida, Texas, and New Jersey remain the largest markets by absolute volume, but the more interesting story is happening in places like Ohio, Massachusetts, and Oregon, where growth is exploding off a smaller base. This is not a niche shift. It is a structural change in where capital is flowing, and it has real implications for how lenders need to think about their operational infrastructure.
Why Experienced Investors Are Moving Toward New Construction
The obvious explanation is housing demand, and that is part of it. But the more interesting dynamic, and the one that should matter more to lenders, is that experienced fix-and-flip investors are migrating toward ground-up construction in search of better margins. The value-add renovation model that fueled so much private lending growth over the last decade has gotten crowded. In many markets, the spread between acquisition cost, renovation cost, and exit value has compressed to the point where seasoned operators are looking elsewhere for returns that justify the risk and the effort.
Ground-up construction offers a better economic profile for experienced operators who know how to manage a build. But it is not the same product as a bridge loan with a fresh coat of paint. It is a fundamentally different loan structure, with a different risk profile, a different draw process, and materially different servicing requirements. Lenders who built their operations around fix-and-flip and bridge lending are now watching their own borrower base shift into a product their systems were never designed to support.
A Different Operational Animal
A bridge loan on an existing property is operationally simple. There is a fixed loan amount, a defined term, and a predictable interest schedule. Once the loan is booked, servicing is largely a matter of collecting payments and tracking maturity. A ground-up construction loan does not work that way. You have a total commitment, but the funds are disbursed in stages as construction milestones are completed. Every draw requires an inspection to confirm the work was actually done, a review of the budget to confirm the numbers still make sense, and a disbursement decision that carries real risk if it is made carelessly.
The loan balance itself is not static. It grows with every draw, and interest accrues on what has actually been disbursed rather than the full committed amount. The timeline is longer than a typical bridge loan, which means more touchpoints with the borrower, more documentation to track, more inspections to schedule, and more opportunities for something to go wrong along the way. None of this is unmanageable in isolation. The problem is what happens when a lender is running this process across dozens of active construction loans at once, each sitting at a different stage of its own draw schedule.
Where the Spreadsheet Model Breaks
I talk to a lot of lending operations teams who are still managing construction draws through a combination of spreadsheets and email. Someone on the team tracks the budget in Excel. Someone else is responsible for sending the inspection request to a third-party inspector. Someone reviews the inspection report and approves the draw, then notifies accounting to release funds. Each of these steps lives in a different tool, and the connective tissue between them is a person remembering to send the next email.
At low volume, this works fine. A construction lending desk with five or six active projects can manage this manually without much friction. The trouble starts at scale. When a lender has thirty, fifty, or a hundred active construction loans, each with its own draw schedule, its own inspection cadence, and its own budget variance to track, the manual process stops being an inconvenience and starts being an operational risk. Draws get delayed because an inspection report sat in someone’s inbox. Budget overruns go unnoticed until they are a real problem, because nobody had a consolidated view of committed versus disbursed amounts across the portfolio. Borrowers get frustrated because they cannot get a straight answer on when their next draw will fund. And when an auditor or an examiner asks for documentation on how draws were approved, the answer is scattered across email threads and shared drives instead of living in one system of record.
This is the point where lenders discover, often the hard way, whether their technology infrastructure was actually built for this kind of complexity or whether it was built for something simpler and has just been stretched to cover a product it was never designed to handle.
What Operational Readiness Actually Looks Like
The lenders who are handling this shift well are not the ones with the most sophisticated marketing or the largest teams. They are the ones whose loan management platforms were built from the ground up to handle complex, multi-draw, multi-stage loan products as a native capability rather than a workaround. That distinction matters more than people give it credit for.
In a platform designed for this, draw requests come in through a borrower portal instead of an email inbox, so there is a single, timestamped record of every request and its status. Budget tracking is built directly into the loan record, not maintained in a separate spreadsheet that has to be manually reconciled against the loan system. The platform automatically recalculates interest based on disbursed amounts and updates the loan balance the moment a draw is funded, instead of relying on someone to update a calculation by hand. Inspection workflows are tracked and documented in the same system as the rest of the loan file, so there is a complete, auditable history of what was inspected, when, and what was approved as a result.
None of this eliminates the need for good underwriting judgment or experienced construction lending staff. Technology does not replace expertise in evaluating a builder’s track record or assessing whether a budget is realistic. What it does is remove the operational drag that keeps experienced teams from scaling their judgment across a growing portfolio. It turns a process that depends on individual diligence and memory into a process that is systematized, visible, and consistent regardless of how many projects are active at once.
Why This Matters for Digital Transformation Planning
For lenders who are already in the middle of a digital transformation initiative, or who are starting to evaluate one, this shift toward construction lending is a useful stress test for whatever platform decision is on the table. It is easy to evaluate an alternative lending platform against your current loan mix and conclude that it handles things adequately. It is a different exercise to ask whether that platform can handle the loan mix you expect to have in eighteen months, especially if your borrower base is already showing signs of moving toward more complex products.
This is also where the case for lending software built natively on Salesforce becomes more concrete rather than theoretical. A lot of loan origination and servicing systems were built as standalone products with borrower relationship data, document management, and workflow automation bolted on as afterthoughts. When a lender needs to track a construction project’s inspection history alongside the borrower relationship, the guarantor’s other active loans, and the communication history with the general contractor, a fragmented system forces staff to piece that picture together manually across multiple tools. A platform built on Salesforce keeps borrower relationships, loan servicing, document workflows, and reporting in one connected environment, which matters enormously when the loan product itself has more moving parts than a standard term loan.
The operational risk here is not hypothetical. It shows up in delayed draws that frustrate good borrowers and push them toward competitors. It shows up in budget overruns that get caught too late because nobody had portfolio-level visibility into disbursed versus committed capital. It shows up in the time it takes to onboard a new construction lending hire, because the process for approving a draw lives in someone’s head instead of in a documented, systematized workflow. And it shows up in the audit and compliance exposure that comes from not having a clean, consolidated record of how draw decisions were made.
The Window to Get Ahead of This Is Now
Ground-up construction lending is not a trend that lenders should treat as something to watch and revisit next year. Based on what the data is showing and what I am hearing directly from lending operations leaders, it is already happening, and it is accelerating in markets that were not previously known for construction lending activity. The lenders who recognize this shift early and evaluate whether their operational infrastructure can actually support multi-draw, multi-stage construction products are the ones who will be able to grow into this opportunity without a corresponding spike in operational risk.
The lenders who wait are going to find out the hard way, likely in the middle of a busy construction season with dozens of active projects, that a spreadsheet and an email inbox were never a system. They were a workaround that held up as long as volume stayed low and every draw went smoothly. Neither of those conditions is likely to hold as this shift continues. The operational strain will show up first in the details that matter most to borrowers and examiners alike: draw timing, budget accuracy, and documentation. By the time it becomes visible to leadership, it has usually already cost the lender borrower goodwill, staff hours, or both.
The lenders who take this seriously now, before the strain becomes obvious, are the ones who will be positioned to capture this growth rather than be limited by it.
Blog
The Hidden Cost of Manual Loan Document Preparation
When lending organizations talk about operational inefficiency, the conversation almost always goes to the same three places. Underwriting workflows. Borrower communications. Payment processing. Those are real problems and worth solving. But after years of sitting in operations meetings with COOs and Heads of Lending across specialty and commercial lending, I have come to believe there is a step that gets far less attention than it deserves, and it sits right at the closing table. That step is loan document preparation.
It does not get the same airtime as origination or servicing because it feels like administrative work rather than strategic work. It is the part of the process everyone assumes is just the cost of doing business. But when you actually watch how document preparation happens inside most lending organizations, and you count the hours and the risk that come with it, it becomes clear this is one of the more expensive blind spots in the entire lending lifecycle.
What Manual Document Preparation Actually Looks Like
Strip away the terminology and here is what the process looks like in practice at a lot of lenders I have visited. Someone on the documentation or closing team pulls the approved loan data and manually keys it into document templates. Borrower details. Property information. Loan terms. Guaranty language. State-specific disclosures. Addenda that vary by jurisdiction or loan product. Once the package is assembled, it has to be reviewed line by line for compliance with federal, state, and sometimes local requirements before it can move to closing.
Experienced documentation specialists can spend hours on a single loan package when the deal has any complexity to it. Multiply that by dozens or hundreds of closings a month and the cumulative time cost is enormous. This is not a minor drag on productivity. For many lenders, documentation is quietly consuming more staff hours per loan than underwriting itself, and almost nobody is measuring it that way.
The reason this matters for a Head of Lending or a Digital Transformation Project Manager is not just about efficiency. It is about where your organization’s capacity actually goes. If your best documentation people are spending their days re-keying information that already exists somewhere else in your system, that is capacity you are not getting back, and it is capacity that does not scale with volume.
The Compliance Risk Is Not Theoretical
Time is the visible cost. Compliance risk is the cost that shows up later, and it is usually worse. Manual document preparation is one of the highest-risk steps in the lending process precisely because the consequences of a mistake are not minor. A missing state disclosure. An outdated legal clause that nobody updated after a regulatory change. An incorrect notary block. Any one of those can delay a closing, create enforcement exposure down the road, or, for lenders selling loans to investors or drawing on warehouse lines, trigger a repurchase demand.
This is where the private lending and specialty finance space feels the pain most acutely. Investors and warehouse lenders hold documentation to a strict standard, and they are not interested in explaining away an error. A single documentation defect can unwind an otherwise clean deal, and it can do so months after the closing, when the loan is already on someone else’s balance sheet and the mistake is far more expensive to fix than it would have been at origination.
What makes this risk particularly dangerous is that it is largely invisible until it is not. A lender can run manual document preparation for years without a serious incident and conclude the process is fine. Then one state disclosure gets missed on a loan that later goes into default, and the cost of that single error dwarfs years of accumulated time savings from not investing in a better process. Risk that is rare but severe is exactly the kind of risk operations leaders should be actively managing rather than quietly tolerating.
Why the Problem Gets Worse as Lenders Grow
The time drain and the compliance exposure are bad enough on their own, but the part that should concern any lender with growth ambitions is how fast this problem compounds. Lenders that are expanding into new states, launching new loan products, or adding new origination channels discover that document complexity grows faster than loan volume.
Every new state brings its own disclosure requirements. Every new loan product requires its own document structure and its own set of conditional clauses. When all of that complexity is managed manually, through templates maintained in shared drives and institutional knowledge held by a handful of experienced staff, the documentation function becomes the ceiling on how fast the rest of the organization can move. I have talked to lending executives who were ready to expand into new markets and had to slow down, not because of capital or demand, but because their documentation team could not absorb the additional complexity without a level of hiring that did not make financial sense.
That is the real definition of a bottleneck. It is not the function that fails outright. It is the function that quietly sets the pace for everyone else, and nobody notices until growth plans run into it.
Why This Is One of the Highest-Return Areas Right Now
Here is what I keep observing across specialty lenders that have actually tackled this problem head on. Document automation is one of the highest-return investments available to a lending organization right now, and it is not because the underlying technology is new. Automated document generation has existed in some form for a long time. The reason the return is so high is that the gap between what is possible and what most lenders are actually doing day to day is still enormous.
The lenders who have automated document generation are closing faster, producing fewer errors, and running documentation teams that can support meaningfully higher volume without proportional headcount growth. That last point deserves emphasis, because it is the difference between a process that scales and a process that simply adds cost as you grow. A documentation team that can support double the loan volume with the same staff has fundamentally changed the economics of the business, not just made one team’s job easier.
This is also where the conversation should move away from thinking of document preparation as paperwork and start thinking of it as a data problem. The loan data that gets underwritten and approved already exists in a structured form somewhere in your systems. The question is whether that data flows forward into the closing package automatically, or whether someone has to manually recreate it in a separate tool. Every time that data gets manually re-entered, you are introducing an opportunity for error and adding time that does not need to exist.
Why Integration Is the Real Unlock
The integration piece is where document automation becomes genuinely powerful, particularly for lenders operating on modern, connected platforms. When loan data flows directly from an origination system into document generation without anyone re-entering it, you eliminate the most common source of documentation errors entirely. The data that was underwritten is the exact data that gets documented. There is no manual transfer step, no typo risk, and no version mismatch between what the underwriter actually approved and what ends up in front of the borrower at the closing table.
This is a meaningfully different outcome than simply digitizing templates or moving from paper to PDF. Digitizing a manual process still leaves the manual process intact. The real operational gain comes from removing the re-entry step altogether, so that document generation becomes a natural extension of the origination workflow rather than a separate task performed by a separate team using separate information.
For lenders running on a Salesforce-native platform, this connection tends to be more achievable than it looks, because the underwriting data, borrower data, and loan terms already live in a single system of record. The document package becomes an output of that system rather than a parallel process someone has to manage by hand. That is the structural difference between lenders who treat documentation as a cost center they tolerate and lenders who treat it as a workflow they have engineered.
The Practical Question Every Operations Leader Should Ask
If you are running lending operations, the exercise here is straightforward. Pull up your last ten closings and count the actual hours your team spent on document preparation for each one. Not an estimate. The real number, including the review and compliance check cycles. Then ask whether that time, and the compliance risk that came with it, is something your organization genuinely wants to keep carrying as you grow.
Most operations leaders who run this exercise are surprised by the number. It is rarely small, and it is almost always larger than what gets budgeted or staffed for, because the work has been absorbed into the daily routine rather than measured as a discrete cost. Once you see the number clearly, the case for treating document preparation as a process worth automating, rather than an unavoidable cost of doing business, tends to make itself.
Lending organizations do not need to accept that documentation is simply where time and risk go to disappear. It is a solvable operational problem, and the lenders solving it now are building a real structural advantage over competitors who are still treating it as background noise. As loan volume grows, as new states and products get added, and as investor and warehouse lender scrutiny increases, the gap between lenders who have automated this step and lenders who have not will only widen. The organizations paying attention to it today are the ones who will be able to grow without their documentation team becoming the reason they cannot.
Blog
Why Lenders Should Slow Down on AI Adoption
I was talking recently with the head of a specialty lending operation, a sophisticated team that has been in growth mode and expanding into new markets. I asked him how AI was showing up inside his organization. His answer surprised me. He said AI is not allowed at his company right now, with one exception: a single enterprise tool with proper controls in place. And he was clear that this was by design, not an oversight.
His reasoning was simple and direct. His team handles customer sensitive financial information every day. Borrower data. Loan files. Personal financial statements. And the risk of that information being mishandled through an AI tool without the right enterprise controls is not theoretical. It is real, and it is happening right now across the industry. His words stuck with me. He said his competitors are going to get themselves in trouble because they think AI is going to solve everything, and they are going to realize what they exposed themselves to a little too late.
I think he is right, and I think it is a perspective that deserves more attention than it is currently getting. The pressure on lending executives to do something with AI right now is enormous. Board members are asking about it. Investors are asking about it. Staff are asking about it. And the easiest thing in the world, when that pressure builds, is to start experimenting with whatever tools are available without fully thinking through what data is going into them and where that data goes once it leaves your hands.
The Real Risk Is Not Hypothetical
The specific risk this executive flagged is one I am hearing about more often in conversations across the industry. People inside lending organizations are dumping customer sensitive information into personal AI accounts. Chat tools. Document summarizers. Whatever is fast and easy to use in the moment. Most of them have no idea that the information they are entering may be retained, used to train underlying models, or accessible in ways that directly violate their organization’s data governance obligations.
In lending, this is not an abstract compliance concern. You are handling income data, credit information, tax returns, bank statements, and personal financial details that are protected under a range of regulatory frameworks. When that information moves through an AI tool that was never vetted for enterprise use, you have lost visibility into where it goes and who might eventually have access to it. That exposure does not show up immediately. It shows up later, often during an examination, an audit, or a data incident, at which point it is too late to undo.
This is the part of the AI conversation that gets skipped over in most of the current enthusiasm. Everyone wants to talk about what AI can do. Fewer people want to talk about what happens when it is deployed carelessly inside a regulated business that owes its customers, and its regulators, a duty of care around sensitive data.
Crawl, Walk, Run Is the Right Framework
The approach this executive described, restricting AI broadly while allowing one vetted enterprise tool with real controls, is not caution for its own sake. It is the correct sequencing for an organization that understands where its risk actually lives. Crawl, walk, run is not a slogan. It is a discipline, and it happens to be the right discipline for lending operations specifically because the value of AI in this industry is directly tied to the quality and structure of the data environment underneath it.
An AI tool querying a well-structured lending platform with proper enterprise controls produces reliable, auditable results. It can answer a specific operational question and you can trace exactly how it arrived at that answer, what data it touched, and who was authorized to ask. An AI tool with access to messy, unstructured data spread across disconnected systems produces outputs that nobody can fully trust, because nobody can fully explain where the answer came from or whether the underlying data was even accurate in the first place.
This is the distinction that gets lost in the rush to adopt. AI does not create good outcomes by itself. It amplifies whatever is already true about your data environment. If your loan data lives across five disconnected systems, spreadsheets, and email threads, AI will not fix that. It will simply generate confident-sounding answers built on top of an unreliable foundation, and confident-sounding wrong answers are more dangerous than no answer at all, especially in a lending context where decisions have real financial and regulatory consequences.
Why Salesforce-Native Lending Platforms Have an Advantage Here
What I find genuinely interesting, from an operational and architectural standpoint, is that lending organizations already running on Salesforce are in a materially better position than most when it comes to adopting AI responsibly. When your loan origination and servicing platform is built natively on Salesforce, the most natural AI layer available to you is Salesforce’s own Agentforce.
Agentforce operates entirely within your existing Salesforce security model. It respects your profiles, your permission sets, and your data sharing rules exactly as they are already configured. It does not require you to export sensitive borrower data to an external tool sitting outside your compliance perimeter. It does not create a new data governance exposure that your compliance and risk teams then have to go identify, evaluate, and retroactively control. The governance work you have already done to secure your lending data on Salesforce extends automatically to how AI is allowed to interact with that data.
In practice, this means a loan operations team can ask a natural language question, something like show me all loans maturing in the next ninety days, or which borrowers are past due on their next payment, and get an instant answer. The AI is querying data that already lives inside your existing, permissioned, audited environment. Nothing new is created outside the walls you already built. Nothing sensitive leaves the system to go sit inside a third party’s infrastructure with unclear retention practices.
That is not a flashy use of AI. It will not generate headlines. But it is useful, it is auditable, and critically, it does not introduce new compliance risk into an operation that is already carrying plenty of regulatory obligation. For a lending organization that takes its data obligations seriously, that is exactly the kind of AI adoption that makes sense as a starting point, and arguably as the only sensible starting point.
Speed Is Not the Advantage People Think It Is
There is a widespread assumption right now that moving fast on AI is inherently an advantage, and that lenders who hesitate are going to be left behind. I understand where that assumption comes from, but I do not think it holds up when you look closely at what is actually being adopted and how.
The lenders who are going to look smart in three years are not going to be the ones who adopted AI fastest. They are going to be the ones who adopted it thoughtfully, with the right enterprise controls in place, the right data governance discipline already established, and a platform architecture that supports AI without creating new exposure in the process. Everything else is just speed for its own sake, and speed without direction in a regulated industry tends to produce the kind of headline nobody wants attached to their organization.
The lenders moving fast without those guardrails in place are effectively placing a bet that regulators and examiners are not paying close attention right now, or will not catch up to what happened until well after the fact. That is not a bet I would want to make with customer financial data, and it is not a bet I would advise any lending executive to make on behalf of their organization, their board, or their borrowers.
What Deliberate Adoption Actually Looks Like
Deliberate does not mean slow for the sake of being slow, and it does not mean avoiding AI altogether. It means starting with a clear-eyed assessment of where your sensitive data actually lives, who currently has access to it, and what controls already exist around it before you introduce any new tool into that environment. It means choosing enterprise-grade tools that operate within your existing security architecture rather than tools that require you to hand data outside your walls in exchange for convenience.
It means being honest with your board and your investors about why you are moving at the pace you are moving, rather than adopting something quickly just to have an answer ready for the next board meeting. Boards and investors who understand lending, and increasingly most of them do, will respect a deliberate answer grounded in data governance far more than they will respect a rushed pilot that later becomes a liability.
It also means recognizing that the foundation matters more than the tool. An organization with clean, centralized, well-governed lending data on a platform like Salesforce is positioned to adopt AI capability incrementally and safely, expanding what the technology is trusted to do only as confidence in the underlying data and controls grows. An organization still operating across spreadsheets and disconnected point solutions is not actually choosing between fast AI adoption and slow AI adoption. It is choosing between AI built on a shaky foundation or doing the foundational data work first. The second path takes longer, but it is the only one that produces results anyone can actually trust and defend under examination.
The conversation I had with that lending executive was a useful reminder that the smartest people in this industry right now are not the ones chasing every new AI headline. They are the ones asking harder questions about data, governance, and architecture before they let any new tool near their borrowers’ information. That instinct is not caution born of fear. It is operational discipline, and in lending, operational discipline is what separates the organizations that grow sustainably from the ones that end up explaining themselves to a regulator.
Blog
Why CDFI Growth Now Means Mergers, Not Just More Loans
For most of the history of community development finance, growth has meant one thing: make more loans. Raise more capital, hire more loan officers, open another office, deepen relationships in another underserved market. That model has worked for decades, and it still works today for the majority of Community Development Financial Institutions, or CDFIs, serving small businesses, affordable housing developers, and borrowers that traditional banks routinely pass on.
But I have started to notice a different growth pattern taking shape among a smaller group of more ambitious CDFIs, and I do not think enough people in this industry are talking about it yet. These organizations are not just trying to originate more loans. They are trying to become the operational backbone for an entire network of community lenders. Instead of growing loan by loan, they are growing institution by institution, acquiring and merging with smaller CDFIs and absorbing their portfolios, their staff, and their operations onto a shared platform.
The Business-in-a-Box Model for Community Lending
The clearest way to describe what these organizations are building is something close to a business in a box for community lending. A smaller CDFI, often one that is well-run mission-wise but operationally stretched thin, gets acquired or merged into a larger organization. Rather than continuing to run its own systems, its own reporting, and its own back office, it gets folded into a shared infrastructure. The acquiring organization brings standardized underwriting workflows, centralized servicing, consolidated reporting, and a technology platform that the smaller organization never had the resources to build on its own.
Over time, the acquiring organization stops looking like a single lender and starts looking like a network. It has multiple entities, multiple program types, multiple funding sources, and multiple geographies, all operating under one operational umbrella. That is a fundamentally different organization than the CDFI that exists to make loans in one region or one asset class. It is closer to a platform business that happens to be in the business of community lending.
This is still an early trend. Not every CDFI is positioned to pursue it, and not every CDFI should. But the organizations pursuing this model tend to be some of the most sophisticated operators I encounter in the community lending space right now, and the implications for how they think about technology infrastructure are worth examining closely.
Why the Funding Mix Matters
One detail I find particularly telling about this emerging model is the capital structure behind it. The CDFIs pursuing acquisitions and mergers are generally not the ones relying primarily on annual government grant cycles. They have diversified their capital sources considerably, drawing on large bank partnerships, private investment capital, and New Markets Tax Credits alongside traditional grant funding.
That diversification matters because it changes the time horizon an organization can operate on. A CDFI that depends heavily on grant funding is often planning in twelve-month increments, because that is the cadence its funding operates on. An organization with a more diversified capital base, including private investment and bank partnerships, can plan in five and ten year horizons. That longer horizon is a prerequisite for pursuing acquisitions, because mergers are not one-quarter decisions. They require patient capital, a stable balance sheet, and the ability to absorb the operational cost of integration without disrupting day-to-day lending activity. The CDFIs building toward a network model have generally done the work on the funding side first, and the operational ambitions follow from that financial stability rather than the other way around.
What a Single-Location Lender Can Get Away With
It is worth being honest about what a smaller, single-entity community lender can operate with, because it explains why this shift in ambition changes everything on the technology side. A CDFI running a few hundred loans out of one office can survive on a legacy loan management system, a set of shared spreadsheets, and a handful of employees who know the exceptions and workarounds by heart. It is not efficient, and it is not scalable, but it is survivable. Tribal knowledge fills in the gaps that the systems cannot cover.
That approach does not survive contact with a merger. An organization absorbing another CDFI is not just adding loan volume. It is adding an entirely separate set of workflows, reporting requirements, program rules, and often an entirely separate technology stack that has to be reconciled with its own. The tribal knowledge that held the smaller organization together does not transfer. It has to be replaced with documented, standardized process, and that process has to live inside a system that can actually enforce it across two organizations instead of one.
What the Network Model Actually Requires From Technology
Once an organization decides it wants to grow by acquisition rather than by origination volume alone, its technology requirements change in specific and predictable ways.
The first requirement is configurability across multiple program types and multiple entities. A CDFI network is rarely lending under one uniform program. It might be running small business loans, affordable housing construction loans, and New Markets Tax Credit-financed projects simultaneously, each with different underwriting criteria, different compliance requirements, and different reporting obligations to funders and regulators. A platform that was built around a single loan type or a single workflow will not bend to accommodate that diversity without significant custom development, and custom development is exactly the kind of implementation risk that slows down an acquisition strategy.
The second requirement is reporting that gives leadership visibility across the entire network, not just one location or one entity. When a CDFI acquires another organization, the board and the executive team need to see performance across the combined portfolio almost immediately. They need to know how the acquired organization’s loans are performing, whether its underwriting standards match the parent organization’s risk tolerance, and where operational bottlenecks are showing up. If that reporting has to be manually assembled from two disconnected systems, the acquisition’s value is diminished before it even has a chance to prove itself.
The third requirement is onboarding infrastructure that does not require a year-long implementation every time a new organization joins the network. This is the requirement I think gets underestimated the most. An organization that plans to make one acquisition can tolerate a slow, painful onboarding process as a one-time cost. An organization that plans to make acquisitions repeatedly over five or ten years cannot. If every merger requires a twelve-month systems integration project, the acquisition strategy itself becomes unworkable, because the operational drag outpaces the benefit of scale. The organizations that get this right treat onboarding a newly acquired CDFI the way a franchise treats opening a new location: a repeatable, largely standardized process rather than a bespoke project each time.
Why the Platform You Are Already On Matters More Than You Think
There is a dimension to this that goes beyond configurability and reporting, and it has to do with what happens on the day two organizations actually try to merge their operations. In my experience, the hardest part of any merger is rarely the strategic rationale or the deal terms. It is the technology consolidation. Data has to move from one system to another. Workflows built around one organization’s assumptions have to be reconciled with another organization’s assumptions. Staff who have spent years learning one system have to be retrained on another, often while continuing to service existing borrowers without interruption.
That process is dramatically smoother when both organizations are already operating in the same technology ecosystem. This is where the choice of underlying platform becomes a strategic decision rather than a purely technical one. Salesforce is the most widely adopted enterprise platform in the nonprofit and financial services world, which means the odds that your next merger partner is already running on Salesforce, or is at least familiar with how it works, are considerably higher than with almost any other platform on the market. A shared underlying architecture does not eliminate the work of a merger, but it removes an entire category of friction. Data structures are more likely to be compatible. Staff face a shorter learning curve. Integrations that already exist for one organization are more likely to work, or work with modest adaptation, for the other.
For a CDFI with no acquisition ambitions, this consideration is close to irrelevant. Pick whatever system fits your current operations best. But for an organization that has decided its growth strategy runs through mergers and acquisitions, the platform decision starts to look less like a vendor selection and more like a piece of long-term strategic infrastructure. Building loan origination and servicing operations on a Salesforce-native platform is not simply about the features available today. It is about reducing the friction of every integration that has not happened yet.
An Early but Real Advantage
I want to be clear that the super CDFI model, if we want to call it that, is still early. Most CDFIs are not pursuing this strategy, and most do not need to. Making more loans in your existing market, to your existing borrower base, is still a perfectly legitimate and often the right growth path for a mission-driven community lender.
But for the organizations that are pursuing this network model, the technology decisions they make in the next two or three years are going to matter enormously. The CDFIs that build configurable, well-integrated operational infrastructure now are going to be positioned to move quickly when an acquisition opportunity presents itself, because the hard work of standardizing workflows and centralizing reporting will already be done. The CDFIs that wait, or that continue to run critical operations on legacy systems with no integration path, are going to find that the technology consolidation itself becomes the barrier to growth, even when the strategic and financial case for a merger is sound.
The organizations I am watching most closely right now are not the ones talking about growth in terms of loan volume. They are the ones talking about becoming the infrastructure other community lenders plug into. That is a meaningfully different ambition, and it deserves a meaningfully different approach to the technology underneath it.
Blog
Why the Sales-to-Implementation Handoff Makes or Breaks Lenders
When lending organizations evaluate new technology, they spend most of their time evaluating the things that show up on a scorecard. Features. Workflows. Integrations. Pricing. Implementation timelines. Those things all matter, and they deserve the scrutiny they get. But there is a moment in almost every technology relationship that gets far less attention than it should, and it tends to define how the entire engagement feels for years afterward. That moment is the handoff from sales to implementation.
The Pattern I Keep Seeing
I spend a lot of time talking to COOs, Heads of Lending, and Digital Transformation leaders at specialty and community lenders. I hear a version of the same story often enough that I no longer think of it as an outlier. A lending organization goes through a months-long evaluation process. There are demos, reference calls, pricing negotiations, security reviews. Somewhere in that process, real context gets built between the buyer and the vendor’s sales team. The vendor learns about the lender’s loan products, their servicing quirks, their reporting requirements, the specific reasons their current system is holding them back. Trust accumulates slowly, conversation by conversation.
Then the deal closes. And in a lot of cases, the buyer is handed off to an implementation team that was not part of any of those conversations. That team is starting from a document, or a summary email, or a kickoff call where everyone is meeting for the first time. The context that took months to build is gone, or at best partially reconstructed from notes.
That experience is jarring for the buyer. It is also completely avoidable, which is what makes it frustrating when it happens. The erosion is not because the implementation team is incompetent. It is because the buyer spent months building a relationship with one set of people, and now has to start over with another set of people, at exactly the moment when they need the most confidence that they made the right decision.
Why This Moment Carries More Weight Than It Looks Like It Should
It is worth being precise about why this particular transition matters so much, because on the surface it can look like a soft, relationship-oriented concern rather than an operational one. But the timing is what makes it significant. The handoff happens at precisely the point where the buyer has the least information and the most exposure. They have just committed budget, internal political capital, and staff time to a decision. They have not yet seen the platform perform in their own environment. The only evidence they have that they made a good choice is how the vendor behaves in the first few weeks after the ink dries.
If that experience feels disjointed, it does not just create friction. It plants a seed of doubt that colors every subsequent interaction. Buyers start reading extra scrutiny into things that would otherwise be treated as normal implementation bumps. A delayed data migration becomes evidence of a pattern rather than a scheduling issue. A miscommunicated requirement becomes proof that the vendor does not understand the lender’s business rather than a rough patch in onboarding. Once that lens is in place, it is very hard to remove.
Contrast that with what I hear from lending executives who describe their implementation experience positively. Almost without exception, they describe a specific mechanic, not a vague feeling of good service. The transition was done live, on a call, with both the outgoing salesperson and the incoming implementation lead present at the same time. The context was communicated directly, in front of the client, not through a handoff document that nobody reads carefully. The buyer got to hear, in real time, that the person who understood their business was transferring that understanding to the person who would be building their system.
That sounds like a small operational detail. It is not common, and the lenders who experience it notice immediately.
This Is Not a Transaction, It Is the Start of a Dependency
Part of why this matters more in lending technology than in a lot of other software categories is the nature of what is being purchased. CDFIs, community lenders, and specialty finance companies are not buying a commodity tool that they can swap out in a quarter if it does not work. They are entering a multi-year operational dependency. Loan origination and servicing platforms sit underneath the entire lending lifecycle. Once a lender is live on a system, unwinding that decision is expensive, disruptive, and organizationally painful. Everyone involved in the buying process knows this going in, even if they do not say it out loud during the evaluation.
Because the relationship is long-term and hard to exit, the way it begins matters disproportionately. The implementation is not the final step of a sales process. It is the first chapter of a relationship the lender is going to be living inside of for years. Buyers who have been through a bad software transition before, and most executives evaluating a new platform have, are attuned to this. They are watching for signals early, because they know that whatever they experience in the first thirty days is a preview of what year three is going to feel like when something goes wrong and they need support fast.
This is also why the handoff moment tends to reveal more about a vendor’s operating discipline than almost anything in the sales process itself. A sales team can present a polished demo regardless of how well-run the company is behind the scenes. A smooth, well-orchestrated handoff is much harder to fake. It requires internal coordination, shared documentation practices, and a culture where the sales team is incentivized to set up the implementation team for success rather than just close the deal and move on to the next prospect. Those are structural things. They show up in the handoff whether or not the vendor intends for them to.
What This Means for a Lender Going Into an Evaluation
If you are a COO or a Digital Transformation lead running a technology evaluation right now, there is a practical implication here that is worth acting on directly, not just filing away as an observation. The handoff between sales and implementation is something you can and should evaluate before you sign, not something you discover after the fact.
Ask the vendor directly how they handle the transition from sales to implementation. Not in the abstract, but specifically. Is there a live call where both teams are present? Is there a formal internal process for context transfer, or is it left to whoever remembers to send an email? These are fair questions to ask during a sales process, and how a vendor answers them tells you something real about how seriously they take what happens after the deal closes.
Ask to meet the implementation team before you sign. This is a reasonable request, and a vendor that resists it or treats it as unusual is telling you something. A vendor confident in their implementation process will generally welcome the opportunity to introduce that team early, because it reinforces the sale rather than complicating it.
Ask whether the people who will be working on your account after go-live are the same people who will be involved during implementation, or whether there is another handoff coming once implementation wraps. Multiple handoffs compound the risk. Each one is another point where context can be lost and where the relationship has to be rebuilt.
None of these questions will show up on a feature comparison matrix. But the answers will tell you more about what your actual day-to-day experience is going to feel like than almost anything in a product demo. A platform can have every feature you need and still deliver a poor experience if the people responsible for making it work in your environment were never properly briefed on why you bought it in the first place.
The Real Differentiator Is Not Always the Platform
I want to be direct about something that runs against the instinct most buyers have during an evaluation. It is natural to assume that the smoothest implementation will belong to whichever vendor has the most capable, most fully-featured platform. Capability matters, and it is not something to compromise on. But in practice, the lenders who describe the smoothest implementations are not always the ones who picked the platform with the deepest feature set. They are the ones who picked a partner that treated the handoff from sales to delivery as seriously as they treated the sale itself.
That is a different kind of diligence than most evaluation processes are built to capture. Feature comparisons and pricing models are easy to put in a spreadsheet. Organizational discipline around client handoffs is not. But it is just as real, and it has just as much bearing on whether the implementation actually succeeds and whether the lending organization ends up with a partner they trust or one they tolerate.
For lenders building out their evaluation process, this is worth building in explicitly rather than leaving to chance. Treat the handoff conversation as part of the diligence, not an afterthought you discover after the contract is signed. The vendors who take it seriously will be glad to talk about it. The ones who have not thought about it will tell you that too, just less directly.
Blog
Why Growing CDFIs Are Outgrowing Legacy Loan Servicing Systems
I have been spending a lot of time lately with CDFIs and community lenders that are in growth mode. New locations, new loan products, sometimes an acquisition on the horizon. And in almost every one of those conversations, the same story comes up. The core loan servicing platform that carried them for the last decade is starting to show its age, and the organization is finally ready to admit it.
This is not a new phenomenon in lending. Every generation of community lenders eventually reaches a point where the systems that got them off the ground can no longer support where they are headed. What is different right now is the specific shape of the problem. It is not that these legacy systems are unreliable or that they crash. Many of them are stable, well-understood, and have years of institutional history baked into them. The problem is narrower and, in some ways, more urgent. It comes down to two things I hear over and over again: no integrations and no AI.
The System That Was Good Enough Stops Being Good Enough
Every organization I talk to describes roughly the same arc. The loan servicing platform was implemented years ago, sometimes on-premise, sometimes as an early cloud tool built before open APIs and modern integration standards became the norm. At the time, it did exactly what was needed. It tracked loans. It processed payments. It generated the reports regulators and boards required. For an organization with twenty staff and a few hundred loans on the books, that was more than sufficient.
Growth changes the math. Once an organization crosses into multiple locations, fifty or more staff, and a more diverse loan portfolio, the operational center of gravity shifts. It is no longer just about whether the system can process a payment correctly. It is about whether the organization can move information across departments, locations, and systems fast enough to keep pace with its own growth. That is where legacy platforms start to buckle, not because they fail outright, but because they were never designed to be connective tissue. They were designed to be a standalone system of record.
No Integrations Is Not a Technology Problem. It Is an Operational Risk
The first thing that comes up in nearly every one of these conversations is integration, or the lack of it. The accounting system does not talk to the loan servicing platform. The CRM has no connection to servicing data. Every time information needs to move between systems, a person is doing it manually, usually through exporting a spreadsheet, reformatting it, and importing it somewhere else.
At a small scale, this is annoying but survivable. At the scale these growing CDFIs are now operating at, it becomes something more serious. It becomes an operational risk. Every manual handoff is an opportunity for data to fall out of sync. A payment gets applied in one system and not reflected in another. A borrower’s updated contact information lives in the CRM but never makes it into servicing. Reconciliation between systems, which should be a routine background process, becomes a recurring fire drill that consumes real staff hours.
What strikes me most is where this shows up in the organization. It is rarely the frontline loan officers who feel it first. It is the operations team, the people responsible for keeping everything reconciled and reportable, who end up absorbing the cost. Their time gets consumed by coordination work instead of the analysis and process improvement they were hired to do. When I ask leaders what their operations team actually spends its day doing, the honest answer is often some version of moving data between systems that should already be talking to each other.
This is worth naming clearly because it rarely gets described this way internally. Nobody walks into a board meeting and says the organization has an integration problem. They say the team is stretched thin, or reporting takes too long, or they cannot get a clean picture of the portfolio without pulling data from three different places. Those are all the same problem wearing different language.
No AI Is a Forward-Looking Problem, Not a Current One
The second theme is a little different in character. It is not about a pain point happening today. It is about a door that is closing for the future. CDFI leadership teams are watching the broader financial services industry move deliberately toward AI-enabled operations. They are attending industry events where this is the dominant topic. They are hearing about co-pilot tools, automated underwriting assistance, and agent-based workflows that reduce manual review time. Salesforce, in particular, has made a very public and very large investment in AI for financial services, and lenders across the industry are paying attention to it.
The problem for organizations on legacy servicing platforms is that none of this is available to them, not because they are behind on adoption, but because their core system has no pathway to connect to any of it. It was built in a different technological era, often before cloud-native architecture was standard, let alone before AI tooling existed as a layered capability on top of a platform. These organizations are not choosing to sit out the AI conversation. Their infrastructure is making that choice for them.
This creates a specific kind of frustration among leadership teams, because it is not a problem they can solve with more effort or better training. You cannot work around an architectural limitation. Either the platform has a path to modern data infrastructure and automation, or it does not. And for a growing number of CDFIs, the answer is no, and they know it.
What Actually Triggers the Decision to Move
One pattern I find genuinely interesting is that the decision to finally replace a legacy servicing platform is almost never triggered by a single dramatic failure. There is rarely one bad audit or one catastrophic outage that forces the issue. Instead, what I see consistently is a combination of two forces arriving at the same time.
The first is organic growth pressure. New branches, new products, higher loan volume, sometimes an acquisition that suddenly requires integrating a second organization’s loan portfolio into the fold. This growth exposes the operational cracks that were tolerable at a smaller scale but are no longer sustainable.
The second is a change in leadership, or at least the arrival of someone in a senior operations or technology role who has direct experience with what modern infrastructure looks like elsewhere. This person has usually worked at an organization, inside or outside the CDFI space, where systems were integrated, data flowed cleanly, and technology decisions were made with a longer time horizon in mind. They bring a frame of reference that the existing team may not have had internally. Suddenly there is a name for the problem, and a sense of what good looks like on the other side of it.
When those two forces combine, growth pressure and a new frame of reference, that is when evaluations that had been quietly postponed for years finally move forward. I have seen organizations sit with a known limitation for a long time simply because no one internally had seen an alternative that felt tangible. It takes someone with outside experience to turn a vague sense of falling behind into a concrete case for change.
The Real Opportunity Is Bigger Than Fixing Two Problems
Here is the part of this conversation that I think gets underappreciated. When a CDFI finally makes the move to a modern, Salesforce-native lending platform, they are not just solving the integration problem and the AI problem in isolation. They are repositioning their entire technology stack for the next decade of the organization’s growth.
This matters because Salesforce itself continues to invest heavily in AI, automation, and data infrastructure across its platform. An organization running its lending operations natively on Salesforce does not need to evaluate, purchase, and integrate each new capability as a separate project. It becomes available as part of the platform they are already standing on. That is a fundamentally different posture than trying to bolt modern capabilities onto a legacy system that was never designed to receive them.
This is also why I think the framing matters so much when CDFI leadership teams evaluate this decision. It is easy to think about a platform replacement as a defensive move, something you do because the old system is causing problems. The more accurate framing is that it is an offensive move. It is choosing an operational foundation that keeps pace with where the rest of financial services technology is headed, rather than a foundation that requires a separate, disruptive migration every time the underlying technology environment shifts again.
What This Means for Lenders Weighing the Decision
If you are a COO or head of lending at a CDFI reading this and recognizing your own organization in it, the questions worth asking are not really about features. They are about trajectory. Can your current platform connect natively to the other systems your organization depends on, or does every connection require custom, brittle, one-off work? Does your platform have any pathway to participate in the AI and automation investments happening across the broader industry, or is that door permanently closed by the architecture itself?
And perhaps most importantly, what would it take for your organization to build the case internally? In my experience, that case tends to build itself once growth creates enough pressure. The more useful thing leadership teams can do is make sure someone in the organization has real visibility into what modern lending infrastructure looks like, so that when the pressure arrives, the path forward is already clear rather than something the team has to discover from scratch under time pressure.
The CDFIs I see making this transition successfully are not doing it because a vendor convinced them to. They are doing it because they looked honestly at where their operations were headed, recognized that their current platform could not go there with them, and decided that the disruption of a transition was smaller than the cost of standing still.