I think JFrog will be successful at what it does, but doesn’t excite me much. It is a process tool, not a building block.
JFrog is not a tool that enables features WITHIN the app, like the APIs and SDKs that you can use in your app as the building blocks of your application (from ESTC, MDB, SNOW, TWLO, OKTA, etc). Building blocks like these are exciting as they 1) enable the Application & API Economies and they 2) scale up as the app’s increase their usage. More success of their customers equals more revenue, because as the # of users rises, the amount of data or usage rises. These types of tools SCALE as the applications integrating into them SCALE.
JFrog is a process tool solely for developers to use. It does not scale based on # of developers, but on complexity of the application and infrastructure, and complexity of development workflow. I find process tools like this more akin to TEAM products. But even TEAM has lots of angles to pivot to from there - it can usage scale based # of team members needing to use it, and can pivot into other directions that are appropriate for other teams outside of development (IT, product mgmt, etc).
I think JFrog will have success, as development environments are constantly shifting into more complex structures (traditional stacks, containers, microservices, serverless), and so these workflows need to be tamed … but where does JFrog pivot from here? I don’t see the SCALE potential that I see in other, more building-block focused dev tooling.
Saul’s method looks for scale in the financials (revenue and customers and NRR and operations), and then I look for scale in platform (technology, platform pivots, TAM add) to lift all of that higher. Not seeing where the latter part of that equation fits in for JFrog.
I thought the company was initially compelling as it IS showing strong operational leverage with some huge margin swings, and great cust growth. But with the above, plus the declining revenues on a pretty small rev base (sub-100M per Q), and I’m not interested.
- muji