Rebuilding ProChamps for scale
A legacy operation was rebuilt on OutSystems into a scalable SaaS platform that grew from 44 to more than 300 municipal clients, grew recognized revenue from roughly $800K to about $8.4M, and returned more than $45M in registration fees to local governments.
Context
ProChamps operated in a regulated public-sector market where the platform had to support municipal programs, high-volume registration activity, and reliable service across a growing client base. The platform's job was civic as well as commercial: collect property registration fees on behalf of municipal programs and return the majority to the communities.
The existing operation had reached a point where the technology and delivery process were becoming constraints on growth. Release cycles were long. The platform needed a stronger architecture. Sales needed confidence that the product could support larger commitments without creating another technical bottleneck.
My role
I led technical operations during the rebuild.
My responsibility was not the company's revenue strategy or the exit itself. My responsibility was to create a platform and delivery system that could support the company's growth, serve a larger municipal client base, and withstand the technical review that came with a transaction.
That included the rebuild of ProChamps 2.0 on OutSystems, architecture and reliability decisions, delivery-process changes, and support for due diligence and platform migration planning. It also meant carrying a commercial load. In a company this size the technical lead runs demos and solutioning alongside sales, which I did for municipal accounts including Hillsborough County, Palm Beach County, and the City of Riviera Beach, and contributed requirements and validation to the data purchase negotiations the platform depended on.
What changed
I dismissed OutSystems in the initial research. It looked like a Lego-block platform, suited to small internal tools and unable to carry the data volume and complexity we needed. The alternatives on the table were Mendix, a few other vendors, and building our own stack and SDLC from scratch. What changed my mind was evidence rather than a pitch. At an OutSystems conference in the US, a European insurance company presented the data volume and operational complexity they were running on the platform. If they could hold that, we could hold ours. The distinction I had missed is that OutSystems is a full SDLC and not simply a low-code tool, so the real question was not how fast we could assemble a first version. It was which delivery system we wanted to run for the next decade.
The legacy operation moved to a scalable SaaS platform on OutSystems. The architecture was designed to support a growing municipal client base and higher transaction volume without treating every new commitment as a special technical event. The rebuild included a 50TB database migration executed with zero downtime.
The team moved from release cycles measured in months toward a shorter, repeatable delivery rhythm. Jira and Scrum were introduced to make work visible, reduce the delay between decisions and releases, and give the business a more predictable path from request to production.
The technical function had to become a system that sales and operations could trust. Reliability, capacity, and release discipline were not back-office concerns. They were part of the company's ability to sell, retain clients, and support due diligence. The commercial side compounded it. Pipeline conversion rose 76% on new forecasting tools, the client base grew from 44 to more than 300 municipal contracts, and client retention held at 100% across five years while the company captured the market before competitors recognized it existed.
Municipal contracts served by the platform.
Registration fees returned to local governments across my involvement.
Release cycles shortened from about four months to about three weeks.
SQL Server to MySQL migration completed with zero downtime.
Private equity sale in 2019, with the exit completing in 2020.
I led the technical operations and the rebuild, and none of the numbers above are mine alone. The engineering team across the US and Portugal built ProChamps 2.0 and moved 50TB without taking the platform down, while the support and operations team kept hundreds of municipalities running through the whole migration. The company achieved the revenue growth and the exit.
What it changed in my thinking
Technology is not separate from the operating model.
A stable platform changes what sales can promise. A visible delivery system changes how the business prioritizes. Architecture changes the cost of the next client. Reliability changes trust. Due diligence reveals whether the company has built an asset or accumulated a dependency.
The lesson was not that every company should rebuild its platform. The lesson was that technology decisions become company decisions long before a transaction makes that connection obvious.
The platform call compounded further than anything else I decided there. I was evaluating OutSystems against the code we would write, when the question was the operating system we would have to run. That correction became the foundation of the decade that followed, through a public-sector product portfolio, a university curriculum, and eventually enterprise go-to-market.
Have a similar operating constraint?
Describe the stage, the system, and what is not moving. I will review the message directly.