How SSLBoard Found Market Fit with Transactional Pricing and Niche Focus

The real story starts with sslping.com, a free tool to check TLS configuration I built because I needed it myself. It found an audience, people relied on it, and I killed it 6 years later for lack of maintenance. The day I shut it down, it hit the front page of Hacker News, not from a launch, but because people were upset it was gone. That reaction told me something, and it was soul-crushing. What really clicked was discovering that every certificate ever issued is recorded in Certificate Transparency logs. All of them, about 1.5 billion at any time, publicly accessible. Once I saw that, I didn't need to ask users to tell me which servers they were managing; I could find their certificates myself across their entire infrastructure, without them having to know in advance what they were looking for. That's when sslping became SSLBoard, the same depth of security testing, now combined with the ability to surface certificates that users didn't even know existed. So it started from building something I personally wanted, which is probably the most honest way a product can begin, and also the most dangerous, because you can easily mistake your own itch for a market.

The SaaS subscription model felt like obvious wisdom when I started. Everyone around me was talking about MRR, churn, and lifetime value, and nobody was questioning whether a subscription actually made sense for what I was building. It "had to work" because that's just what software companies do, right? It didn't. Users came in, poked around, and left without converting. The ones who started a free trial went quiet after a week, and I'd start dreading what that silence meant. What I've come to believe is that the world is moving toward transactional pricing because it's finally practical to offer it, and because SaaS is genuinely getting harder to justify. People are fatigued by subscriptions, and they're getting better at resisting them. If the value isn't continuous, the billing shouldn't pretend it is. That turned out to be the right model for SSLBoard, and I think it's going to be right for more software than people currently expect.

Think about the last time a Todo app on your phone asked you to create an account and sign up for a subscription before you could do the one thing you opened it to do. It's absurd, and people feel that absurdity now in a way they didn't a few years ago. The gym app, the habit tracker, the Todo app, they all want you to register and subscribe. A few years ago, they were $1 apps in the App Store, now they're $29 per year! TLS scanning is mostly periodic work. A lot of teams do it quarterly for compliance reasons or when they're planning a broader infrastructure modernization campaign. You're not spinning up new servers every day; you audit, fix, and move on. A monthly billing model doesn't fit that rhythm. There's also a broader shift happening, transactional pricing is the native model for AI agents, which are rapidly becoming the way software gets used. The idea that you pay for what you actually consume, when you consume it, is going to feel more natural, not less, as that plays out. In the case of SSLBoard, it means you'll be asking your agent to help you review your security, and it will go purchase an inventory and in-depth evaluation of your servers and cryptography. Then it will send emails or add Jira tickets for others to fix issues, and you will use it to create your report to the Board or whatever. That's transactional in nature.

People hear "cybersecurity" and picture someone technical, a developer or a security engineer (a nerd) with a terminal open. For some security teams, that's accurate. But TLS health and compliance are concerns that cut across roles (DevOps, developers, cybersecurity, compliance) in ways that word doesn't really capture, and that disconnect creates a real problem when you're trying to explain what the product does. The people who care most about TLS health and security posture are often not writing code. They're IT managers trying to get ahead of audit findings, compliance officers who need to demonstrate due diligence, and operations teams responsible for keeping infrastructure in good standing. None of them would describe what they're doing as cybersecurity, but they're dealing with exactly the problems SSLBoard addresses. When you lead with security language, you filter out a big part of your actual audience before the conversation has even started, and I've had to learn to describe the same underlying problem very differently depending on who's in the room.

I'm working on Agent-to-Agent (A2A) payments for automated, usage-based billing that fits natively into AI workflows. As more tasks get handled by agents, billing needs to match, triggered by usage, without a human approving each transaction. That's a natural fit for SSLBoard, where the value has always been transactional anyway. The subscription product I'm building alongside it is for a genuinely different use case, compliance tracking. And subscriptions actually make sense there because compliance is time-locked by definition. You're not checking once and walking away; you're maintaining a continuous posture, monitoring for drift, and tracking changes over time. The value is ongoing, so the billing can be too, and that's not a contradiction of my views on subscriptions. It's just a different problem that calls for a different model.

Three weeks after a soft launch on LinkedIn only, traffic is up every week. 25% of visitors voluntarily leave their email. 800+ domains audited, more than 100k servers checked in less than a month. SSLBoard has found demand, at last.

I had deep software engineering experience but it turned out to be a problem, not an advantage. Building wasn't "the easy part"; I hate that sentence. But the deep technical knowledge you need to have can be an obstacle when it comes to talking to customers who do not possess that expertise, you can't talk protocols and cryptography when they only need compliance. I wasn't prepared for how hard it is to get any useful signal from the market, and how much you have to fight just to learn things that should be obvious. You put something out there and people look at it and say nothing. Some tell you they love it and never come back, others say they'll follow up and then disappear. You reach out and get ghosted repeatedly, and somewhere in that silence you have to figure out what to build next. The indifference your beloved product produces in most people is genuinely hard to process when you've poured yourself into it. Getting signals you can actually steer by is war. Engineering trains you to solve problems once you've defined them, but the business side is mostly about finding the definition, and that definition keeps shifting every time you think you've nailed it.

The biggest mistake I made was treating "every company with a website" as a target customer, which felt logical because TLS certificates are universal and the theoretical audience is enormous, but when everyone is a potential customer, you end up writing messaging that speaks to nobody in particular, building features that satisfy some vague average, and having conversations that go nowhere because the person across from you can't tell whether any of this was actually built for them. The hardest thing I've learned is that people don't care about what you build, finding one specific person with one specific pain, understanding their pain well enough that your product feels like it was made for them, and resisting the urge to broaden your scope until you've genuinely nailed that first case. If you get it right, and you earn some street cred, then word travels. If you try to speak to everyone at once, you end up invisible to all.