The SecOps Cloud Platform for Product Builders

Building a security business on top of someone else's product is a strategic mistake disguised as a shortcut. That is the real subject of this panel. Ross Haleliuk, LimaCharlie's Head of Product, sits down with two people who have actually built service offerings under load: Eric Capuano, Founder and CTO of Recon InfoSec, and Amanda Berlin, Lead Incident Detection Engineer at Blumira. The conversation is framed as a tour of the SecOps Cloud Platform's benefits, but what the two operators keep circling back to is a harder question. When you build a security product or service, what exactly are you building on, and who controls it?

The thing you build on decides what you become

Capuano is blunt about the cost of the obvious answer. Recon InfoSec spent its early years on a do-it-yourself stack: self-managed infrastructure, open source tooling, integrations built and maintained in house. He is careful not to dismiss it. The approach was, in his words, full of wins and financially rewarding. But it carried a hidden cost in complexity. Someone builds the integrations, then troubleshoots them when they inevitably break, all while a security operations business has more important fires to fight, namely actual customer incidents. He puts a number on it later: the team was spending 30 to 50 hours a week just keeping the underlying infrastructure alive.

Berlin describes the same trap from the entry point most builders recognize. You start with free and open source components because you know what you want to do, then hit the limits the moment you try to shape the experience your customers expect. Each accommodation adds another integration, another fix, another thing to deploy and document, until managing the toolchain competes with the product you are supposed to be shipping. For a service provider, that is not just annoyance. It is margin leaking out the back and innovation that never happens because the team is too busy keeping the monolith happy.

The deeper version of the argument is about dependency, and Capuano states it as a principle. The last thing a product builder wants is to build on top of other products, because then you are at someone else's mercy: their license model, their billing, their pricing, capabilities they could withdraw at any time. He draws the contrast with AWS. You do not pay AWS license fees for features they might take away; it is a neutral service provider whose only business is infrastructure, and EC2 instances will always be there. He wants to build on an abstract, agnostic service layer with that same posture, where his success is not hostage to a vendor's success. An enterprise can stitch a dozen tools together behind a SOAR and make it work. A product builder cannot build an offering on top of a traditional EDR or asset management tool without inheriting its constraints.

Scale should be boring, and so should the bill

The clearest evidence for the argument is what changes at scale. On a monolithic, self-hosted setup, Capuano admits that signing a large customer became a source of anxiety: take this account on and does it break our infrastructure? He names the absurdity directly. No one running a business should be afraid of winning a big, awesome customer, yet rigid infrastructure makes that a real fear. On an on-demand, scalable cloud foundation, customer size is the last thing he thinks about. He could bring on an account 15 times larger than his biggest one with no concern, because it does not change the math.

Cost is the other half. The old infrastructure produced dynamic, per-customer costs, where some customers cost more than others and figuring out whether the service was profitable was genuinely complicated. A fixed cost model retires that problem. As Haleliuk reframes it, you stop scaling the technology and start scaling the things a business should scale: support, documentation, edge cases. The freed engineering time did not evaporate either. The people who had kept the monolith running shifted to building customer-facing applications and shipping the feature requests customers actually asked for, work that had stagnated under maintenance load.

Berlin adds the point most worth weighing before a migration. Adopting LimaCharlie was not a like-for-like swap. It forced Blumira to rethink how it ingests data, and the rethink made the internal process better overall. The new capabilities mattered as much as the time saved. Capuano calls some of them daydreams the team simply could not have built before, regardless of available hours: on-demand hunts and response actions triggered directly by detections.

Real time is the capability, consolidation is the wedge

Those capabilities show up where it counts. Berlin describes automatically isolating a host on a detection, a file written to an internet-facing application server triggering a quarantine that cut the attacker off before the compromise spread. Capuano's case is a ransomware engagement with a brand-new client. IR usually means arriving after the damage and performing a post-mortem to find root cause. This time the team caught a system mid-impact, rapidly deployed the EDR agent, pulled the indicators off the affected host (the malware, the command and control, the persistence mechanisms), and crafted detection and response rules on the spot. Those rules then fired on other systems where the attacker had already begun moving and quarantined them instantly. The lesson separates real-time telemetry from a traditional IR toolkit: most tools do autopsies, while real-time streaming and response let a team move at the speed of the attacker.

The API-first design is what turns those capabilities into a product. Capuano interrogates systems in real time through a single API call to populate inventory databases, then surfaces that data to analysts and to customers directly. Most of his customers are IT teams who do not care about the SOAR and EDR machinery on the back end; they want simpler answers about their environment, and the exposed APIs let Recon build exactly that into a customer-facing application. As he puts it, the only limit is imagination, because the platform stops being just a security tool.

That leads to the panel's sharpest practical point, the one Berlin surfaces and Capuano calls the golden issue: in this industry, agent is a four-letter word. Customers resist stacking endpoint agents, and every service provider shows up wanting to drop yet another one. If a single agent covers RMM, CMDB, and asset management on top of solid EDR, a provider can collapse five agents toward one. That consolidation is both a sales advantage and a way out of the brittle external dependencies the whole conversation warns against.

The case for speed follows from all of it. Fewer interfaces, fewer vendors, fewer agents, fewer learning curves. Berlin offers the concrete proof: with only a handful of people, Blumira built a full integration with its product in roughly three to three and a half months, crediting both the API and the documentation. The economics lower the barrier to even starting. Capuano remembers the old reality, where the pay-to-play minimum from a big-name SIEM vendor targeting MSSPs was high enough that you would lose money every month until you signed three, four, five customers. Usage-based pricing inverts that. You can onboard a 15-endpoint customer, deliver the service without losing money, and grow from there. For anyone weighing whether to build a managed offering, his point is that the bar has never been lower, and the thing keeping it low is that you are no longer building on something you do not own.