Why Lenders Don’t Know What They Need Until Go-Live

Something comes up in almost every conversation I have with lending organizations that have been live on a platform for six months or more. It is some version of the same honest reflection. They could not have told you at the beginning of the implementation what they actually needed. They only figured that out by doing real transactions and running into real situations that the initial configuration did not anticipate.

I want to be careful about how I frame this, because it is not a criticism of vendors or of implementation teams. It is a structural reality of how lending operations work. You cannot fully spec a loan origination software implementation the way you might spec a piece of manufacturing equipment, where the requirements are fixed and knowable in advance. Lending is a living process, full of exceptions, and the decisions that matter most in a configuration are the ones nobody thinks to ask about until they are staring at an actual transaction that does not fit the mold.

The decisions that actually matter are invisible at the start

Think about what a typical requirements-gathering process for a new platform looks like. You get the operations team in a room, sometimes with the vendor, sometimes with an implementation partner, and you walk through your loan products, your servicing workflows, your reporting needs. It is a thorough process, and the people in the room are experienced. But they are describing what they remember, not what is about to happen.

How should payment allocation logic handle an odd partial payment that does not match the amortization schedule. What does the payoff workflow need to look like when a borrower on a specialty product pays off eleven days into a new cycle. How should collections triggers behave for a borrower who has a temporary hardship but a strong payment history otherwise. What does the investor reporting structure need to produce when a loan gets restructured mid-term and two different funders need to see it reflected two different ways.

These are not exotic questions. They are the ordinary texture of a lending operation. But they require operational context that most organizations do not fully have until they are living inside the platform, processing real transactions, watching real exceptions surface. You can ask an operations leader to imagine these scenarios in a discovery workshop, and they will do their best. But imagining a scenario and encountering it are different experiences, and only one of them generates the specificity a configuration actually needs.

What actually happens after go-live

The pattern I see across specialty lenders, CDFIs, commercial lenders, and private credit shops is remarkably consistent. The implementation covers the obvious workflows well. Origination, basic servicing, standard reporting. The team goes live and things work reasonably well for the straightforward cases, which is most of the volume in the early weeks.

Then the edge cases start appearing. A payment comes in for an unusual amount. A borrower requests a temporary restructuring. An early payoff generates a refund situation the servicing team has never had to process through the new system. And suddenly the team is submitting support tickets for transactions that feel like they should be basic but somehow require five emails and two escalations to resolve, because the system was never configured for that specific scenario. Nobody knew to configure for it, because nobody had run into it yet.

I want to underline this point because it changes how you should think about the first ninety days on a new alternative lending platform. This is not a failure of the implementation. It is the natural second phase of it. The first phase gets the foundation right, meaning the loan products, the intake workflows, the basic servicing rules, the reports your board and your funders expect to see. The second phase, which often starts three to six months after go-live, is where the real customization happens. It is driven by actual operational experience rather than anticipated requirements, and it is where a genuinely well-configured system gets built.

Why this catches organizations off guard

Most digital transformation initiatives in lending are budgeted and staffed as if the implementation ends at go-live. The project plan has a clear finish line. The steering committee reports success. The implementation partner rolls off. And then, three months later, the operations team is quietly accumulating a backlog of workflow gaps, unsure whether raising them again constitutes admitting the project failed.

This is where a lot of the frustration I hear about lending technology actually originates. It rarely comes from the platform itself being wrong for the organization. It comes from the mismatch between how the implementation was resourced and how lending operations actually mature. Nobody budgeted for the second phase, so when the second phase’s needs surface, there is no obvious mechanism to address them. The requests pile up, the operations team starts working around the system instead of through it, and six months later someone concludes the platform does not fit, when what actually happened is that the configuration was never allowed to finish maturing.

I have also seen this cut the other way, where a lender tries to solve the problem by over-specifying everything up front. They spend four extra months in discovery trying to anticipate every possible scenario before writing a single configuration. This rarely works either. You end up with a configuration built around hypothetical edge cases that may never occur, at the cost of months of delay, while the real edge cases, the ones that only show up once borrowers and transactions start flowing through the system, still surprise you anyway.

What the lenders who navigate this well actually do

The lenders who handle this transition best are the ones who plan for the second phase explicitly, rather than being surprised by it. That planning takes a few concrete forms.

They budget for ongoing managed services or build internal Salesforce administration expertise, so there is a standing capacity to make configuration changes without opening a formal change request every time an edge case appears. This matters more than it sounds. A team that has to escalate every workflow gap through a vendor’s support queue will let a backlog build for weeks. A team with someone internally who can adjust a flow, a validation rule, or a report in an afternoon will fix small things before they become recurring pain points.

They build a running list of workflow gaps as they encounter them rather than letting frustration accumulate informally in Slack channels and hallway conversations. This sounds almost too simple to matter, but the organizations that keep a disciplined, prioritized backlog of items they noticed in production that the configuration should handle end up systematically closing those gaps over two or three post-go-live cycles. The organizations that do not keep this list end up re-discovering the same problems repeatedly, because nobody wrote down that it happened the first time.

And critically, they treat the post-go-live period not as a sign that something went wrong, but as the expected and necessary continuation of the implementation. This is as much a leadership and communication issue as it is a technical one. If your steering committee believes the project is done at go-live, then every subsequent configuration request looks like a failure or a scope creep argument. If your steering committee understands from the outset that configuration maturity is a twelve-month journey, not a ninety-day sprint, then the same requests look like exactly what they are, the system getting better because you are using it.

The practical implication for how you approach implementation

The advice I give lenders about to start an implementation is to resist the urge to over-specify upfront. Get the foundation right. Your core loan products. Your basic servicing workflows. The essential reporting your board, your regulators, and your funders actually require on day one. Then go live. Do real transactions. Let the operational reality of your portfolio start generating the specific questions that only real transactions can generate.

Then iterate on the configuration based on what you actually encounter, not what you tried to anticipate. This approach produces a better-configured system in roughly the same total timeline, with significantly less pre-implementation paralysis. It also produces a healthier internal relationship with the platform, because the operations team experiences the system improving in response to their actual work, rather than experiencing a static configuration that feels increasingly out of step with what the business needs as it grows.

This has direct implications for how software vendors should set expectations too. A vendor who promises that a discovery process will capture every requirement before a single transaction runs through the system is setting up an implementation for disappointment, because that promise is not really possible to keep. A vendor who is upfront that the first six months of production use will surface real requirements, and who has a structure in place to address those requirements without friction, is setting a far more honest and ultimately more successful expectation.

At FUNDINGO, this is part of why we think about implementation as a relationship that continues well past go-live rather than a project with a hard finish line. The configuration work that happens in the months after a lender starts processing real loans is not rework. It is the part of the implementation that could not have happened any earlier, because the operational knowledge it depends on did not exist yet. Lenders who plan for that phase, rather than treating it as a surprise, end up with platforms that genuinely fit how they operate, not just how they described operating in a discovery workshop months before they ever processed a single loan.

If there is one thing I would want a Head of Lending or a Digital Transformation lead to take from this, it is to stop treating the post-go-live adjustment period as evidence that something was chosen wrong. In nearly every case I have seen, it is evidence that the organization is finally using the system the way it was always going to need to be used, and is now positioned to configure it accordingly.