Pablo Fernandez

Tag: saas

  • The SaaSpocalypse is real, but not for the reasons you think

    , , ,

    SaaS valuations dropped. The narrative is simple: AI lets anyone build anything, so why pay for software? They’re calling it the SaaSpocalypse.

    I think part of it makes sense. But a big part of it doesn’t.

    You don’t buy code, you buy decisions

    When you buy a piece of software you’re not just buying the code. You’re buying the decisions that shaped that code. What to build, what not to build, how to model the domain, which tradeoffs to make. Those decisions were valuable before AI and they are still valuable today.

    This is why I think we’re entering the era of product managers. They are the ones making those decisions. And those decisions require deep domain knowledge. Gaining that domain knowledge is not trivial.

    The Fusion test

    Let me make this concrete. I do 3D design for 3D printing. It’s a hobby, not my life’s work. I use Autodesk Fusion.

    Should I vibe code my own 3D design tool instead?

    Vibe coding something equivalent would cost far more in my time and token spend than the Fusion subscription. But cost isn’t even the main problem. The main problem is that I don’t know the domain.

    Fusion has a specific set of tools for creating 3D designs. It starts with parameterized 2D sketches, from which you build parameterized 3D shapes. Choosing the right set of primitives to manipulate 3D geometry inside a computer — flexible enough to be useful, constrained enough to be learnable — is not trivial. It probably took the industry years of trial and error to get here. I remember the primitive AutoCAD of the 90s. We came a long way. I would have to replicate that trial and error, and that is not cheap.

    Technically, I could ask an AI to clone Fusion. But that is only possible because Fusion exists. You could argue that’s fine, it exists today. But next year, Fusion will have evolved. Without Fusion pushing the domain forward, there is nothing to clone.

    And no matter how good I am at building Fusion with AI, the people at Autodesk would be better at it. They have the same AI tools, but more domain knowledge.

    This generalizes

    Pick any domain and you’ll find the same thing. I wouldn’t want to vibe code my accountancy software, or my email client, or my calendar. Don’t believe me? Think about how you would represent recurring calendar entries where each recurrence can be individually rescheduled. This is not a trivial problem.

    For some tools, the domain is trivial, and the code was the moat. That moat is gone. The drop in valuation for those companies makes sense. But when the moat is decisions, taste, or domain knowledge, it’s still there.

    The real SaaSpocalypse

    The real SaaSpocalypse is not customers vibe coding their own tools instead of buying them. It’s the new startup that vibe codes a competitor.

    The real danger to Autodesk is not me building my own Fusion. It’s someone who dedicates their life to 3D design building a competitor with AI.

    That newcomer would have an AI-friendly codebase from day one. If they invest in keeping it that way, they would add features much faster than Autodesk can on top of decades of tech debt.

    The real SaaSpocalypse is that you can now catch up to and surpass incumbents with less effort, fewer people, less investment. And the incumbents, to fight that off, will need to rebuild their internals to be AI-friendly. At some point — as crazy as it sounds — it might be faster to start from scratch than to evolve an old, tech-debt-laden codebase.

    Buy vs. build still applies

    At work we recently needed a tool. It was going to cost us tens of thousands of dollars. An engineer proposed we vibe code it instead. I seriously considered it. We understand this domain much better than I understand 3D design, and for internal tools you can move fast when security constraints are lighter.

    But it would have taken us 2 to 3 weeks. And during those weeks we would not have been developing our core product. Our unique differentiator is our own product, not a tool we can buy and use off the shelf. Our competitors can buy that same tool and have it running in hours. We shouldn’t spend weeks to get there. Focusing on our core product was the right call.

  • When raising prices is easier than lowering them

    , , ,

    When you are building a B2B SaaS product it’s very hard to know what the appropriate price for your product is. Even if you magically found the correct one, it might not be the correct one next month when you made the product better and you are providing new values. That’s why you need to be constant experimenting with prices on your app.

    When I started my career I was afraid of raising prices, of having to justify why they went up (I wasn’t even aware of grandfathering). When I started to learn that most entrepreneurs set their prices too low, my partner and I decided to set the price too high and then lower it if it was necessary. Without realizing we painted ourselves to a corner.

    We didn’t want to just lower prices, we wanted to experiment with prices (switching from per-user to 3 plans, things like that). The problem was that anything we would come would cost a different amount for each customer. For some customers it would go up, and that wasn’t a problem, because we would grandfather them in. But for some customers it would plummet.

    There were two options for those customers:

    • Lower their prices according to the new plans and lose the revenue.
    • Don’t lower their prices and risk them being very angry about overpaying.

    Because we were a bootstrapped startup living month to month, every time we discussed this we would get stuck in a cycle of what-ifs one or the other situation. Eventually one day we made a rule of forbidding talking about pricing (trying to get some work done, because we would spend days and days discussing pricing).

    Eventually I found myself wishing that instead of starting with a high price and lowering it for experimentation, that we started with a low price and raising it for experimentation. We would have experimented much more. There’s another obvious solution which is not depend on the sweet revenue of those high prices. But even though it’s simple, I don’t think it’s easy… like sitting in front a pizza and not having a slide. Yeah… right!

    Next time I want to increment prices over time and even then try to give myself room for experimentation.