9 ms·

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 develop

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.

publicdebates 9mo ago
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.
- Nextgrid 9mo ago
  Won't be giving exact figures but that's my business model as well - I charge a premium because my job for clients is to make myself obsolete. If I "deliver" something that needs my constant presence then I haven't actually delivered. Of course, my price is high upfront because I'm budgeting in the fact that I strive to be out of there as soon as feasible instead of trying to stick around. Some clients are ok with it, some don't; this is normal and what a competitive market should look like. I tell clients openly when my premium service is not the right fit for their current requirements or budget, and there are cases where cheaper labor or LLMs are absolutely a better fit (and they should come back once when/if they outgrow the cheaper, lower-quality product).
- refulgentis 9mo ago
  I'd love to do this and have a quite marketable resume, but it is extremely, extremely, unclear to me how you build a clientele or where you'd even start. Only road I can imagine is highly specialized industry, with money, that often has time-sensitive needs, and smart management that knows how to recognize value or trusts their tech management. And even then I think you'd have to start in the coal-mines version of it, $50K/year flat salary, and building a reputation without management taking credit for your successes, somehow.
  - Nextgrid 9mo ago
    The hard part is to get the client on the phone. Once you have them on the phone, you can not only better understand their problem but also demonstrate your skill and credibility in a way no resume or branding could. At that point it's just a sales game - generally you'd avoid hourly rates and sell them a solution (see my other comment) which will maximize your effective hourly rate while being structured in a way that's very good value for the client. Hourly should be a last resort, at which point generally you'd rather have the client bounce, so you quote a high rate.
    - publicdebates 9mo ago
      That last part is exactly why I charge $999/hour. I'll offer a specific solution that takes me a week of full time work (14 hours each day -- I'm focused) for about $10k, which is roughly $150/hour if you want to calculate it that way, or another specific solution that takes me 3 weeks of 10 hour days for $15k which amounts to $100/hour. And like any good consultant, I'll eat the cost if I'm wrong. Other times I'll charge $40k when I know it will take a few months of dedicated work and I have to really lock in. In practice, I never actually charge hourly. So the $999/hour is really Schrodinger's rate.
dostick 9mo ago
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.
- DANmode 9mo ago
  If you finish the backlog, you’ll get laid off, the backlog keeps being increased (by you and your manager at times), so it never gets finished. Seems easy enough to explain. There has to be a dragon being fought to account for all this money. Even if the dragon is bs.
  - DANmode 9mo ago
    Sometimes the dragon is technical debt. When you’re historical Google, building three or more competing chat platforms…? That’s pretty much bs. Downvote away, but consider a reply explaining why.
- hahahahhaah 9mo ago
  It is simple. A productive developer can either: * Fix things * Build new things Add to this that things naturally break. Try a git reset to 1 year ago and deploy that to prod, for example. Add to that new features tend to add new bugs.
refulgentis 9mo ago
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)
- Nextgrid 9mo ago
  > companies took on debt to fund bloated engineering teams because no one noticed the engineering was done ZIRP allowed a lot of "businesses" to exist that wouldn't in a conventional, competitive capitalistic environment. Businesses in quotes because there was never any reasonable potential for profitability, but it didn't matter because VC money was cheap. Building a sustainable business is hard, playing "startup founder" and having that lifestyle subsidized by VCs is easier. In that case, (over)engineering was part of the performance art that was required to keep your only revenue source: the next funding round. There was never any incentive to "finish" the product because doing that would put your business model (or lack thereof) to the test and stop the music. On the other hand, as long as cheap money is around you could endlessly "engineer" and pivot and bullshit around, chasing the next funding round and using that to pay yourself/your friends decent salaries. During the ZIRP era it was all about "engagement" and DAUs/MAUs, then it was blockchain, and now it's all about AI. For those that have run out of grifts, they fold or "incredible journey" and get sold for pennies on the dollar to entities like Bending Spoons that do notice there are bloated engineering teams that can be cut.
reaperducer 9mo ago
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.
- Nextgrid 9mo ago
  > the head of Communications immediately said he's going to start looking for alternatives. He's gonna start looking for alternatives and then most likely find nothing that matches the featureset vs price of the current solution + the cost of switching, and the matter will quickly disappear. Last time AWS or Cloudflare was down a lot of noise was made and a lot of people started looking for alternatives too - and everyone forgot about it a week later. > Only for the company. Yes, the point of business is to make profit, not to be a charity. Bending Spoons believes they can extract enough profit off Vimeo to justify the purchase price, either by reducing expenses, raising prices or both. This may still be palatable to the customers if they don't have any better option.
  - reaperducer 9mo ago
    Yes, the point of business is to make profit, not to be a charity. No one said it was. Where do you see that in this thread? Bending Spoons believes they can extract enough profit off Vimeo to justify the purchase price, either by reducing expenses, raising prices or both. This may still be palatable to the customers if they don't have any better option. Just listen to yourself. "Extract enough profit," "raising prices," and ending with You don't like it, too bad. You sound like the taxi industry before Uber. This the type of thinking that gave us Windows 11, Adobe, and every other piece of technology that started good, but became crap. It's also the reason new companies suddenly show up and eat the incumbent's lunch. Happens every day. I'm glad I don't work for you or your company. I have pride in my work. I wouldn't want to be just another tool to "extract" things from my customers because "they don't have any better option."
MontyCarloHall 9mo ago
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-manual https://www.colinkeeley.com/blog/bending-spoons-operating-ma... [1] https://www.unifygtm.com/insights-headcount/vimeo 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."
- CiccioNizzo 9mo ago
  > 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. And accidentally turned it into a shitty product in the process :-)
  - johnnyanmac 9mo ago
    "accidentally", huh. Such a charitable take. Well, the goal of the optimizations wasn't to benefit the customer or even make the app faster. It was to make it easier for a skeleton crew to maintain. If that chopped out a few features, oh well.
wavemode 9mo ago
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.
- f33d5173 9mo ago
  The businesses they acquire are ones whose revenue has not appreciably grown in many years. They are being sold because the prior owner does not believe they can improve the business any more. Any profit bending spoons earns they can run off and invest in another business if they like. They don't bother investing in the businesses they purchase because they believe, like the previous owner believed, that there is no more juice to squeeze from that particular lemon.
  - specialist 9mo ago
    Just like Computer Associates. https://en.wikipedia.org/wiki/Computer_Associates https://en.wikipedia.org/wiki/Computer_Associates
  - johnnyanmac 9mo ago
    >Any profit bending spoons earns they can run off and invest in another business if they like And the ones who helped make Vimeo what it is? left out in the cold to fend for themselves. This is why loyalty is dead. Maybe if this billion dollar aquisition benefitted the workers there'd be less hard feelings, but that's not how capitalism works.
    - senordevnyc 9mo ago
      And the ones who helped make Vimeo what it is? left out in the cold to fend for themselves. This is such a bizarre mentality to me. When you sell your car, do you send a cut of the money to your mechanic?
hahahahhaah 9mo ago
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.
- fuzzfactor 9mo ago
  Yep, and then CDROMs really bumped it up to the next level for Microsoft. Pop music CD's had been popular for years before data CDROMs became available and more common. Stars like Michael Jackson were raking in the bucks and their record companies even more. Then by the mid '90's Windows was too sizable and unwieldy for most people to install from floppy any more, and consumer PCs started having CD reader/players standard. Microsoft CDs started flying off the shelf at 10x the retail price the record companies were charging for music CD's.
mattbrewsbytes 9mo ago
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.
- ewheeler 9mo ago
  I'd suggest commercial aircraft as an even better analogy than cars. Most of the ongoing costs you mention for cars still apply--but there are also the occasional (possibly dramatic) changes to the interior 'cabin product' like new seats and entertainment systems, new fabrics/branding, new business class seats/pods, changes in seat layouts, etc in order to remain competitive in their market segment. Cars rarely have such significant refreshes, but software products often have analogous design and UX overhauls that are also intended to try to keep the software competitive in its market segment. And again airlines don't need to engage the specific airframe manufacturer like Boeing or Airbus for these, but they do need some semblance of a tech team that have certain domain expertise in aircraft engineering constraints. Airframes also have major overhauls called MROs (Maintenance, Repair, and Overhaul) about every 6-10 years, which again does not require the original manufacturer but does require significant engineering expertise. To me this is akin to certain ongoing software maintenance activities like updating a codebase to use newer library versions, major database version updates, API or SDK version compatibility, etc.
ahmadyan 9mo ago
why do you think the previous management team couldn't pull an Elon and fire 80% of the engineering staff themselves? why they needed an external leadership to take over and do it? Part that i can't wrap my head around was at least in case of twitter, it was a hostile take over. In case of Vimeo, it didn't look hostile at all.
- Nextgrid 9mo ago
  I wonder if existing management had a lot of social ties to the existing workforce so that they couldn't easily get away doing that themselves without a big hit to their reputation. Letting someone else do the dirty work allows them to disassociate themselves from the (predictable) outcome and frame it as just business.
- johnnyanmac 9mo ago
  Maybe they could have. But they have 1.4 billion reasons to just walk away and either retire or try something else instead.
- lotsofpulp 9mo ago
  Twitter was not a hostile takeover. https://en.wikipedia.org/wiki/Acquisition_of_Twitter_by_Elon_Musk https://en.wikipedia.org/wiki/Acquisition_of_Twitter_by_Elon... > Twitter's board publicly and unanimously accepted the buyout offer for $44 billion
insane_dreamer 9mo ago
the house is a bad analogy the more appropriate analogy is a car company. They still need engineers because they need to keep coming out with new model and technology in order to remain competitive. Ford didn't fire its engineering team once it had built a car.
- cirelli94 9mo ago
  But they don't reinvent the wheel at every new car.
0xbadcafebee 9mo ago
Buildings are built according to a standard, legal code, with architectural drawings, inspections, standard components and dimensions, etc. The people who work on them are trained and certified in specific practices with specific tools and materials, and follow rigid guidelines. Most jobs are the same tools, same parts, same basic construction, same tasks, there are plans available, and most of the time it was inspected so it was done mostly in a way everyone understands and expects. Maintenance is very minimal, on the order of years, and it lasts decades if not centuries. Software is more like industrial manufacturing. Besides the high cost of the machinery, if the machines stop working (which they do occasionally) you stop producing product, so you need someone on staff who is familiar with them to fix them. A friend of mine is one of several "night staff" at Hershey's that just sit there twiddling their thumbs until a candy machine stops working at 4am.
- Nextgrid 9mo ago
  > you need someone on staff who is familiar with them to fix them But that maintenance headcount is much lower than the headcount necessary to build that machine. The same should be the case in tech - once the product is built and the groundwork laid, ongoing maintenance and minor alterations should not require anywhere near the headcount it took to build.
  - jollyllama 9mo ago
    Replying here because GP makes a good distinction, and your point still holds. I would point out that there are a few alternate models: 1) You use the maintenance headcount to build, and you just build that much slower. 2) You have an org that wants to stay the same size and move from project to project. In that case, some subset of your staff, are, at any one time, revisiting old projects for updates/maintenance, and some other portion are working on building a new thing. This is probably the strongest paradigm, because you can leverage common platforms between solutions. Unfortunately, of course, either of this is at odds with the current approach to business/capital, in which once an opportunity emerges, everything is thrown at it as quickly as possible.
  - 0xbadcafebee 9mo ago
johnnyanmac 9mo ago
> Builders and electricians and tradesmen either work as contractors and take that into account okay. Salaries office workers don't work on contracts. If they do, they know an end is in sight and renewal is not guaranteed. If companies want contractors, they should just do that. Meanwhie, I'm sure your parents' generation for many industries expected to find one job and make a career around that company, maybe doing 1 or 2 hops based on circumstances. It was highly unusual to lay off everyone at the drop of a hat. This is not normal, and I don't think we should normalize it. To use your metaphor, this is more like you are working on the 3rd room of some house and suddenly you are kicked out. Contractors take this into account, but you as a salaried worker just need to bite the bullet. This is companies having their cake and eating it to. >the old situation was never sustainable to begin with. Tell that to the trillion dollar tech companies.
- 627467 9mo ago
  plenty of software business rely on contractors dont they? im sure even pre-acquisition vimeo likely used contractors on many roles some even in "engineering" roles. the idea that software is never done is a double edge sword: yes, its great to have a long term vision that keeps evolving and motivating people to continue to push boundaries. but it also creates this idea that "done" state is not possible or even desirable. plenty of human (economic) activity is just operating, or maintaining. maybe some people who built products are happy to continue operating and operating it. not everyone, and certainly it would be hard to expecy society to guarantee employment under any circunstances. i have never seen labor laws that prohibits lay off under any circunstances. some make it more onerous and/or more beneficial conditiona to employees than others. but certainly is it possible (and likely) that vimeo lay offs have been lawfull and even beneficial for many employees. i certainly know plenty of people who explicitly stick around "mature" organizations waiting for the fat check of layoff
cirelli94 9mo ago
I don't think people where simply laid-off here, but replaced by the in-house developers and technologies of the platform of BS. I see a lot of negative comments here on HN, and I partly agree, but no one is recognizing here their try to optimize.
pjc50 9mo ago
The biggest piece of evidence for this worldview is the Twitter acquisition. A lot of people were very confident that it would quickly fall over after mass layoffs. That turned out not to be the case: the site can be kept running on a much lower staff. They've not really been able to add new features to the backend, but on the other hand: old @Jack Dorsey Twitter was so bad about this that there were memes ("likes are now florps"). And the features they have added (indecent image autogeneration) have caused as much brand damage in Europe as the Nazi salute. Yet the site continues to stay up almost all the time. (I don't think ZIRP is where the blame should lie, though. It's SaaS, which turns software into rentierism rather than purchase)
d--b 9mo ago
That's not true at all though. Car makers don't make a car and dismiss the entire engineering team. Sure, you could do that, but eventually people are going to move on from your only car that's old and clunky. That's exactly Bending Spoons model. Cut all the expenses, let the product die slowly. In the meantime you might have made more money than you put in to buy the product and the team. It's basically bankrupcy management.
xtiansimon 9mo ago
> “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…” Do you include visual design/UI design in the engineering category? In the situation you describe does a completed product continue evolving visually, or does the design stay fixed, and gets bug fixes and such?
rswail 9mo ago
This is the same business model that Computer Associates used successfully in the 1990s, so it's not new to IT or technology. The primary difference now is that the transition from bespoke IT on premises environments has been subsumed by the cloud hyperscalars and an entire hierarchy of products that use that infrastructure in a higher level of composability than in the past. Products like SAP will continue to require engineering to maintain compatibility with the changes in its customers' requirements. Products like MS-Word don't need that same level of feature work. If a product is essentially feature complete then making the engineering a "maintenance only" support is about minimizing those support costs.
- FormerBandmate 9mo ago
  The thing about this business model is that it inevitably falls apart when things break. Bending Spoons doesn’t care (yet), but they’re not at the point where stuff has proven unsustainable
  - rswail 9mo ago
    Sure, but that's not a problem for the short term, and these guys can beef up support to keep it going if needed, just not invest in new features or chasing competitors. Just like an old building, their business model is to sweat the asset until it's no longer viable. In the meantime, the cashflow goes directly to the bottom line.
dzonga 9mo ago
Vista Equity operates along a similar model for SAAS cut wasteful spending, find a way to increase revenue - milk the SAAS for a few years - then either sell it off or shut it down - or it can keep running as a lean cash generating machine Vista Equity rotates operators within its holding companies
- randito 9mo ago
  I've been through a Vista Equity acquisition. It was not pretty -- they slashed, consolidated and basically ran their one-size-fits-all playbook. The brought in their crew -- which is totally expected -- and then bought other companies in the same vertical. Of course, they all had different tech stacks. (like ya said, operators is the right word. it felt icky) At least for the first year, the acquired teams were able to run more or less the same but with new hyped-up-overly-aggressive Vista hotshot managers and then the sh*t-from-above just started raining down. Also, they hired the worst sw architect / person I've ever had to work with. He wasted so much time and money.
deepsummer 9mo ago
I understand your argument. But I have worked at two companies that worked pretty much like you described. They call it 'project-oriented'. They threw lots of engineers at projects, hired freelancers, and got it working as fast as possible. Once it was done, they only left a maintainer or two. That model works fine for a few years. Then you need a bigger change. Often, the system is built on top of some enterprise project, heavily customized, and you stay at your outdated version until it becomes unsupported. The maintainers don't care, and often don't have the capability to upgrade, so they just leave it as long as it keeps working. Or maybe some law has been introduced and requires a bigger change. Or the market just changes, and you need to support new APIs, new payment methods, new integrations... The maintainers tend to quit every 1-2 years and are replaced with someone only trained by the previous generation. With every generation, the maintainers get worse. After 3 generations, all product knowledge is gone. To make things worse, the maintainers do stupid things in the code because they don't fully understand it, and it begins to rot. In the worst case I know, no one even knew what branch was deployed on production and what the last changes were. Then, after 5-10 years of decay, some requirement comes along that would require a major refactoring. Everybody is overwhelmed, no one understands the internals, and eventually they decide that it the project is now so outdated that the only solution is to replace it. Management doesn't care because they can blame their predecessors. In my experience, that's how it always works. I know at least 5 major projects that took over a year to develop, and costing millions, in at least one case tens of millions, that died like that.
deleted 9mo ago
[deleted]

publicdebates 9mo ago

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.

Nextgrid 9mo ago
Won't be giving exact figures but that's my business model as well - I charge a premium because my job for clients is to make myself obsolete. If I "deliver" something that needs my constant presence then I haven't actually delivered. Of course, my price is high upfront because I'm budgeting in the fact that I strive to be out of there as soon as feasible instead of trying to stick around. Some clients are ok with it, some don't; this is normal and what a competitive market should look like. I tell clients openly when my premium service is not the right fit for their current requirements or budget, and there are cases where cheaper labor or LLMs are absolutely a better fit (and they should come back once when/if they outgrow the cheaper, lower-quality product).
refulgentis 9mo ago
I'd love to do this and have a quite marketable resume, but it is extremely, extremely, unclear to me how you build a clientele or where you'd even start. Only road I can imagine is highly specialized industry, with money, that often has time-sensitive needs, and smart management that knows how to recognize value or trusts their tech management. And even then I think you'd have to start in the coal-mines version of it, $50K/year flat salary, and building a reputation without management taking credit for your successes, somehow.
- Nextgrid 9mo ago
  The hard part is to get the client on the phone. Once you have them on the phone, you can not only better understand their problem but also demonstrate your skill and credibility in a way no resume or branding could. At that point it's just a sales game - generally you'd avoid hourly rates and sell them a solution (see my other comment) which will maximize your effective hourly rate while being structured in a way that's very good value for the client. Hourly should be a last resort, at which point generally you'd rather have the client bounce, so you quote a high rate.
  - publicdebates 9mo ago
    That last part is exactly why I charge $999/hour. I'll offer a specific solution that takes me a week of full time work (14 hours each day -- I'm focused) for about $10k, which is roughly $150/hour if you want to calculate it that way, or another specific solution that takes me 3 weeks of 10 hour days for $15k which amounts to $100/hour. And like any good consultant, I'll eat the cost if I'm wrong. Other times I'll charge $40k when I know it will take a few months of dedicated work and I have to really lock in. In practice, I never actually charge hourly. So the $999/hour is really Schrodinger's rate.

dostick 9mo ago

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.

DANmode 9mo ago
If you finish the backlog, you’ll get laid off, the backlog keeps being increased (by you and your manager at times), so it never gets finished. Seems easy enough to explain. There has to be a dragon being fought to account for all this money. Even if the dragon is bs.
- DANmode 9mo ago
  Sometimes the dragon is technical debt. When you’re historical Google, building three or more competing chat platforms…? That’s pretty much bs. Downvote away, but consider a reply explaining why.
hahahahhaah 9mo ago
It is simple. A productive developer can either: * Fix things * Build new things Add to this that things naturally break. Try a git reset to 1 year ago and deploy that to prod, for example. Add to that new features tend to add new bugs.

refulgentis 9mo ago

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)

Nextgrid 9mo ago
> companies took on debt to fund bloated engineering teams because no one noticed the engineering was done ZIRP allowed a lot of "businesses" to exist that wouldn't in a conventional, competitive capitalistic environment. Businesses in quotes because there was never any reasonable potential for profitability, but it didn't matter because VC money was cheap. Building a sustainable business is hard, playing "startup founder" and having that lifestyle subsidized by VCs is easier. In that case, (over)engineering was part of the performance art that was required to keep your only revenue source: the next funding round. There was never any incentive to "finish" the product because doing that would put your business model (or lack thereof) to the test and stop the music. On the other hand, as long as cheap money is around you could endlessly "engineer" and pivot and bullshit around, chasing the next funding round and using that to pay yourself/your friends decent salaries. During the ZIRP era it was all about "engagement" and DAUs/MAUs, then it was blockchain, and now it's all about AI. For those that have run out of grifts, they fold or "incredible journey" and get sold for pennies on the dollar to entities like Bending Spoons that do notice there are bloated engineering teams that can be cut.

reaperducer 9mo ago

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.

Nextgrid 9mo ago
> the head of Communications immediately said he's going to start looking for alternatives. He's gonna start looking for alternatives and then most likely find nothing that matches the featureset vs price of the current solution + the cost of switching, and the matter will quickly disappear. Last time AWS or Cloudflare was down a lot of noise was made and a lot of people started looking for alternatives too - and everyone forgot about it a week later. > Only for the company. Yes, the point of business is to make profit, not to be a charity. Bending Spoons believes they can extract enough profit off Vimeo to justify the purchase price, either by reducing expenses, raising prices or both. This may still be palatable to the customers if they don't have any better option.
- reaperducer 9mo ago
  Yes, the point of business is to make profit, not to be a charity. No one said it was. Where do you see that in this thread? Bending Spoons believes they can extract enough profit off Vimeo to justify the purchase price, either by reducing expenses, raising prices or both. This may still be palatable to the customers if they don't have any better option. Just listen to yourself. "Extract enough profit," "raising prices," and ending with You don't like it, too bad. You sound like the taxi industry before Uber. This the type of thinking that gave us Windows 11, Adobe, and every other piece of technology that started good, but became crap. It's also the reason new companies suddenly show up and eat the incumbent's lunch. Happens every day. I'm glad I don't work for you or your company. I have pride in my work. I wouldn't want to be just another tool to "extract" things from my customers because "they don't have any better option."

MontyCarloHall 9mo ago

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-manual https://www.colinkeeley.com/blog/bending-spoons-operating-ma... [1] https://www.unifygtm.com/insights-headcount/vimeo 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."

CiccioNizzo 9mo ago
> 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. And accidentally turned it into a shitty product in the process :-)
- johnnyanmac 9mo ago
  "accidentally", huh. Such a charitable take. Well, the goal of the optimizations wasn't to benefit the customer or even make the app faster. It was to make it easier for a skeleton crew to maintain. If that chopped out a few features, oh well.

wavemode 9mo ago

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.

f33d5173 9mo ago
The businesses they acquire are ones whose revenue has not appreciably grown in many years. They are being sold because the prior owner does not believe they can improve the business any more. Any profit bending spoons earns they can run off and invest in another business if they like. They don't bother investing in the businesses they purchase because they believe, like the previous owner believed, that there is no more juice to squeeze from that particular lemon.
- specialist 9mo ago
  Just like Computer Associates. https://en.wikipedia.org/wiki/Computer_Associates https://en.wikipedia.org/wiki/Computer_Associates
- johnnyanmac 9mo ago
  >Any profit bending spoons earns they can run off and invest in another business if they like And the ones who helped make Vimeo what it is? left out in the cold to fend for themselves. This is why loyalty is dead. Maybe if this billion dollar aquisition benefitted the workers there'd be less hard feelings, but that's not how capitalism works.
  - senordevnyc 9mo ago
    And the ones who helped make Vimeo what it is? left out in the cold to fend for themselves. This is such a bizarre mentality to me. When you sell your car, do you send a cut of the money to your mechanic?

hahahahhaah 9mo ago

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.

fuzzfactor 9mo ago
Yep, and then CDROMs really bumped it up to the next level for Microsoft. Pop music CD's had been popular for years before data CDROMs became available and more common. Stars like Michael Jackson were raking in the bucks and their record companies even more. Then by the mid '90's Windows was too sizable and unwieldy for most people to install from floppy any more, and consumer PCs started having CD reader/players standard. Microsoft CDs started flying off the shelf at 10x the retail price the record companies were charging for music CD's.

mattbrewsbytes 9mo ago

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.

ewheeler 9mo ago
I'd suggest commercial aircraft as an even better analogy than cars. Most of the ongoing costs you mention for cars still apply--but there are also the occasional (possibly dramatic) changes to the interior 'cabin product' like new seats and entertainment systems, new fabrics/branding, new business class seats/pods, changes in seat layouts, etc in order to remain competitive in their market segment. Cars rarely have such significant refreshes, but software products often have analogous design and UX overhauls that are also intended to try to keep the software competitive in its market segment. And again airlines don't need to engage the specific airframe manufacturer like Boeing or Airbus for these, but they do need some semblance of a tech team that have certain domain expertise in aircraft engineering constraints. Airframes also have major overhauls called MROs (Maintenance, Repair, and Overhaul) about every 6-10 years, which again does not require the original manufacturer but does require significant engineering expertise. To me this is akin to certain ongoing software maintenance activities like updating a codebase to use newer library versions, major database version updates, API or SDK version compatibility, etc.

ahmadyan 9mo ago

why do you think the previous management team couldn't pull an Elon and fire 80% of the engineering staff themselves? why they needed an external leadership to take over and do it? Part that i can't wrap my head around was at least in case of twitter, it was a hostile take over. In case of Vimeo, it didn't look hostile at all.

Nextgrid 9mo ago
I wonder if existing management had a lot of social ties to the existing workforce so that they couldn't easily get away doing that themselves without a big hit to their reputation. Letting someone else do the dirty work allows them to disassociate themselves from the (predictable) outcome and frame it as just business.
johnnyanmac 9mo ago
Maybe they could have. But they have 1.4 billion reasons to just walk away and either retire or try something else instead.
lotsofpulp 9mo ago
Twitter was not a hostile takeover. https://en.wikipedia.org/wiki/Acquisition_of_Twitter_by_Elon_Musk https://en.wikipedia.org/wiki/Acquisition_of_Twitter_by_Elon... > Twitter's board publicly and unanimously accepted the buyout offer for $44 billion

insane_dreamer 9mo ago

the house is a bad analogy the more appropriate analogy is a car company. They still need engineers because they need to keep coming out with new model and technology in order to remain competitive. Ford didn't fire its engineering team once it had built a car.

cirelli94 9mo ago
But they don't reinvent the wheel at every new car.

0xbadcafebee 9mo ago

Buildings are built according to a standard, legal code, with architectural drawings, inspections, standard components and dimensions, etc. The people who work on them are trained and certified in specific practices with specific tools and materials, and follow rigid guidelines. Most jobs are the same tools, same parts, same basic construction, same tasks, there are plans available, and most of the time it was inspected so it was done mostly in a way everyone understands and expects. Maintenance is very minimal, on the order of years, and it lasts decades if not centuries. Software is more like industrial manufacturing. Besides the high cost of the machinery, if the machines stop working (which they do occasionally) you stop producing product, so you need someone on staff who is familiar with them to fix them. A friend of mine is one of several "night staff" at Hershey's that just sit there twiddling their thumbs until a candy machine stops working at 4am.

Nextgrid 9mo ago
> you need someone on staff who is familiar with them to fix them But that maintenance headcount is much lower than the headcount necessary to build that machine. The same should be the case in tech - once the product is built and the groundwork laid, ongoing maintenance and minor alterations should not require anywhere near the headcount it took to build.
- jollyllama 9mo ago
  Replying here because GP makes a good distinction, and your point still holds. I would point out that there are a few alternate models: 1) You use the maintenance headcount to build, and you just build that much slower. 2) You have an org that wants to stay the same size and move from project to project. In that case, some subset of your staff, are, at any one time, revisiting old projects for updates/maintenance, and some other portion are working on building a new thing. This is probably the strongest paradigm, because you can leverage common platforms between solutions. Unfortunately, of course, either of this is at odds with the current approach to business/capital, in which once an opportunity emerges, everything is thrown at it as quickly as possible.
- 0xbadcafebee 9mo ago

johnnyanmac 9mo ago

> Builders and electricians and tradesmen either work as contractors and take that into account okay. Salaries office workers don't work on contracts. If they do, they know an end is in sight and renewal is not guaranteed. If companies want contractors, they should just do that. Meanwhie, I'm sure your parents' generation for many industries expected to find one job and make a career around that company, maybe doing 1 or 2 hops based on circumstances. It was highly unusual to lay off everyone at the drop of a hat. This is not normal, and I don't think we should normalize it. To use your metaphor, this is more like you are working on the 3rd room of some house and suddenly you are kicked out. Contractors take this into account, but you as a salaried worker just need to bite the bullet. This is companies having their cake and eating it to. >the old situation was never sustainable to begin with. Tell that to the trillion dollar tech companies.

627467 9mo ago
plenty of software business rely on contractors dont they? im sure even pre-acquisition vimeo likely used contractors on many roles some even in "engineering" roles. the idea that software is never done is a double edge sword: yes, its great to have a long term vision that keeps evolving and motivating people to continue to push boundaries. but it also creates this idea that "done" state is not possible or even desirable. plenty of human (economic) activity is just operating, or maintaining. maybe some people who built products are happy to continue operating and operating it. not everyone, and certainly it would be hard to expecy society to guarantee employment under any circunstances. i have never seen labor laws that prohibits lay off under any circunstances. some make it more onerous and/or more beneficial conditiona to employees than others. but certainly is it possible (and likely) that vimeo lay offs have been lawfull and even beneficial for many employees. i certainly know plenty of people who explicitly stick around "mature" organizations waiting for the fat check of layoff

cirelli94 9mo ago

I don't think people where simply laid-off here, but replaced by the in-house developers and technologies of the platform of BS. I see a lot of negative comments here on HN, and I partly agree, but no one is recognizing here their try to optimize.

pjc50 9mo ago

The biggest piece of evidence for this worldview is the Twitter acquisition. A lot of people were very confident that it would quickly fall over after mass layoffs. That turned out not to be the case: the site can be kept running on a much lower staff. They've not really been able to add new features to the backend, but on the other hand: old @Jack Dorsey Twitter was so bad about this that there were memes ("likes are now florps"). And the features they have added (indecent image autogeneration) have caused as much brand damage in Europe as the Nazi salute. Yet the site continues to stay up almost all the time. (I don't think ZIRP is where the blame should lie, though. It's SaaS, which turns software into rentierism rather than purchase)

d--b 9mo ago

That's not true at all though. Car makers don't make a car and dismiss the entire engineering team. Sure, you could do that, but eventually people are going to move on from your only car that's old and clunky. That's exactly Bending Spoons model. Cut all the expenses, let the product die slowly. In the meantime you might have made more money than you put in to buy the product and the team. It's basically bankrupcy management.

xtiansimon 9mo ago

> “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…” Do you include visual design/UI design in the engineering category? In the situation you describe does a completed product continue evolving visually, or does the design stay fixed, and gets bug fixes and such?

rswail 9mo ago

This is the same business model that Computer Associates used successfully in the 1990s, so it's not new to IT or technology. The primary difference now is that the transition from bespoke IT on premises environments has been subsumed by the cloud hyperscalars and an entire hierarchy of products that use that infrastructure in a higher level of composability than in the past. Products like SAP will continue to require engineering to maintain compatibility with the changes in its customers' requirements. Products like MS-Word don't need that same level of feature work. If a product is essentially feature complete then making the engineering a "maintenance only" support is about minimizing those support costs.

FormerBandmate 9mo ago
The thing about this business model is that it inevitably falls apart when things break. Bending Spoons doesn’t care (yet), but they’re not at the point where stuff has proven unsustainable
- rswail 9mo ago
  Sure, but that's not a problem for the short term, and these guys can beef up support to keep it going if needed, just not invest in new features or chasing competitors. Just like an old building, their business model is to sweat the asset until it's no longer viable. In the meantime, the cashflow goes directly to the bottom line.

dzonga 9mo ago

Vista Equity operates along a similar model for SAAS cut wasteful spending, find a way to increase revenue - milk the SAAS for a few years - then either sell it off or shut it down - or it can keep running as a lean cash generating machine Vista Equity rotates operators within its holding companies

randito 9mo ago
I've been through a Vista Equity acquisition. It was not pretty -- they slashed, consolidated and basically ran their one-size-fits-all playbook. The brought in their crew -- which is totally expected -- and then bought other companies in the same vertical. Of course, they all had different tech stacks. (like ya said, operators is the right word. it felt icky) At least for the first year, the acquired teams were able to run more or less the same but with new hyped-up-overly-aggressive Vista hotshot managers and then the sh*t-from-above just started raining down. Also, they hired the worst sw architect / person I've ever had to work with. He wasted so much time and money.

deepsummer 9mo ago

I understand your argument. But I have worked at two companies that worked pretty much like you described. They call it 'project-oriented'. They threw lots of engineers at projects, hired freelancers, and got it working as fast as possible. Once it was done, they only left a maintainer or two. That model works fine for a few years. Then you need a bigger change. Often, the system is built on top of some enterprise project, heavily customized, and you stay at your outdated version until it becomes unsupported. The maintainers don't care, and often don't have the capability to upgrade, so they just leave it as long as it keeps working. Or maybe some law has been introduced and requires a bigger change. Or the market just changes, and you need to support new APIs, new payment methods, new integrations... The maintainers tend to quit every 1-2 years and are replaced with someone only trained by the previous generation. With every generation, the maintainers get worse. After 3 generations, all product knowledge is gone. To make things worse, the maintainers do stupid things in the code because they don't fully understand it, and it begins to rot. In the worst case I know, no one even knew what branch was deployed on production and what the last changes were. Then, after 5-10 years of decay, some requirement comes along that would require a major refactoring. Everybody is overwhelmed, no one understands the internals, and eventually they decide that it the project is now so outdated that the only solution is to replace it. Management doesn't care because they can blame their predecessors. In my experience, that's how it always works. I know at least 5 major projects that took over a year to develop, and costing millions, in at least one case tens of millions, that died like that.

deleted 9mo ago

[deleted]