I am surprised so many people don't understand the business model of Bending Spoons or are bewildered by it.
In conventional infrastructure and product development you need engineering staff to build the product; once the product is built you need very little engineering. If you build a house you don't keep the builders on payroll once it's built to keep "building" it - you may need maintenance staff but that's it - if you need to keep the full team of builders around then something is wrong and you may want to seek a refund for the original builders' fees since they did not actually finish building it.
Builders and electricians and tradesmen either work as contractors and take that into account (charging higher rates to compensate for the sporadic nature of the work) or work full-time for companies who then resell their services on building projects (charging accordingly to ensure there is enough revenue to pay a full-time payroll of said tradesmen).
Tech was an outlier in this case because ZIRP allowed companies to retain full engineering teams to keep "engineering" the product even once product-market-fit has been achieved and the product has been stabilized and finished. This gave a lot of engineers the illusion that perpetual "engineering" of a single product/service is a sustainable model and career.
Bending Spoons' business model is to buy finished products, cut off the deadweight and keep operating the product and actually making profit off the finished product, which was always a normal thing in every other industry.
For tech people that see themselves as builders, this should be normal and expected - they should charge competitive rates for their services taking into account the expectation that they're building something for someone else to make money off once it's built and that they won't be part of it once that's done (unless they want to negotiate an actual stake in the company). For tech people that don't, this is a difficult wake up call, but the earlier the better - the old situation was never sustainable to begin with.
The economics are different because the industries are fundamentally different. Software is never "finished" the way a building is finished. More features can always be added to software. If those new features create new product lines and attract new revenue, then the software engineers' salaries are more than paying for themselves.
But, this obviously carries risk, that the new thing you develop won't be worth as much as you spent. Bending Spoons doesn't want risk, hence their decision.
It’s a mystery to me, almost every product on market has serious user-facing issues that never get fixed. As if every company indeed have no development team, while all of them retain teams of developers.
Exactly why I charge $999/hour for my software consulting. To the doubters, laugh all you want, but I've been doing this for literal decades, and will absolutely slaughter LLM generated code in terms of code reliability and maintainability amortized over 5 years.
The fact that it's the norm for the builders of mature software to stick around can lead to some gross engineering inefficiencies. For instance, a lot of Evernote's backend infrastructure was manually managed [0]:
With Evernote, Bending Spoons identified that the backend needed a complete rewrite. They moved from a monolithic architecture running on manually provisioned virtual machines to a microservices architecture with managed databases, significantly improving performance and scalability.
It's easy for companies to fall into such pits of inefficiency because climbing out of those pits entails utterly gutting the headcount [*].I wonder if the same is true at Vimeo, which employed ~250 engineers [1], which seems high for a mature product that's deliberately conservative (most of Vimeo's customers are B2B whitelabelers, for whom a constantly changing product is a massive downside.) It's not like video codecs or storage systems or web standards are changing daily. I would imagine a well-engineered codebase from 10 years ago would work well today with only minimal changes, mostly centered around updating libraries for security patches. The fact that they had 250 engineers on staff who presumably did more than play ping-pong all day makes me wonder if the codebase was not, in fact, well-engineered.
[0] https://www.colinkeeley.com/blog/bending-spoons-operating-ma...
[1] https://www.unifygtm.com/insights-headcount/vimeo
[*] Imagine the equivalent for a building: "we don't have automatic circuit breakers in this building; instead, we have a 24 hour staff of electricians who measure current with an ammeter and manually cut the power if it gets too high."
If you build a house you don't keep the builders on payroll once it's built to keep "building" it - you may need maintenance staff but that's it
A very analytical, technological, short-sighted view of things. But not necessarily how the customers think.
For many customers, a company that isn't growing is shrinking. If a company isn't willing to invest in growth, that's a red flag.
I mentioned the Vimeo thing in a meeting this morning, and the head of Communications immediately said he's going to start looking for alternatives.
You can make all the analogies and excuses you like, but look at Vimeo's sister properties (Evernote, etc.) Are they better off since they were gutted? Are they delivering more value to the customers, or just funneling money to the parent company and its investors?
I think a better analogy is some big Wall Street investment company buying up nursing homes, and making lots of noises about "efficiency." That never works out well for the patients/customers. Only for the company.
I don't think you need ZIRP or even VC to have successful software companies that reinvest in features. You need a low marginal cost of manufacturing, aka the floppy disk.
I think you're entirely correct.
I put it to not-tech people as: "[insert_ridiculous_valuation] is because you can fire everyone tomorrow and keep operating"
> "Tech was an outlier in this case because ZIRP allowed companies to retain full engineering teams to keep "engineering" the product despite it being essentially finished."
This is wrong, though, it's unnecessarily tying in a pop-finance obsession with ZIRP.
Unnecessary is the right word because it's not necessary for the rest of your post, you could cut it out and it wouldn't affect your argument or anyone's understanding.
Wrong is the right word because the dynamics it assumes are fantastical - companies took on debt to fund bloated engineering teams because no one noticed the engineering was done?
Additionally, ZIRP didn't induce this, this stuff happened, exactly the same, during ZIRP as well. Saw it in the iPad point of sale industry in early to mid 2010s.
A real finance nerd would point out ZIRP would in fact induce more of this behavior. It makes it cheaper for private equity/entities like Bending Spoons to take on debt to buy out companies and strip mine them. (strip mine being my word for this behavior)
I think a better analogy than building construction is cars. You need to do active maintenance and fix things on cars to keep them running, you may even change out a radio or wheels, etc. like minor feature development, but you're not likely to change out the design of the engine and transmission. You definitely don't need the design crew from the car manufacturer around, aka Product Mgmt, to do maintenance but you do need some semblance of a tech team or people that can do the tech work on contract.
At some point a tech product is "finished" as in a mature, stable product and adding new things to it isn't going to do 10x in revenue. Its probably really hard for the product and tech teams involved to admit though.