How we built Cloud Claims and what else we’ve been building along the way
By Paul McLaughlin, APP Tech Founder and CEO
Somewhere in the middle of building Cloud Claims version 1.0, I looked at what we had, looked at what we still needed, and thought, “We’ve bitten off more than we can chew.”
That feeling passed, mostly. But I think about it sometimes when I watch a customer who’s been with us since the early days of our original Incident Management System (IMS) finally make the move to Cloud Claims. It makes me proud, not just because we delivered something good, but because we didn’t let doubt talk us out of trying.
The Case for Starting Over
Cloud-based software wasn’t a new idea in 2018, when we started building Cloud Claims. In claims and risk management, like many business areas, the access limitations of on-premises software was still a common pain point. Adjusters in the field, risk managers spread across locations, and executives who needed a view of the whole portfolio were all working around the same limitation. Customers kept asking for the ability to reach their claims from anywhere, on any device, without a VPN or a desktop install. Our IMS software wasn’t able to address this requirement. A web-based platform was the obvious answer, and we knew it wouldn’t be cheap or quick to build.
IMS had served our customers well. When it launched, it was a real step up from paper, and customers built smart workflows on top of it. But the architecture had a ceiling. Although we built a browser-based component to address the most urgent remote requirements, by 2018, we’d been bumping against that ceiling long enough to know that incremental fixes wouldn’t get us there. A full rewrite was the only real path forward.
The Two Hard Things
Going in, I thought the hardest parts would be workflow complexity and the UI. I was half right.
Claims workflows are intricate. Steps have to happen in sequence, conditional logic branches everywhere, and permissions and documentation requirements pile up fast. Years of working alongside claims teams had given us a good feel for that complexity, but it was still a bit daunting.
What I underestimated was the constraint we’d set for ourselves. We envisioned Cloud Claims as one standard platform that every customer could fit to their own operation through configuration, without custom code. That single requirement changes how you architect everything. It meant building tools that let us, and eventually our customers, shape workflows without touching the codebase. The approach added complexity up front in exchange for a much better product over the long run.
On design, one early decision saved us. We brought in an outside partner, Rossul, to lead the UI/UX work. They came in with fresh eyes and no assumptions about how a claims platform was supposed to look. We taught them the domain, they showed us our own product from a user’s point of view, and they did the heavy lifting on the design itself. When customers tell us the platform is easy to use, a lot of that credit belongs to Rossul. In a category that isn’t known for elegant software, that matters more than it might sound.
The MVP That Took Twice as Long
We planned 12 months for an MVP. It took closer to 24. Maybe 25.
That was humbling. We ran an Agile process, built incrementally, tried not to over-engineer, and kept listening to customers and prospects the whole way. None of it made us as fast as I’d hoped. We kept looking for places to automate and work more efficiently, but we weren’t willing to cut corners to hit a date, so mostly we had to be patient.
We also made a structural mistake. Parts of the codebase we’d written as one piece later had to be pulled apart so we could distribute the code more effectively in Azure. We should have seen that coming, and it cost us real development time in 2022 and 2023. The Agile discipline paid off there, because we could do the refactoring without stopping the roadmap. The team kept shipping capabilities while we rebuilt the foundation underneath them, and I don’t take that for granted.
COVID and What We Learned in a Strange Year
When COVID hit in 2020, we went fully remote for about six months. The team held together, largely because we’d already built enough trust with one another that the shift didn’t break our rhythm. Early on, sales actually picked up. Companies that were suddenly operating remotely had a strong reason to modernize their claims infrastructure, and we signed a number of new customers in that window.
As the pandemic dragged on, some customers in hard-hit sectors like hospitality, restaurants, and retail were in real trouble, and some filed for bankruptcy. Watching companies we had just started working with struggle, and in some cases disappear, was heartbreaking. It was a reminder that our customers’ fortunes and ours are tied together in ways a sales number doesn’t capture.
Managing Two Platforms at Once
You don’t get to shut down a production platform while you rewrite it, so for several years, we supported IMS and Cloud Claims side by side.
The early Cloud Claims MVP couldn’t yet handle some of our most complex customer configurations. Rather than push a migration that wasn’t ready, we sold Cloud Claims to new customers first, learned from that group, and worked toward the feature parity that would let IMS customers move over. It meant carrying two codebases longer than we wanted, and it also meant our long-term customers weren’t disrupted while we got there.
Mike’s Carwash has been with us since 2014. Watching customers like Mike’s make the move from IMS to Cloud Claims is one of the most satisfying parts of this work. Our customers place a lot of trust in us. The expectation of a software company is that it will be innovative, always creating new value. For us, it’s more than just an expectation: it’s a responsibility. We have to do right by our customers. For this reason above all, it feels good to see our longtime customers make the leap to Cloud Claims.
What We’re Still Building
Eight years in, the part of this I value most isn’t a feature or a client list. It’s what the team built while building the product. They stayed focused when the roadmap stretched. They kept shipping through a pandemic and a painful refactor. They trusted each other when everyone was remote and very little was going to plan. Software can be rewritten. That kind of team is harder to come by.
The fundamentals of good claims management haven’t changed much. The tools available to support them have, and we have plenty left to build. We’re further along than I expected to be on that day in the middle of the build, when I wasn’t sure we’d get here at all.
