Why frameworks are having a moment

(and why it matters for lending)

For the last ~40 years, enterprise software has been oscillating between two instincts:

1. Freedom — build exactly what you need
2. Simplicity — buy something that already works

What’s interesting today is not that frameworks are “back”, but why they are back.

The short answer: AI is changing the trade-off curve.

Let me rewind.

1. Before SaaS, before platforms: everything was custom

In the early days of enterprise software, the “platform” was basically the operating system, a compiler, and discipline.

Teams implemented everything themselves: lifecycle, UI events, state handling, persistence, error recovery, permissions, deployment.

This worked — but it didn’t scale.

Every serious application was re-implementing the same structural concerns. The industry needed a way to standardize structure, not just reuse snippets of code.

2. Frameworks: standardizing structure instead of rewriting it

One of the earliest examples of an application framework is MacApp, released in 1985 — an object-oriented framework for building desktop applications on classic Mac OS.

Its importance wasn’t the language or the UI toolkit.

It was the idea that:

Most applications share the same skeleton. Business logic should plug into a predefined structure.

That idea matured over decades.

In the web era, Ruby on Rails (2004) became another milestone. It demonstrated that if you standardize conventions around models, workflows, persistence, and lifecycle, teams can move dramatically faster without losing control.

Frameworks succeeded because they did two things at the same time:

• reduced entropy by enforcing structure
• preserved transparency — engineers could still read and reason about the system

Then the pendulum swung again.

3. SaaS: standardizing the product, not the structure

What most buyers call “SaaS” today is not just a delivery model.

It is a finished application with predefined capabilities.

Your freedom lives inside:

• configuration screens
• rule builders
• workflow designers
• low-code / no-code tools exposed by the vendor

This model exploded in the late 1990s and early 2000s. Salesforce, founded in 1999, is the canonical example.

SaaS optimizes for:

• time-to-value
• operational simplicity
• reduced need for engineering teams

And for many problems, that trade-off is excellent.

Until differentiation appears.

The moment your business logic stops fitting neatly into the vendor’s configuration surface, the system starts pushing back.

4. Low-code / no-code: a real trend — and an illusion of simplicity

Low-code and no-code are not fake trends. Adoption is real.

Gartner projected that by 2025, 70% of new applications developed by organizations would use low-code or no-code technologies.

But adoption does not equal elimination of complexity.

In practice, low-code / no-code systems usually SHIFT complexity rather than remove it.

They create two very familiar user profiles.

The technical specialist

Engineers and solution architects can build almost anything — but only after:

• learning a proprietary DSL
• understanding opaque runtime behavior
• navigating extensive documentation
• debugging outcomes rather than code paths

At that point, many engineers ask a simple question:

Why not work with code or a framework I can actually read and test?

The business specialist

Business users are promised independence, but face:

• hundreds of configuration options
• unclear cause-and-effect relationships
• difficulty understanding what should be configured in the first place

Low-code does not remove the need to understand the system.

It often pushes that responsibility onto people who were never meant to carry it.

And when a low-code tool is truly simple, it is usually simple because it is constrained.

That is not a flaw. It is a design choice

5. Lending exposes these trade-offs immediately

Lending systems are not simple CRUD apps.

They are long-running, event-driven systems dealing with:

• origination and underwriting paths
• complex integrations
• servicing schedules and recalculations
• delinquency, collections, recoveries
• fees, penalties, waivers, reversals
• regulatory and audit requirements
• constant exceptions

This is state-machine territory.

When logic becomes opaque — hidden inside configuration layers or vendor code — teams lose the ability to reason about their own business.

And when you cannot reason about the system, you cannot change it safely.

6. Why frameworks make sense again (even without specialized AI)

Frameworks sit in the middle:

• more flexible than rigid SaaS applications
• more structured than building everything from scratch
• readable, testable, auditable

AI has made this middle ground far more attractive today.

A controlled experiment by GitHub found that developers using Copilot completed tasks ~55.8% faster than those without it.

According to Stack Overflow’s 2024 Developer Survey, 76% of developers are using or planning to use AI tools, and 62% already do.

At the same time, trust remains conditional — many developers report concerns about correctness and reliability.

That nuance matters: AI accelerates execution + Frameworks provide guardrails.

Together, they increase speed without turning systems into black boxes

7. The bigger future: framework + AI as a real system-building experience

The most interesting shift is not “AI writes more code”.

It is AI becoming the interface to a framework-native platform.

Imagine the following setup:

• You have a framework with carefully designed primitives:
• On top of that, you have a conversational agent that acts as your personal CX with:

This agent:

• gathers requirements
• actively challenges them (which usually leads to better products)
• implements logic on top of the framework
• generates tests
• packages the application as a deployable container
• delivers the full codebase for audit and review

This is not about hiding complexity.

It is about making complexity navigable without sacrificing transparency.

__________

“Frameworks are a step backwards. This is 50-year-old technology.”

Electric cars were experimented with in the early 1900s.

Progress is not about novelty — it’s about when the surrounding ecosystem becomes ready. Cloud infrastructure, modern tooling, and AI are what make framework-native approaches viable at scale now.

“If this is so good, why won’t all low-code SaaS vendors switch to it?”

They could — but it would fundamentally change their business.

A framework-native product is not a configuration-heavy app with extensions; it is a platform. Moving there usually means rebuilding the architecture, pricing model, go-to-market, and customer profile. That’s not a feature update. That’s a new company.