Podcast with a founder of BriteCore, the platform for P&C insurers trusted by 80+ clients across USA and Canada: Achieving growth with the help of technology 

The DICEUS team is excited to share with our audience the interview with Phil Reynolds, a founder and former CEO of BriteCore, and CEO of DevStride. Illia Pinchuk, DICEUS CEO, and Kateryna Monastyrska, Head of Sales and Marketing, talked with Phil about his experience running a large company providing a first-class software solution for P&C insurers across USA and Canada. You will surely find here a lot of valuable insights on technology, innovations, and the latest trends in software engineering for the insurance sector.

Illia: Hi, Phil. I’m thrilled to have you as our guest on this podcast. You, as a former CEO of BriteCore, a fully managed platform for P&C insurers, obviously have a great experience in software development and insurance. Can you please tell us a little bit about yourself and your career in the insurtech sector? So, you know, just our audience would better understand yourself. 

Phil: Of course. And thanks for having me on it. I really appreciate it. My background, I started in 2005. I launched a company that then ultimately became BriteCore, which is a court administration suite for property casualty insurers. That company was bootstrapped for a number of years and then did a series seed round, a series A, and a series B. 

I was at the company for 18 months after series B, at which point I left to go, and started a new company, DevStride, which is where I’m at today. But for 16 years, I was the CEO and founder of, I guess, the third largest P&C administration provider in North America. And so, I was always a very technical founder or product-led founder and picked up a lot of lessons along the way, and, you know, learned some things that I hope benefit me in my future business at DevStride.  

Yeah, yeah, perfectly. So, we obviously, well, for the ones who don’t know, we worked with Phil. I think we met in 2016. So, prior to this call, I actually checked my mailbox just to see when we actually met each other. And it was in 2016.  

Phil: Wow. I can’t believe it’s been that long already.  

Illia: So, what was the BriteCore’s size when you partially quit the company and left the CEO position?  

Phil: Yeah, so a number of things changed, and this is a journey that I think most founders go through. If you go down, pursue the path of institutional capital, and the nature of the business shifts at the point that you have capital partners, and BriteCore was culturally at a place, where the board and the investors had a vision they wanted to go execute. That really was best served by a new manager to come in and sort of like run the company and take it in that direction. And I visited with a lot of founders subsequently, and, you know, virtually everyone who goes a funding event like that, a big one where there’s, you know, liquidation and an exit and all those things, experience is a similar thing. I don’t think that’s bad. 

I think that that’s good, but the board just wanted to take the company in a different direction than sort of where I was envisioning and leading. And probably most important is that the organization is an organization and it supersedes anyone individual. And so, if the board decides instruction, they want to go, I wanted to be very supportive and back that, and I still am the chairman of the board at BriteCore, and so I, I still have a hand in it and, you know, do my best to advise and oversee things. 

But yeah, just sort of reached that point where after series B, there were new ideas, new visions, new strategic directions. They wanted the team to go. And another manager ended up being the best person to lead that charge. 

Kate: Phil, the BriteCore platform is trusted by many P&C insurers across North America. And what unique functionalities does it provide? Did you probably invent something new?  

Phil: Oh yeah, we did a lot of things. We were very innovative at BriteCore. Probably the most meaningful among those is that we built this system with meaningful guide rails, in the setup and configuration of the system. 

So, the large upmarket competitors like Guidewire or Duck Creek, those systems require a much heavier weight implementation compared to a system like BriteCore, which we built to be implemented very rapidly. And so, you know, I think today they’re at the point where the average implementation is taking, you know, a matter of weeks, and their system, you know, companies are totally live with fully featured, end-to-end policies, admin claims, statutory accounting, reporting. All of those things are configured and ready to go in a matter of weeks. And that is a very different experience than you have if you go to implement one of the much larger enterprise solutions that exist upmarket.  

Illia: And what was actually the core functionality of your system? What your customers loved the most? 

Phil: Oh, well, I mean, I think the fact that we did everything and now it’s a question whether it was brilliant of us to do everything, or was that ill-advised, I don’t know. Our problem domain is very large BriteCore managed policies, claims, billing, mobile app, agent portal, accounting and reporting, and all the vendor integrations. I mean, like, this just goes on and on. There were 43 individual discreet services deployed as the BriteCore platform, along with hundreds of integrations on the backside. And so, so we really, our, our scope was vast.  

Illia: Okay. And you also mentioned mobile applications. What was that? What kind of mobile applications? 

Phil: Yeah. So, well as you know, DICEUS has helped us build and manage the mobile application. Yeah. For quite some time. And the targeted mobile app was specifically there to deliver a policyholder experience. And so, yet again, another competitive differentiator for BriteCore is that in all those other systems, you have to go to a dedicated, you know, mobile app developer to build some kind of custom policyholder portal. 

And we built BriteCore in such a way that we could deploy and launch a live policyholder portal out of the box with the systems. As you configured the backend system, you were simultaneously configuring an agent experience and a policyholder experience. And those apps were all preconfigured, pre-compiled with just launch with your system. 

And so, it was yet another way that we offered an accelerator to the carriers who were trying to, you know, roll out digital transformation strategy across their entire book of business.  

Illia: Well, seems like all those components came to the market actually to your customers not on day one, right? It was like a continuous process. So how often did you release those improvements and new features to the customers?  

Phil: So, we utilized a continuous release process, and so BriteCore would ship source code 10, 20, 30 times a day. And we were always on a process where we would push updates, and we did that by trying to build a mature QA suite. I think also in my newer company DevStride, I’ve actually migrated back away from that strategy a bit and have moved instead towards a biweekly release so that you’re still getting a very frequent release for customers, but you have a little more time to do packaged QA as opposed to only automated QA. But we released regularly and customers saw new features go out the door, literally hourly, at BriteCore.  

Kate:  Phil, are software integration and scalability capabilities important for BriteCore customers in particular and in any insurtech products in general?  

Phil:  Well, all of those things are very important for customers. In terms of scalability, customers want to know that as their business grows, the system grows with them. And so, the way that we handled that at BriteCore was and is a fully native AWS solution. 

And so, you know, the data stores relying on, you know, I think we were using serverless Aurora at the point in time that I left. I’m unsure if they’re still using that as the primary transactional database, but Amazon services are designed to scale. And as long as you build to those and use them correctly, many of your workloads on a big SAS platform just scale up and up and up and up. 

Of course, there are always challenges with reporting and things like that around scaling. So, it’s not like it’s perfectly smooth, but it generally worked really well. Integrations for another huge component because despite our very large scope, and as far as I know, BriteCore has the largest scope of any solutions provider in the P&C space. 

We sold whatever things we couldn’t do. So, for example, um, we did not want to do like risk scoring and so we integrated with a vendor called Hazard Hub. And we didn’t want to do, you know, printing solutions. And so, we integrated with a vendor called Mass Printing, and there were, you know, a bunch of those that, that we worked with over the years. 

So, integrations ended up proving very valuable, very critical as well. So yes, we had to think all the time about both scaling in integrations and a wide range of other concerns.  

Illia: How many clients have you had in BriteCore?  

Phil: As of the date that I left, we had 87 carriers using BriteCore  

Illia: 87 carriers. Well, this is actually a huge number of carriers, and I believe while each implementation is huge, it’s not just like a couple of hundred dollars projects, so they are much bigger, right? 

Phil: Yes. They’re large.  

Illia: Yeah, I can imagine. And obviously, each of those carriers had some requirements, like it might be even functional and non-functional requirements like security, maintenance, and performance. How did you manage all these things for different customers?  

Phil: Yeah, first of all, it was a great challenge, and that leads directly to what I’m doing today with DevStride. It was always very difficult to manage that. You have a dimensional problem in your project management, when you run a solution like BriteCore. Big banking systems have this problem, hospital systems have this problem, anywhere where you are managing work streams across product teams, but also the effort that you’re expending in each of the product teams is in service of a big enterprise implementation, right? So, you’ve got the product roadmap and the customer roadmap and those things intersect somewhere, and you have to determine whether or not this feature will be done by this product team in time for this commitment to this customer. 

 And what we discovered was that all of the tooling that existed in the world was terrible at this and it does not do this well. So, a Jira, Click up, Monday, you know, Asana. None of them do this well. And the problem we went to solve with DevStride was this exact problem because we always struggled with it at BriteCore. 

It was very difficult to manage, timelines for a product roadmap and also timelines for a customer roadmap. And we were very fortunate that just through an incredible staff, we managed to do that successfully most of the time. But there were certainly some stumbles along the way, and dates would slip and things would get missed. And that was frequently very expensive for us at BriteCore. And so that’s why I’ve moved on to DevStride to solve that exact problem.  

Illia: Yeah, exactly. And who are BriteCore’s biggest competitors in the US market?  

Phil: So, upmarket, the biggest competitors are Guidewire and Duck. Those are the two big ones. As you go on down market, then you start running into like Majesco, Insurity or Gum Risk Sectra. There are several other vendors in that space that all, you know, off or core services where BriteCore really didn’t have a major competitor in a lot of ways, and BriteCore very rarely lost. None of those other solution providers actually provide the full stack. So, if you’re going to, you know, for example, Socotra, who has a great platform, I think Socotra is a really great team, good platform, solid, like the people that are wonderful. We rarely competed for business because they are offering a platform-first solution that is really just policies and rating and for the most part. 

So, if you were looking for just policies and rating and you were going to build your own front end, then Socotra is a logical fit for you. If you were looking for a full solution as a service, then BriteCore was a better fit for you. And so, you know, we really did our best in our sales process to not just tell every customer we could do everything for them. 

We tried to actually help match customers to the appropriate vendor. And so, as to the best of my knowledge, I was a steady source of… I should have been probably getting a commission as a channel partner for all of my competitors because if you weren’t a great fit for me, I would quickly refer you on to a vendor like Origami or SE Cochair, or someone else. 

Illia: In BriteCore, you were proposing to your customers both the front-end side and the core business implementation, right? So, on the front-end side, I assume it was customer-like portal, like web solutions or mobile solutions?  

Phil: Yeah. So, BriteCore is designed as a modern web service. So, it is all backed by an API. And so, you could go out and build your own UI that simply talk to the BriteCore service on the backend, however, in practice, we had no customer that did that because our UI was excellent. Our UI was very good, it was very quick, it was easy to use. And so, when people sat down and did the calculus on, I could go spend $5 million building a UI to talk to this web service, or I could use this UI that’s free, it’s baked into my system. 

People always used our UI. And so, we ended up with a range of our change requests, and the sort of implementation features that would be asked for all the time were more new capabilities in the UI. And also, when we deployed a new feature, we never just deployed it as a web service. We deployed both the backend capability and updated the front-end UI to match so that we still had an end-to-end solution. Yes, there was a platform underneath it, but really everyone used us as a product.  

Kate: It looks like the solution was built in a professional manner, but what were the biggest business and technical challenges for you in developing BriteCore?  

Phil: Yeah. Well, several, so the very largest is, again, the solution I’m offering at DevStride goes to solve the single biggest core challenge I had at BriteCore, which is it was very, very difficult to manage customer implementation timelines, overlaid on product roadmaps because the number of dependencies that you’re sort of tracking there is vast, and the surface area is very large. So that was the biggest business problem that we tried to solve at BriteCore for 16 years there. 

And as far as I know, the team is still always wrestling with that, and all of the competitors to BriteCore are always wrestling with that. It’s a very hard problem to solve. That’s why I’m trying to solve that problem. We also had a couple other challenges that were secondary. I would say, probably, the next largest challenge was that carriers, as general rule, are not big technology spenders, and they have a very modest budget relative to their technical appetite for product. 

And so, operating a business with a healthy margin was always very challenging because insurance companies ideally want to pay you as little as possible, and they want you to offer, again, policies, billing claims, statutory reporting, agent portal, policyholder, portal actuarial predictions, reinsurance integrations. 

There’re all these things. And they don’t always want to connect that, “Hey, I need to pay for someone to think about all these domain problems, and so my price needs to ratchet up as the domain gets larger.” And we spent a lot of time trying to help educate customers on what the real economic drivers were of the requests they were making. 

And hey, if we add this new capability to the platform, that’s great. We can do that. But once we do it now, someone has to keep an eye on it all that time. And as with DICEUS, once we launched a mobile app for policyholders, then from that point forward, we had a team of six or seven that was full-time managing that product because we had launched that product and someone had to pay for that. 

And so that was always a challenge as well as helping the customer understand like where the resources were going and what it truly required in order to launch a new capability and then sustainably manage that capability into the future.  

Illia: Phil, well, as I know you are an engineer, well, besides that, you are an entrepreneur, and I’m sure that you understand well the financial sector, recruitment processes, operations, and insurance. So, you are an expert in different areas. Well, because we are all entrepreneurs who should be experts in different fields. But, first of all, as I know, you are an engineer because you graduated, if I’m not mistaken, from the Massachusetts Institute of Technology, right? 

Phil: Yeah. So, I’ve done a lot of continuing ed executive education through Sloan, at MIT. I don’t have a computer science degree from MIT. I wish I. But yes, I am an engineer by background and yes, I do have overlap with the MIT crew there.  I’m a highly technical founder.  

Illia: But did you experience any failures while you were executing with your team the BriteCore project? Can you talk about some of them? 

Phil: So many, yes. So many failures. I mean, that’s, you know, anyone who tries to portray their path to success as a straight line is almost certainly lying to you, unless you’re the luckiest human being that ever, you know, lived. That’s not the way it works. And so, business is so much about hypothesis, forming a hypothesis and educated hypothesis around what you think is going to happen if you take a certain set of actions, and then measuring the result of that set of actions, and being very nimble and ready to pivot all the time and always be pivoting because things change. 

Things that you thought were true aren’t true. BriteCore had many mini fits and starts among them; let’s see here. For a random example, at one point in time, we had some large customers who came to us and wanted some capabilities that simply the rest of the customer base would not be willing to increase their recurring support fee to fund because they didn’t need the feature. 

And so, we tried to push that across the line as a base capability. The customers were just like, we’re not paying for that except for these two or three customers who really needed it. We ran a hypothesis that we could branch the source code. And have a group of customers on a branch of the source code, a variation of the source code that had these capabilities in it, and then we would be able to just merge back to this branch and pull the updates in. 

Well, in practice, over time, that branch slowly diverged away from the main development branch more and more and more. The cost of merging those things back became so high that just wasn’t worth maintaining the branch anymore. That was a notable mistake in our history and we debated when we did it, it was even a good. 

It did, however, solve a customer problem for four or five years. Very, very capably. But after four or five years, that solution almost just folded it down on itself because there just, there was too much divergence and it was too expensive to maintain and synchronize those two branches. So, we ended up with almost two versions of BriteCore deployed out into the wild. 

So that is a great example of something we tried. It did, in fact, sort of work. It solved a problem, it generated some revenue, solved a customer need, but ultimately led down a blind alley. So today, the BriteCore team has, you know, merged everyone back into Master, and everyone’s on the same resource code branch and all. But for a while, we had sort of an offshoot happening to try to solve a problem, and it ended up not being a great, great idea.  

Illia: Yeah. I actually watched your previous podcast with some other guy. I just don’t remember his name. And you said to him that if you knew all these mistakes now and if the development technology were at the same level as back days as they now, BriteCore might be 400% bigger than it’s now.  

Phil: Oh, easily, yes. No, no. I feel 99% confident; 100 is always too high. I feel 99% confident that if I could reset the clock and reimagine BriteCore, starting from day one with what I know today, BriteCore would easily be a unicorn. Now it would easily be a billion dollars. And actually, I really felt like we were on a path to achieve that anyway on our current, on where we were leading previously. So yeah, there, I certainly, hindsight is always 2020. That’s a saying for a reason. And you know, we all don’t know what we don’t know. 

And we look back, and we’re like, oh God, if I would’ve just known X, Y, or Z, I could have done this thing. Of course, the challenge is no one gets to know that, you know, I would be the most brilliant investor in the world if I could know what the stock market was going to do. If I could rewind my investments from a week ago and know what the stock market was gonna do, yes, I would be the richest man in the world. 

But no one gets to know that. You have to predict, and I think it is a trap. I try to always steer executives, staff, new founders. Anyone that will listen to me in business, I try to show them away, is I try to steer people away from arm shore quarterbacking or Monday morning quarterback. There’s a lot of, a lot of phrases that, you know, looking back into the past to advise people. 

Well, I always knew whatever because, no, you didn’t. And you know how, you know, you. Whatever you thought, you knew; whatever you thought, you didn’t do anything about it; you didn’t fix it, which means you didn’t really know. It means you had doubts. There were reasons to be uncertain. You maybe been sitting up and screaming at this thing, but you didn’t build the influence you needed to convince the team to do whatever. 

And so, what really occurs in the real world is messy. And it’s complicated, and you’re going to make mistakes, and that’s fine; it’s totally fine. Everyone else is making mistakes too. You just make ’em faster than everybody else and be nimble and pivot and move on.  

Illia: I totally agree with you. And how many people and teams did you have in BriteCore back days?  

Phil: Yeah. So, there were 43 product teams. Our staff was 360 at the point in time that I left the company  

Illia: 360. Wow. Why so much?  

Phil: It, again, our problem domain was massive. You know, each one of those teams, so as you know, the mobile app team had seven people. My policies team had like 19 people. My claims team had 14 people. The data team had 15-16 people. The DevOps team had almost 20. So, you know, we just have all these different domains that have to be, you know, attended to. And so, this challenge of running a core solutions provider is your scope is so large, and you are the core utility. So, you know, it’s one thing. The scale of impact is very different for solutions providers like BriteCore than it is for a point solution. So, you could almost liken it to something if you’re a non-technical, you know, the listener to this podcast. 

You know, it’s one thing if you go to your favorite restaurant and it is open for an afternoon because the power got disconnected, right? Somebody hit a line out back and you can’t eat your burger. Ah, no big deal. You walk next door, and you get a burger, right? But if the utility goes down, then the entire city’s out of power. There are no burgers for anyone and everyone starves. BriteCore was the utility. BriteCore was the rails that everything else wrote on. So, it took a big staff and a lot of intellectuals, you know, power to keep the utility running all the time. We were a big enterprise company.  

Kate: Would you recommend that insurance companies build their own ERP platforms or use existing solutions or solution providers?  

Phil: Building your own solution is almost always a mistake. Not always. There are a couple of use cases where it’s not. And the reason I say that is it took a staff of 360 people to maintain a system is unless you are a big enough team. Now, if you’re, if you have a thousand engineers and you are exceptional at hiring, and you can bring in domain experts for policies, claims, billing, all these different things, then yeah, you could actually would have the demand power to build your own solution that may be the best choice for you cause there is margin inherently baked into a vendor. 

However, I would say the vast majority of insurers, their expertise is in insurance, not in technology. And they’re not going to run a great technology shop. And so, they should probably go to a trusted provider because I can tell you the number of product mistakes I made and the number of times I had to rebuild the same application five or six times until we got it right was numerous, very expensive. 

And you know, by the time I left BriteCore, we had spent just shy of 150 million in R&D over the years to get New Build. And so most carriers do not have the skill, the expertise, the know-how, or the budget to absorb that, or the timeline to absorb that. So, most of the time, building on top of an existing provider is going to be the better choice. 

Now, that is no longer the case. If a) your company is huge, as I just talked earlier, it might make more sense to build or b) If your use case is sufficiently unique. So, the trade-off in going to an existing solution provider is that they have a model for how insurance works baked into their system. And they have, you know, there are capabilities in their billing system and there are capabilities that don’t exist in their billing system and pushing a change into an existing platform. 

The utility, as we were talking about earlier, the utility doesn’t just switch voltages randomly, right? Like, like it’s a big process to make a change to a utility. It’s the same thing if you go to an existing solution provider. Making a change is a big deal. So, I say all that to say if you were, for example, today, a new insurtech startup. You were about to go insure, you know, ride share scooters or internet of things devices or something in some way where the model of your rating, your underwriting, your renewal, all those things was sufficiently different from existing business. 

Then it also might make a lot of sense to build your own system because it may be that, that the inertia and the assumptions baked into an existing platform are, are too diverse, and it’s too expensive to change it. So, and you know, and needs analysis is wise anytime you go to, you know, embark on a project like this, so you really understand the drivers. But I would say that for the majority of carriers, buying is a significantly wiser decision.  

Illia: But, did you face any carriers over this, like 20 years’ experience, who decided to go on their own and create their own platform instead of using like BriteCore or similar type of solutions?  

Phil: Yeah, so we saw a couple who did, and we had several, many of them failed. Most of them failed. Okay. A couple was successful, and the ones that were successful did this. Here’s what they did. They all did the same thing. They came to another vendor or us, but frequently us first. And they used an existing solution for a year or two to get off the ground, so they understood the mechanics because we were able to, if you do something like turn on a solution like BriteCore, you inherit 20 years of operational excellence on day one because the system only lets you bill in a sensible way. 

You can’t make stupid mistakes in your billing cause it does not let you make stupid mistakes in your billing. So, there’s a lot of operational discipline expertise that you are able to pick up by implementing a solution like that. And then specifically, so like we had one of our customers, Abay, was a BriteCore customer for a while that eventually moved on. 

And they moved on because what they’re doing is cyber risk and they have a unique underwriting model that is based around like intrusion detection and other things like that. And it is sufficiently different from the existing P&C carriers that were our bread and butter at BriteCore, that they actually could go build a system more cost effectively. 

But they did that after using an existing solution provider for a few years to figure out how to insurance and once they knew how to insurance, then they went and built some custom solutions. Then they were very successful with that, which was an excellent decision for them.  

Illia: Yeah. Well, this is very clever. Phil, if we can just maybe back to your team and how you structured your company? So, I know similar companies to yours, to BriteCore, they structured the team’s technical department in the following way. They have two different departments. One of them is like core product development, and another one is like professional services or implementation department. So, did you have the same?  

Phil: So we did. And, yet again, tying back to why I’m doing DevStride today, that was at the core of the conflict that we were always trying to resolve, which is, are we mapping work at BriteCore by product? Or are we mapping work at BriteCore by customer? And if you do either it is a fatal flaw to the other side of the house. If you organize everything around products, your customer experience suffers greatly. You focus all your work around your customer implementation projects, they tend to go better. 

But the product you’re left with on the backside is far less scalable and re-sellable, and the business starts to collapse around that side. So yes, we had both. It did not work well to have both, and we really always wanted to implement both a product R&D work stream and a service implementation workstream through the same domain expert. 

So, I have like one rating team, and that rating team is both doing core R&D and implementation. And that was always what we wanted to do in terms of where it touched source code, where it touched you, new capabilities. Now, where that’s not the case where, and that’s why we built DevStride, is to solve that exact problem. If you were listening to this podcast and you have a conflict where you have multiple product teams, you’re trying to figure out what we are getting done for this customer or this key stakeholder across all these product teams, DevStride has a solution for you. That’s what we’re doing. 

But there is a division there where it can make a lot of sense to have them completely separated up. And that is if your core platform has all the key capabilities necessary and new customers coming through the door do not need new features out of your system. And for BriteCore at this point, cause the system has now been around for a long time, it now has, for example, all of the core capabilities you could dream of for a regional farm, or mutual insurance company. 

They’re all there. There’s nothing new to be built. You just need to implement it. And when you’re implementing, you’re not touching code. There are no new capabilities. It’s simply an exercise to go in, use the configuration, and utilities, configure the system and deploy it. Then it is a much smarter idea to run services through a dedicated service department because there’s no competition for priority and you know, all the heat and the cost and the expense and the P&L and everything tied to a product team doesn’t impact that service project. 

So, I guess that’s a long-winded way of saying it depends. If your implementations require technical debt, I think it is better to have a unified cross-functional team that can do both R&D and implementation services. If your implementations do not contain significant technical debt, then I think it makes more sense to implement it through a dedicated implementation services team. 

Illia: So now I understand much better what is DevStride is about. I might have a few customers for you.  

Phil: Yay. I would love that.  

Illia:  Phil, if just coming back to the implementation of BriteCore customers. So did you face any challenges, and what was it like, well, how long does it take to implement BriteCore? If possible, maybe you can share even the price of it. 

Phil: It’s always undergoing modifications, and I’m no longer the operational manager of the company, so I have to be cautious. What sort of like pricing and timeline? Cause nothing I say today would be a prediction of the future. 

I will say that the system is priced around an attachment point to direct written premium that has continued to be for the moment. The best measure of roughly how much it makes sense to charge a customer is if you are a $10 million carrier versus a hundred million dollar carrier. You have a different price because you are roughly 10 more times the work, if that’s roughly your policy count. 

Now there are variations within that. That’s generally how the code system is priced. The implementation timelines have gotten very compressed at BriteCore. So, one of the big successes I can tout on this podcast for BriteCore is that BriteCore’s average implementation timeline is down to like 40 days. 

It is really quick and really tight. The reason that is the case is that BriteCore has decided to laser focus on small regional mutual insurers at the moment. And I told you earlier that all the capabilities needed by those, that particular profile, a customer, that particular target customer profile are similar, and BriteCore has addressed all of them. 

And so, they do not walk into the room with a mutual insurance company, a small regional mutual who says, can you do X, Y, or Z? And the answer is no. The answer is always yes, yes, we do all the things, we do them well. And because of that, their implementations currently are all the second type I talked about earlier where I’m just configuring. 

You see the configuration, and utilities, I push the button, I launch it, and you have BriteCore now. And they can do that very quickly. In the past, we were doing much more R&D and joint R&D as part of implementations. The implementations are much larger, much higher dollar. Bigger customers, but also much longer timelines. 

So, in the past, for example, when there was a lot of development debt that came with each new customer in implementation would take on average, about 18 months. So that was the average we were running right then. And now the implementation is literally about 40 days. 

And so that’s the difference between I’m building versus I’m considering. And then again, the system is priced as a percentage attachment point. One of the things they’re doing today that I think is very clever and very beneficial for customers is that we used to charge that upfront implementation cost as an upfront amount you to pay the company. 

Instead, they are now offering, and almost every customer is accepting instead, a tradeoff, where instead of charging a big, you know, bucket up front, they are assuming BriteCore is assuming the risk offering the services frequently but in exchange for a higher attachment point on that recurring revenue, a greater percentage of your direct written premium. 

And what it does for the carrier is it de-risks the upfront project, the project doesn’t go well. Carrier never starts paying that recurring fee, and therefore, they don’t care. But if they do, and BriteCore is successful, and everyone’s incentivized there. Britecore is to generate more money in the long run, which then supports, to my earlier point, better R&D, more sustainable processes moving forward, which is good for everyone. 

So, I think the model they’d move to there, where instead of charging a bunch of upfront services, they are baking that into higher attachment points, is a very good move and a very smart idea.  

Illia: Phil, if back to the implementation of the core platform to the insurance organizations. From my experience, implementing core platforms for different companies doesn’t matter where this is, the insurance company or bank, or retail. They typically have something in common and it is like a core platform and then a middle layer. Well, the integration level. Typically, they use something like the MuleSoft or Informatica or something like this. So, did you have any standard integrations or connectors to such kind of middle layers in BriteCore?  

Phil: Yes. BriteCore had, again, as of my departure as CEO, we were sitting on over a hundred integrations that we had built, that we fully maintained on our own. We built the value prop, we built integration. It was fully supported as part of the base platform. So, we did not go through middleware. We actually built integrations directly. Now there has been a lot of evolution technically, which I think, you’re pointing to there, and you all know in the timeframe, actually, since I left the company two years ago, the low code, no code movement has really taken off. 

And as a result, there are many more services like Zapper, which automate API to API. So, one of the moves that BriteCore may very well adopt in the future is instead of building integrations and maintaining them directly, they may decide to go to more like a MuleSoft sort of, you know, like someone who is a broker between the APIs. And that may be what they end up doing, that’s undecided yet.  

Kate: And by the way, if you, coming back to implementation, you mentioned that you do it very quickly, very fast. Did you use implementation partners, or did you do everything on your own?  

Phil: We would use them occasionally. It was always fastest and best if we did it ourselves. Because we knew our system better than anyone else. There is that equation is not the same. For Duck Creek Guidewire, the much larger carriers in frequently, EY, PWC, Accenture, Deloitte, those companies are out there who do big implementation services. 

They actually tend to work well for those companies, because their solutions are very large and the dollar figures tied to their implementation projects are very high. And so, there’s enough margin in it that the SI partner, that’s the solution integrator partner, wants to go invest. 

The challenge BriteCore always had was we were serving the smaller mutual insurance industry, and therefore anyone, customer’s, service contractor was not large enough to move the needle for EY. And so, EY didn’t want to invest heavily into that customer, and therefore we were always much better doing it internally because, you know, our average implementations were $800,000 and EY is looking to make five to ten million in just services, you know, in a year. And so, so it is just a scale mismatch.  

Illia: Yeah, this is clear and makes sense.  Phil, so now, while you already mentioned that mobile application and customer portals, well, actually, the whole front office is something like what the insurance companies would like to have from you, but and they allow it because it’s free of charge. They don’t need to spend this 5 million to build it. So, is it a mandatory request, which you were getting from leads, or is it just like a nice-to-have feature and, maybe, other requirements that you faced, except these core platforms were mentioned typically in RFIs? 

Phil: Optional. Frequently a big carrier like Liberty Mutual or USAA or someone like that, they have entire teams devoted to their mobile app, and they’ve got that IP is internal to the company, and they just want to interface with your backend provider, the backend platform as an API, as a platform, your API calls. So, in that case, it would be very, for all of them; it is not, is so optional that many of them do not offer a mobile app whatsoever because other customers would use it. Conversely, BriteCore was offering the full solution as with a platform and a product. And so inherent in the, as a product part of that is that we had to have a bundled packaged agent portal, policyholder portal, all those things. 

So, it was a mandatory requirement for us. Which goes back to the earlier question about monetizing everything correctly. The BriteCore problem domain is actually significantly larger than Guidewires, and that boggles people’s minds. But it’s true, BriteCore’s product is a much broader, wider workload, with a lot more detail. 

Cause our customers could not help themselves frequently, technically. And so, they needed us to do it for them. So, for us, it was mandatory, but for larger upmarket customers, it’s not mandatory and, in fact, not even desired. So, it all depends, again, on who your target customer is; what does your target customer profile look like? 

And really listening to the needs of the customers, understanding the capabilities of the customer so that your solution can map to those needs and capabilities.  

Illia: Now it’s clear. If you talk a little bit, not about the BriteCore, but about just the overall insurance market and insurtech market. Are you familiar with such insurtech startups like Hippo and Lemonade? What do you think about those projects? Are they real competitors to insurance organizations? I mean, traditional insurance companies?  

Phil: They are real companies. They could not be less of a concern to the carriers. They’re not a competitor in any way whatsoever. And here’s why. Those companies are, I guess Hippo, are actually different. So, they’re both a little bit different. Those companies have not continued to scale over time. If you watch their growth curve, it has kind of flattened a lot in the last year, and in fact, even negative in some. 

And it is because there are a lot of reasons to add. I don’t know why; I’m not a truth-sayer of all of insurance and economic activity. I believe that the reason is that there are only so many people who want a technical insurance policy. My case, for example, and I am the chief technologist out there. Like, I don’t really care if you give me a prettier website for my insurance. I just wanna know that if I get in a car wreck, you’re gonna pay my claim. And so, technology matters, but those companies tend to lead with technology, and frequently, they are not. 

And I’m not sure exactly what the authority structure is at both Lemonade and Hippo. However, frequently those companies are just MGU, managing general underwriters, where they are still giving the business to a carrier. So not only is the carrier not worried about them, they actually just, the carrier is them, they’re the ones actually backing the risk. 

And so frequently, the insurtechs are just a pretty layer over the top of a real, you know, entity that’s issuing coverage. And so, where, I think, the carriers would start to feel very threatened is if the insurtech movement had given rise to an entirely new form of insurance that no longer relied on the carriers. 

But at the end of the day, the insurtechs are still relying on the carriers, right? The insurance. Because to write insurance, you have to actually be domiciled in this state. You have to be authorized by the state. There’s a lot there. And the insurtechs, by and large are funded by VCs and private equity who don’t want to take on that complexity. And so, I don’t think the carriers are concerned at all.  

Kate: And would you recommend traditional insurance companies to digitalize engagement with consumers as he or Lemonade do, or should they do absolutely even something better? 

Phil: Well, I would say they should. And I would say that to back up the value prop of Hippo, Lemonade, and others like them, I would highly recommend that a carrier who likes what they’re doing, just go acquire them. Because there is the capability valuable to the end consumer, but no, many of those companies are not really set up to do all the regulatory root compliance and all the various insurance jurisdictions. 

And so, so I think the carriers would be wise to purchase someone who knows how it’s going or hire up significantly internally use firms like Illia’s firm in order to help them build out those capabilities. Because there’s no doubt that the carriers who build better consumer engagement platforms are, in fact, winning the overall game. 

Absolutely. I think they should do that and they should offer it. And it’s a question of whether they also buy or build at the organizational level.  

Illia: Very good answer. Thank you very much. Phil, so, BriteCore is the core product, right? And basically, well, the product which you have built is a technological heart of the insurance organizations, you know, well, as no one else does. What are the biggest challenges that insurance companies face these days?  

Phil: Well, the biggest is certainly relative. I can share some of those that are large. Insurers find it very difficult to predict what new consumer buying patterns and consumer drivers are going to move the needle. And because they are inherently domiciled in these different state departments, there’s the massive technical infrastructure behind what they do. It is not easy for an insurer to innovate and be nimble and adapt because there are a lot of enterprise concerns on the backside, like statutory reporting and PCI compliance and GDPR and all these different things that they have to think about every time they make a change. 

And so, so that is certainly an ongoing struggle for insurers is just predicting our consumers going to want point of sale, renter’s insurance, you know, in some hot new, you know, mobile app where people are not renting their apartments right from the mobile app, that kind of thing. That’s very difficult for insurers. 

Another huge component is that insurers are faced with – they are not private equity-backed companies just trying to get public, and everybody walks away. They are longitudinal organizations. They frequently been around for a hundred-plus years. They plan to be around for another a hundred years. And so, they have to think about the true sustainability of their upgrade path, their upgrade cycle, and that is a tremendous pain for them. 

And then this year, this actual calendar year happening right now, we’ve seen interest rates start to climb. Reinsurance is be, is flipping into a one of the hardest markets carriers have ever seen. That’s happening a lot as we speak. And so, bringing carriers are starting to experience an essential threat to their existence if they’re a smaller carrier where reinsurance is becoming prohibitively expensive or totally inaccessible. 

And so, that is a need that needs to be addressed as well. And so they have need to demonstrate to the carrier all the reasons that they think they’re not going to experience disastrous losses in the coming year. And then, they need the ability to better underwrite their platform and identify the bad risk so that they don’t experience those losses so they can continue to get reinsurance. 

So, those are a handful of the challenges, but for every carrier, it’s different, you know, there are as many answers to that question as there are carriers out there.  

Illia: I have one more interesting question for you. So, if you were the CEO of a tier-one insurance company, with all these problems, what would you change as a first technology-wise? 

Phil: The first thing I would do is I would make sure I would actually take a playbook from Jeff Bezos at Amazon going back to 2006 and say, your department can do whatever it does. I’m not going to micromanage what you do, but you have to expose everything you do through an API. And I would make it such that if you want to end, you know, generate an invoice, there’s an API call to go generate the invoice. And I don’t even care what backend solution you’re on, it can be a black box to everyone else about how it happens, but you need to be able to do it. And here’s the spec. So technically, I would make sure that all of my departments had a well-formed, well-documented API, for pushing workloads in and out of that functional area of my company. 

That is the first thing I would change because once you get that lined out, there’s so many things you can do with, again, low code, no code, automation platforms, new vendors, data analytics, all these things you can do. But you have to start by saying it’s fundamentally the data and the ACT actions here are fundamentally accessible to the web. 

Kate: And what new technologies would you recommend them to implement or what technologists can bring the utmost value in your opinion?  

Phil: Well, of course, a modern solution provider is tremendously helpful. Someone who can expose all their capabilities via an API and make everything accessible and be those rails, all the automations and insights right on. That’s huge. Of course, there are providers like BriteCore that do that. BriteCore’s an excellent solution and excellent, you know, vendor for you to talk to, though, of course. There are other great ones. So, Coach is good or Gum Risk is good. There are great solution providers outside of BriteCore and it’s just a big question of which one matches your needs, you know? 

Well, there are others that I would recommend, which is, for example, I would not have my data in like one of these old like I would not have it all going to like Excel somewhere. Excel’s a terrible, terrible choice for data for an insurance company.  

There’s no QA suite on Excel spreadsheets. And so, your ability to make a, to totally unintentionally misinterpret a cell to misarrange accidentally type over the top of a calculation or something and reach fundamentally unsound conclusions is huge. So, like another, there’s a bunch of examples of this, but another sort of like point solution example is, I would forbid Excel in my company and say we’re going to use a real code-first platform, data solution so that we can do QA suites on this and we can pull analytics and all the things we need at scale. So, that’s another example of the kind of thing that I would come in and do.  

Illia: Thank you, Phil, so much for all these comprehensive answers. I appreciate it. Please tell our audience a little bit about you and your journey with DevStride.  

Phil: Dev Stride is doing a project to portfolio management. So, what we do is we help complicated delivery teams deliver on time. That’s really what we’re doing. And so, we lived the pain ourselves for many years of managing a bunch of parallel work streams and those parallel work streams were in service of big customers go live. And so that can translate to any of the other solution providers out there like your Guidewire, Duck Creek or Majesco or of them. 

They’re all solving this problem, but so are the technical teams inside of big carriers. So, you know, in a big carrier like Liberty or USAA or State Farm, there are these product teams who are delivering capabilities, and now the enterprise needs to pick up. And then, various initiatives within the enterprise require new capabilities from the product team. We are really trying to provide true management and visibility across complex parallel work streams. That’s what we’re doing, and I think we are killing it. Our platform and our product are amazing. The early users that we have been experiencing, so I’ve got some early stats, very early cause we’re very early in our journey. 

But it’s currently, we’re getting really close to a 30% improvement in time-to-value cycles because we’re just able to show people things that are breaking down sooner. They’re able to find out something’s off track way earlier and go in and resolve it right from within the tool. So, that’s what we’re doing now. 

And, of course, I would love to visit with anyone who’s listening to this podcast and is trying to manage parallel work streams cause my heart goes out to you. It’s complicated. It’s a hard problem to solve, and I’ve got a tool to help address it.  

Illia: And that might be the best question for you in order to sell the company and explain the difference between Jira and DevStride. 

Phil: That’s what we let you see across multiple projects. If you go implement a solution in Jira, Click up Monday, there’s a bunch of tools like that. You fundamentally start by building a project, and then you assign people to the project and put work in the project. 

And then all works great as long as your domain lives in that one little project; you’re good to go. But the moment you’re a CTO, you are a VP of Architecture, you are Ilia, and your team doing work for a bunch of different carriers everywhere. It is now immediately impossible to see things like, what is our cycle time for defects across this whole swath of products or how are we doing for, what does our burn down look like for customer X across 20 different product teams? That’s what we’re solving. That’s what Jira, Monday, Click up don’t solve. We solve that problem.  

Illia: So, you show the company’s management the helicopter view of everything that is going on inside the development team. 

Phil: That’s right. Teams. So, we have a workflow tool that replaces Jira, and it’s an awesome project management tool for individual contributors. But the ultimate benefactor is the key stakeholders who need to understand how we are performing across all these different works. 

Illia: Super. So, I would lovely recommend your new product to the potential customers.  

Kate: And good luck with your new product.  

Phil: Yes, thank you. Same to you all. You do great work. And for everyone listening, I have worked with Ilia and the team at DICEUS several times in the past, and they have performed spectacularly, and they have my full endorsement.