The same cost savings could be captured by SaaS. Potentially not by incumbents, but by up and comers.
If you can spend $10K/year to keep your in house one alive but $5K/year on the new SaaS option, you stop building your own again.
The same cost savings could be captured by SaaS. Potentially not by incumbents, but by up and comers.
If you can spend $10K/year to keep your in house one alive but $5K/year on the new SaaS option, you stop building your own again.
Possibly, but I don’t think it’s certain. For a SaaS to capture, you’d need a forward deployed engineer model. And then I would have ten different FDEs to liaise with, none of whom know my domain.
Vs if I contract a shop, then I have a dedicated team ramped up on my domain who then can vet infra providers and choose the best tech. So potentially still some SaaS, but probably shifting more to PaaS.
Similar to how you don’t hire your Salesforce or SAP contractors from these companies, I would predict this model spreads to other platforms too, and may make OSS viable in more places.
I think with a SaaS you're trading user research and workflow design for a certain lack of customization, and that for 90% of businesses that will remain the right call. (And for the ones where it's not the right call, I think the contractor model also makes more sense than in-house LLM-generated-user-tool teams. That's a lot of code to pile up under a very small team for long-term maintenance. Yeah, "the agents can do it," but you're making ever-more balls that the people overseeing the agents will have to juggle over time.)
If you're selling honey online, say, how bespoke does your inventory management tool really need to be? And are there no lessons you'd learn from a SaaS tool that you'd not have thought of on your own?