The Problem Is Not the Technology. It's the Gap.
Nobody designed it that way maliciously. Legacy systems accumulate. Mergers happen. New products get bolted onto old platforms. And at some point the architecture that made sense in 2009 becomes the single largest constraint on the business in 2026.
The problem wasn't the technology per se. It was the gap — between what the platform could do and what the business needed it to do. And that gap was widening every year.
Why Visual Basic Becomes a Talent Problem
The pool of developers who are comfortable building and maintaining Visual Basic applications is shrinking every year. Junior engineers don't learn it. Senior engineers who know it are increasingly concentrated at larger enterprises that can pay to retain them, or they've moved on entirely.
What this means in practice: a carrier running a critical production application on VB faces rising maintenance costs, increasing risk of knowledge concentration in one or two people, and a genuine inability to attract the engineers who could grow the product. The technology choice becomes a hiring constraint. The hiring constraint becomes an innovation constraint. And the innovation constraint becomes a competitive one.
This is not a hypothetical. It's the situation the carrier in this story was in when the conversation about a new platform began.
What We Actually Built — and Why It Was Designed That Way
The directive was not to replace the backend. This is important. The core rating systems, the policy administration layer, the integrations with downstream services — all of it was working. Imperfectly, with workarounds, but working. A big-bang replacement of functioning infrastructure is the kind of decision that looks bold in a boardroom and lands badly in production.
Instead, the approach was API-led: build a new frontend and middle layer that sits cleanly on top of what exists, exposes the bundled product to agents the way it should always have been exposed, and routes data through a centralized Rules Engine that handles eligibility and pricing logic in real time.
How API-Led Connectivity Changes the Agent Experience
In the legacy stack, an agent creating a multi-line quote did three things sequentially: open application one, enter all client data, proceed to the end. Open application two, re-enter the same client data, proceed to the end. Open application three. Repeat. Each flow had its own data model, its own validation logic, its own pricing moment at the very end — by which point the agent had already invested twenty minutes they may not be able to get back.
In the new platform, an agent enters the insured once. The application routes that data via API to every relevant line — Workers' Comp, BOP, Cyber — simultaneously. Shared data is shared automatically. Line-specific fields appear only where they're needed. And at every save action, the platform calls the Rules Engine and returns a real-time eligibility update. The pricing update is returned in real time via Raing API.
The agent sees the quote evolving as they work, not only at the end. If a data point makes the quote ineligible — a payroll figure below the minimum threshold, an address that doesn't qualify for the program — they find out immediately, not after completing the form. Decline codes are surfaced inline. Refer statuses are flagged for underwriter review. Bind-eligible quotes proceed cleanly to policy creation.
The Rules Engine: Centralizing What Was Previously Scattered
One of the structural choices that made the new platform work is the centralized Rules Engine. Rather than embedding eligibility logic inside each application — where it inevitably drifts, gets duplicated, and eventually contradicts itself across products — the Rules Engine holds the canonical version of business rules for multiple applications simultaneously.
When a user saves data on any page of the platform, the application sends a request to the Rules Engine with the current state of the quote. The Rules Engine runs the data through every relevant rule, returns a status, and the UI responds accordingly. This is infrastructure. But it's the kind of infrastructure that makes everything else more reliable, and it's the reason underwriting decisions can be surfaced in real time rather than at the end of an already-completed workflow.
The Rules Engine also belongs to a broader API ecosystem. It's not a module inside the application — it's a separate service that other applications in the carrier's portfolio can also call. This is the promise of API-led connectivity: you build a capability once and make it available everywhere it's needed, rather than rebuilding it, differently, in each new project.
The Rewrite Nobody Planned — and How the Team Delivered It Anyway
Two weeks before the end of 2025, the team received new information: they were abandoning OutSystems, the low-code platform that had served as the frontend layer, and rewriting the entire application in Angular. The timeline was January through April 2026. Four months.
There were reasons for this. OutSystems licensing is expensive. The platform imposes constraints on what developers can do and how fast they can work. As new features were being added and the class code coverage was expanding — from restaurants to Office, Retail, Wholesale, Contractors, and Auto Service — the cost-per-feature of the low-code approach was rising. And with Angular developers more readily available inside the carrier's own engineering teams, transitioning made the platform easier to staff and extend going forward.
How a Team Self-Trains in a Running Production Environment
The team had no prior commercial Angular experience. This is the kind of fact that tends to surface in post-mortems, framed as a risk that should have been caught earlier. In this case, it's better framed as a constraint that the team worked around deliberately.
Critically, the backend was left untouched. The team that had built the original application knew the business logic, the edge cases, the reason certain fields behaved the way they did. They brought that knowledge into the Angular rewrite and carried the new developers through it. Domain knowledge transferred laterally. The technical stack changed; the institutional understanding of the product did not.
Four pages were developed in parallel. By March, four of five pages were in active testing — one already fully closed. The QA and business analyst teams reported that the Angular version was noticeably faster than its OutSystems predecessor. The OutSystems licensing cost was eliminated. And the application that went to production in spring 2026 was the same product the agents had been using — just faster, more maintainable, and built on a stack the carrier's own engineers could extend without external dependency.
The Client Relationship: What Honest Partnership Actually Looks Like
The original version of this application was built under pressure. Two Symfa engineers — including me and Gleb, who split his time across two projects for the same carrier simultaneously — joined a project with one developer on the client side, designs and authorization in place, and a two-month go-live deadline. Shortly after we joined, the client-side developer went on paternity leave for six weeks.
Roughly 75% of the first production version was delivered by Symfa. The carrier's IT Director sent his thanks through the account manager afterward. The feedback was that this kind of commitment from an outsourced vendor was something they hadn't expected and had come to value.
That's the origin of the relationship. But the more interesting question is what came after: how the project evolved from a restaurant-only bundle into a multi-industry workflow covering five class code groups, and how the team that built it stayed through the transition — OutSystems to Angular, two months to two years — without the institutional knowledge walking out the door.
The carrier also invited Symfa teams to participate in an internal AI hackathon — competing alongside their own engineers and other vendors to build AI-powered tools with measurable business impact. The winning proposals would go to production. The fact that a software engineering partner was included, not just invited to observe, says something about how the relationship had matured.
On the Distinction Between Vendor and Partner
There's a structural difference between a vendor relationship and a partnership, and it shows up most clearly when things go wrong or when the requirements change unexpectedly. A vendor delivers against a spec. A partner holds the broader context and flags when the spec might be wrong.
The Angular rewrite decision is a good example. The team didn't just execute the migration. We had enough product knowledge to understand which backend behaviors the new frontend had to replicate exactly, which OutSystems-specific quirks could be dropped, and which seemingly minor details — the way shared data propagated across lines, the order of Rules Engine calls on save — would break the agent workflow if they got them wrong. It's not something that appears on a project plan. But it's often the thing that determines whether a rewrite succeeds or fails.
Business Value: The Only Metric That Matters
The application went live. It is used by agents and brokers daily.
Production defects were minimal. The Rules Engine surfaces ineligible quotes before they reach underwriting. Agents are no longer navigating three separate applications for a single insured. The data that needs to be shared is shared automatically. The data that's line-specific appears only where it belongs.
What Didn't Go Perfectly
A few things are worth naming plainly, because they're real and because omitting them would make this read like a press release.
The original OutSystems decision was reasonable at the time — low-code platforms promise faster delivery, and in early phases, they can deliver on that. But the promise tends to compress at scale. As complexity grows, the licensing cost-to-value ratio shifts. The decision to move off OutSystems was correct; the cost of that decision was a full frontend rewrite under a tight timeline.
And the client relationship, however strong, is still a client relationship. Insurance carriers have procurement processes, communication chains between their engineering teams and ours. The best projects aren't the ones where nothing ever slows down — they're the ones where both sides can talk honestly about the slowdown and keep moving.
What Carriers Should Take Away From This
Legacy modernization in insurance is often framed as a binary: you either replace your core systems or you don't. The reality is considerably more nuanced, and the carriers who navigate it well tend to share a few qualities.
They don't confuse the frontend with the backend. The agent experience — the form, the workflow, the place where a quote becomes a policy — is a presentation layer. It's separable from the rating engines, policy administration systems, and data stores underneath. You can transform the experience without touching the infrastructure that still works.
They treat data integration as architecture, not an afterthought. The reason agents were re-entering data three times wasn't laziness. It was that three separate applications had three separate data models with no shared layer between them. API-led connectivity is the answer to this — but it requires discipline and a willingness to build for reuse rather than for immediacy.
They invest in the team that knows the product. The Angular rewrite succeeded because the people doing it already understood why the application behaved the way it did. That knowledge was accumulated over years. You cannot acquire it from a handover document. The carriers who treat engineering team continuity as a business asset get considerably better outcomes on transitions like this one.
They measure what matters. Not the technology — the outcome. Premiums processed. Underwriting decisions surfaced earlier. Agent time saved. Production stability. These are the metrics that justify the investment. If a platform change doesn't move them, the platform change wasn't the right one.