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.
Software may never be finished (in your opinion) but the budget of any customer is finite. If you keep reinvesting your revenue forever into "engineering" the product there's going to be a time where a competitor comes in with a finished product matching your customers' requirements and snatches him from you by both charging less and making a profit.
There’s also the much more common case of a competitor coming in with a similar product that has a few more features matching the customers’ requirements… which explains the endless product development treadmill that companies find themselves on.
Software doesn’t win by being “finished” it wins by out competing other software
Yeah, if Youtube was "finished" we wouldn't have had Youtube Red, Youtube shorts, Youtube music, etc.
And yes, I am making a good case for mature software with those lovely examples. But clearly they wanted more widgets and they kept engineers who can deliver those widgets. This wasn't some unsustainable thing for Youtube as the top comment argues. And that's how most software businesses work as of now. If you remain complacent, you're slowly dying to competition. Because the demand for more still exists.
The number of customers is, effectively, infinite though. YouTube continues to be engineered and continues to grow. It could have, realistically, been finished over a decade ago. But they repeated branch out into new markets with new features, and that seems to work from them.
But YouTube is still a growing and maybe a profitable business (they disclose its revenue but not costs).
Bending Spoons buys stalled or failed products and keeps them alive with a central engineering team in Italy which is far cheaper than anything in the US.
That's their business model. If the company you work for is acquired by them you should start looking for a new place.
The new features are an order of magnitude less complexity to build than the main feature - hosting video at scale, which is complete and just requires maintenance.
I'm going on a limb here and saying that the scale that YouTube was running on back in 2010-2015 is not the same scale as now, and if they had left their whole infrastructure unchanged, a "finished product", so to speak, the site would have been feeling dated and would have eventually been killed off.
Without having access to the source code we can only speculate but I believe even in those days YouTube already outgrew vertical scaling and thus had to be built as a horizontally-scalable system. That is the hard part.
Adding extra nodes to an existing horizontally-scalable system (that has already been operating and has its bugs ironed out) is much easier.
That is really a bit of an oversimplification IMO. Please check, for example, the Netflix tech blog and read about what has changed in the past 10 years or so when it comes to architecting video processing and video delivery systems. There's a tremendous amount of engineering work there which advances the entire industry. For instance, it's not trivial to add live events to a VoD infrastructure at that scale — it's not like you just add a few more nodes and buy faster encoders.
Potential revenue growth is only as finite as your ideas (and ability to execute on them).
Just look at Google. They could have stopped writing new software at any point and been just fine. But in the long run they'd have missed out on trillions of dollars.
As with everything in business, it comes down to risk/reward. Not every risk pays off, but some do.
But for every outlier that can perpetually keep unlocking new revenue streams with more features, there's probably 100 companies that burn themselves out trying to do the same and end up sold for pennies on the dollar.
The key is knowing when to stop. Unfortunately permanent employment does not provide an incentive for anyone involved to speak up when they think it's that time.
>for every outlier that can perpetually keep unlocking new revenue streams with more features, there's probably 100 companies that burn themselves out trying to do the same and end up sold for pennies on the dollar.
Okay. Most businesses also fail. Is that a reason for existing ones to stop growing?
> Not if you find new ways to appeal to them once you have them as users.
Doch, even then.
Back at university, we had practice sessions about our CVs and job interviews. Mine had a cliché in it, "committed to quality"*. The businessperson who was helping us figure out how to be any good at the jobs market, picked up on it with an example:
Which is higher quality? A Porsche, or a go-kart?
We nodded at "Porsche", as was the point.
Except no; you didn't consider who the customer was. If this is for a kid who just wants to have some fun, they can't afford a Porsche, they've got no insurance, they don't know how to drive. A go-kart solves their problem, they get to have fun, a Porsche doesn't.
(I'm paraphrasing, it was over 20 years ago now).
* I was 19 or 20 when I wrote that, it was about as true as when ChatGPT writes the same: I didn't know any better.
This is a weird example because there are crappy go-karts and there are carefully designed and assembled go-karts. You can have a high quality anything: car, truck, go-kart, trailer, wagon.
Even then... you reach a point where any additional quality or craftsmanship offers no more value. Aesthetics can have some arbitrary value, but even then it's a matter of taste.
> Software may never be finished (in your opinion) but the budget of any customer is finite.
The reason why software companies grow, is because businesses demands growth.
I suppose you could build a simple, small app and leave it on "maintenance" (even then, it's going to be difficult due to crumbling infra) but real world products don't work that way.
Companies want to scale, add features and expand to various verticals. They also have to compete with other companies , there is regulations, compliance and never ending list of incoming features from sales, marketing and customers.
Elon Musk famously attempted to run Twitter "lean", and look how that ended.
Unless you are able to curb the corporate greed, you will need to grow your engineering team.
> The reason why software companies grow, is because businesses demands growth.
There's only so much growth you can achieve in any vertical - the key is to realize when you've hit that limit and cut your losses. Unfortunately as a company employee you have no incentive to do that.
I doubt Vimeo would've sold if there was still lots of growth potential on the table. They've exhausted it, and for various factors were unable to cut costs internally.
Bending Spoons evaluated the situation and determined they can still extract a certain amount of profit by massively cutting costs - they gave chunk of said expected profit to the current owners, and are now implementing said strategy.
> Elon Musk famously attempted to run Twitter "lean", and look how that ended.
The decline of Twitter has all to do with Musk's politics and lack of any kind of strategy of the product (makes sense if you see it as his personal mouthpiece rather than a business). Tech-wise it seems to be working well enough. Cutting 80% of expensive engineering staff for a 1% drop in uptime of a non-critical service with no SLAs is a no-brainer.
I'm not really sure this argument makes sense. Plenty of software I've built is finished, it does the thing I need it to do and I haven't touched it in years. Adding features just because is not a useful way to spend anyone's time, doubly so in a business context.
> Adding features just because is not a useful way to spend anyone's time, doubly so in a business context.
You could make this statement about anything. "Building a new hospital wing just because is not a useful way to spend anyone's time", "Adding an extra drive-thru lane just because is not a useful way to spend anyone's time". The point is that it's not "just because", it's because you believe it can grow your revenue.
On the other hand, if you don't believe that, then don't invest. Nobody's saying you have to. If you think my comment is saying that, you've misread it.
> You could make this statement about anything. "Building a new hospital wing just because is not a useful way to spend anyone's time", "Adding an extra drive-thru lane just because is not a useful way to spend anyone's time". The point is that it's not "just because", it's because you believe it can grow your revenue.
You can, but do you really need the same sized team to add an extra lane to a drive-through as you needed to build the entire restaurant's building, kitchens, etc?
Do you need the same sized team to add a new wing to a building as the team that built the existing building(s)?
Hospitals expand because they either already don't or they project they won't meet demand. It's the same story with drive-thrus. These are things that are measured and analyzed. Adding features in the blind hope that more features equals more revenue is exactly how companies stagnate and burn. There's plenty of successful software products out there that are finished as far as the feature set goes, you'll find they power most of the industries outside of IT.
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.
>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.
It is absolutely true that software can be finished, it's just that software appears to be dead if it hasn't had any work done on it for years. You don't need to keep adding features and changing the software ad infinitum.
Just like with your building analogy and with other car analogies presented here, software does need some maintanence every now and again to keep it up to date - with security fixes, compiling to a newer platform, integrating fixes from dependencies, etc. And yes while buildings may be finished they stil require regular maintance if they are used.
My argument is that the maintenance overhead of a finished product (or car, or building) should require much less effort than what it takes to build it - otherwise you should seek a refund from the original manufacturer(s).
That's absolutely not true in pretty much any mid scale software. You can have a team of 5 people make the core of an app, then need 50 people to help with support for customers. scaling up is never cheap, but software scalability is really low despite that.
That's not even true with a car. I'm about to spend 3000 dollars on a big repair for a car I bought 9 years ago used @ 3500. Even if you adjust for inflation we're still talking about 70% of the car's worth just to keep it running. As for a refund, the blue book value tops at 850 dollars.
> I'm about to spend 3000 dollars on a big repair for a car I bought 9 years ago used @ 3500. Even if you adjust for inflation we're still talking about 70% of the car's worth just to keep it running.
That's one way to run that ROI, sure, but is it correct?
1. The original $3.5k you spent is a sunk cost; you should ignore it, so your total cost of getting a running car is only $3k.
2. Even if you don't ignore it, your total bill to get a running car is $7.5k
In either of the above situations, you should be comparing the cost to get a running car by fixing your existing car (either $3k or $7.5k) to the cost of getting a running car by selling it as-is (so, perhaps +$500 as a parts donor -$X for a replacement running car).
Regardless of which calculus you are using, it's still going to come cheaper to fix the running car.
What the car is "worth" (however you define it) is irrelevant to the calculus.
That actually depends what kind of application you are building and maintaining.
From the sounds of it I assume you're talking about developing and maintaing a SaaS application, where there is no real maintanence of it, and instead what you end up doing is developing it further to support larger data sets and more people. That is of course assuming that the software is successful and the usage is growing.
For traditional desktop software you can declare it finished and then maintanence is minimal and limited to only critical bugs, so you'd have a team of 5 develop it and then 1 person or less maintain it.
> Software is never "finished" the way a building is finished.
On the contrary, it absolutely can be, in both directions.
Software can absolutely be "feature complete", and in the case of many products it would have been an improvement to say "we're done now" and switch from developing new features to maintenance-only mode, dealing only with API changes and new laws.
Some examples of where it should be "done" by some point include smart TVs and smart lightbulbs. I'm also old enough to remember the era of games where patches were rare and small, unlike the current experience of having to wait for Steam to install updates almost every day, and only then will allow me to see if the game I want to play and which worked yesterday now has a mandatory update that I also have to wait for (which is less often but still often enough to be annoying).
Even with MacOS, while I absolutely do appreciate all the behind the scenes stuff regarding security and so on, the last time I appreciated what they did with the UI in an update, the version branding scheme was still to name releases after cats.
Even as an iOS developer, although I can see what they're trying to do with SwiftUI, I find it worse than UIKit in basically every regard because the "magic" keeps not working and the "problem" it tried to solve was never (for me) a problem; with concurrency, they went from GCD to Combine which IMO was a step back, before going to async/await.
"Too many features" is also a problem for the developers, as it leads to them duplicating work. For example, the background sounds feature on my phone and the one on my HomePod each has its own list of sounds, they're not just two interfaces to the same underlying app even though the HomePod's OS is a fork of tvOS which is a fork of iOS.
(The other way around, the home I grew up in is now about twice the size it was when my parents bought it around 1970, judging from the Google areal view).
Unfortunately when the software is done, the product lifetime comes to a close soon after. Everything around the product changes and the software needs to change to keep up. Smart lightbulbs need apps to keep working and you get kicked out of app stores if you don't keep up with never-ending churn Apple and Google imposes on you.
The only way to run older games is to use emulators and other 3rd party effort, that also needs to be continually updated. When you claim that any piece of software is done and completed, you've only externalized the effort required to keep it useful.
I absolutely agree with your pushback against feature creep. That is unfortunately a reflection of internal corporation value system, while the successful open source projects often know where to draw the line.
How does that make it different? More features could always be added to most buildings. You could keep adding rooms onto the side, update the floors/ceilings/walls every year to stay trendy, add a water feature, expand the basement with a tunnel network, etc.
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.
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.
> 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.
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
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.
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
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.
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.
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.
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.
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).
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.
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.
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.
Hourly rates are inherently risky for clients - you're asking them to part with money with no guaranteed outcome, so there's a natural ceiling where the financial risk becomes untenable regardless of your expertise and reputation.
Clients don't buy hours though, they buy solutions. They have problems costing them money or preventing revenue and they'll pay a percentage of that value to solve it. When you price based on solution value rather than time, your effective hourly rate merely becomes a function of your efficiency and expertise delivering said solution.
They key to achieving such a rate comes down to your sales and business skills: understanding what to sell, how to structure it to maximize your earnings and make it palatable for the client.
For example I generally avoid hourly billing except as a filter for time-wasters. Instead, consultancy becomes a loss leader for the real business: deeply understanding client problems and delivering high-value solutions. Clients happily pay premium rates when they see the price as a fraction of the solution's worth to them.
I only resort to quoting (quite high) hourly rates where it's clear the client just wants consultancy/advice (basically a glorified IT/business support) as a way to make it worth my time and gently encouraging them to bounce (I openly suggest more cost-effective options and refer them there).
You judge how valuable the solution is to your customer and then structure your pricing to maximize your profits while still being palatable to your client.
Let's say your client has a problem that will bring them 1k/hr of revenue when fixed. You think you can fix it in an hour.
You could quote them 5k/hour, because you think you can fix it in one hour and you estimate it'll take them at least 5 hours to find and talk to someone else who could fix it. This is a big gamble for the client, what if you don't fix it or take longer? The client balks.
Now let's say you offer a "reasonable" hourly rate like 150/hr. Your client is happy to take the gamble because 150 is peanuts compared to the value they get if you do fix it. Client takes the deal, you fix the problem, but you got paid peanuts.
Now let's say you offer them a no-fix-no-fee rate of 5k. The client is happy to take it because once the problem is solved it takes them just 5 hours to go back in profit, and they risk nothing if you end up not solving the problem. They take the deal, you fix it in an hour, the client happily pays you 5k, netting an hourly rate of 5k/hour.
Same hourly rate as the first scenario, yet the first scenario will cause everyone to balk while the second one is a steal for the client (in reality, you can actually charge more than 5k, how much more depends on your reputation and sales skills).
Such consultancies feel like a dying art for the new work force. To consult, you need to be trusted. To be trusted, you need to already have experience working with software at scale. To get that experience you need to go through events like mass layoffs every few years, which limits your expertiese built.
I very much worry for Gen Z. Through no fault of their own.
And if no one takes your price, you fail as a business. I think that's the concern. There's not a lot of vectors I feel I can jump in to say "I'll do this for 1000/hr" without getting some bulging eyes. Because I don't have the credibility to back that up.
How to get credibilty? Well, you gotta be in industry. The thing the two consultants here are besmirching. You can't win.
I think you're just looking at these negotiations from the wrong perspective.
> There's not a lot of vectors I feel I can jump in to say "I'll do this for 1000/hr" without getting some bulging eyes.
1000/hr might be a lot for you, for many businesses it's not even a meaningful expense, the bigger hassle for them is doing the paperwork to get the money sent out.
I'm well out of tech at this point, running a small lifestyle business in a different industry. At least once a month, I get people in my new industry offering me significant amounts of money to build them software. I don't have a fancy public tech resume; really, the only thing these people know is that I'm some relatively pleasant, rich, former tech guy.
If you're someone like Steve Jobs then #3 is a bit optional because #4 is increased, both in truth and in arrogant overestimation.
The hardest part of this really is #4, because most people either get too cocky and overconfident in the value they provide in general, or they are so overcome with imposter syndrome that they believe they offer practically nothing, so they do almost entirely open source work and fail to start a consultancy.
> And if no one takes your price, you fail as a business.
Vimeo employees and all the people part of the recent tech bloodbath experienced that too, but without even pocketing the upside beforehand. I'd argue that for anyone currently searching for a job, they will get a better ROI engaging in sales instead.
Any monkey can (and does) sling ChatGPT'd resumes at anything that moves, hoping to get the job and pocket enough salary before people catch on. That scam doesn't work with consultancy on a "paid on delivery" model, so the market there is much less crowded. There are different scams out there but those primarily target big companies.
> There's not a lot of vectors I feel I can jump in to say "I'll do this for 1000/hr"
We as techies know how the sausage is made and estimate a "fair" price based on the effort it would take us to do it. A car mechanic would probably also consider retail oil change prices to be unfair... because he's already invested in the knowledge and tooling and with those it's indeed a 5 min job.
From a business' perspective though, our work might as well be magic - we are writing prayers in an arcane language to make silicon come to life and do things that generate money for the business. It's magic that they have repeatedly failed to replicate for themselves. The latest fad is AI/LLMs and that will fail too - LLMs only work in the hands of a skilled operator - and otherwise fail disastrously and often generate extra remediation work on short notice.
If you worked in tech there's a good chance your past contributions are netting way more than 1k/hour to someone else already - so you can generate this value. The challenge now is to capture more of said value.
Nobody in their right mind will pay 10x market rate for no guarantee of result; see my other comments in this thread. This would open them up to the same scams that happen with permanent employees and third-world countries will be all over it the next day.
But if they are guaranteed a result then the calculus changes, they are no longer thinking of hourly rates but instead of as a fraction of the revenue enabled by your solution, and their risk is lowered to only the opportunity cost. This is a much better deal for the client. Your resulting hourly rate now purely depends on the value of the solution to the client divided by how quickly you can do the task.
You only explicitly quote the 10x market rate when you want the client to bounce because the job or client sounds like a nightmare. You will get some clients who are cheap and insist on an hourly rate to explicitly prevent you from playing the above game and earning the (much bigger) cut of the solution. The "fuck you" rate is for that, it's not expected to be taken, it's there to set a baseline price for your expertise and make the deals you offer sound more attractive in comparison.
It's basically all sales and reframing your work from salaried/hourly rate to how much your work is worth for potential clients (which doesn't scale linearly with time invested nor software complexity).
As to why am I giving you advice on how to compete with me? Because you're already competing with me by willing to settle for permanent employment market rate for the services I am offering. Encouraging you to charge more helps us both.
Have you tried Claude Opus 4.5 within Claude Code?
it's only been released for two months but its changed the calculus entirely
if its been over two months since you've tried any LLM generated code solution, or are still occasionally copy pasting code requirements into a browser chat session as if its still 2023, then I can't put any weight into the opinion
That's because it's been true for every major new model release since GPT-3.
HN is full of people who tried the free version of ChatGPT a couple of years ago, got a load of random hallucinated slop, and concluded it was all a bunch of useless hype. They enjoy parroting a lot of obsolete stuff they read once about stochastic parrots, without the slightest sense of irony.
When I was growing up, my old man recalled engineers who reacted the same way to transistors, which sucked even more than early-generation LLMs when they first came out. Most of them got over vacuum tubes eventually, though. So will most of the HN'ers, likely including you.
I don't know whose thoughts you're trying to attribute to me, but I've been pretty up-to-date myself (while still keeping myself to a $20/month budget that I switch between providers every few months).
Every generation has at best been a 5% improvement, and nothing revolutionary compared to the last generation. Absolutely no significant improvements between me selecting say Claude 3.7 Sonnet, Claude Sonnet 4, or Claude Sonnet 4.5. Still the same somewhat useful tool for specific purposes, still not good enough to be let loose on production, still not better than what I can do myself with 10 or so years of experience.
Genuinely useful from time to time? Sure, I agree completely. Anywhere near being revolutionary enough as people here insist on gaslighting themselves to be? Absolutely not. Not even remotely.
I'll grant that progress in coding hasn't been as impressive, although if you don't see a difference between Claude 3.7 Sonnet and 4.5 Opus (which is the actual SotA for Claude) I'd suspect a skill issue. I haven't seen miraculous progress in baseline code generation, but there has been a lot of progress in tool use. I can tell Claude CLI to install a complex package, for instance, and it will handle all the Python versioning and dependency-hell issues for me, then test and evaluate the results. 3.7 Sonnet couldn't do that, at least not reliably.
What's really different now is that LLMs have become useful research tools. Three or four years ago, models couldn't cite their sources at all. Two or three years ago, they started to gain the capability, but a large proportion of the citations would either be hallucinated or irrelevant. About a year ago, significant improvements started to emerge. At this point, I can give Gemini 3 Pro or GPT 5.2 Pro a multilayered research task, and end up with a report indistinguishable in accuracy and bibliographic quality from what a good human might produce in a couple of weeks.
It might take a half hour to get the answer, and I'm not sure if you could get the same result at the $20/month level, but the hype and promises we started hearing a couple of years ago are starting to bear fruit. The research models are now capable of performing at grad-student level. Not all the time, and not without making stuff up on occasion... but to argue that no progress at all has been made is nothing more or less than moon-landing denial.
Cool, how much of it can I use with a $20/month subscription? I'd reach the monthly limit within hours while gaining nothing. It's not that I never tried it, it's that I did and the difference is nowhere near worth 10x my money (nor even the wait time needed to get results).
> I'd suspect a skill issue.
There's 0 skill involved with asking a magic 8 ball to solve your problem for you. There's some skill involved with making it better for yourself consistently by cramming as much useful info as possible into the context window by writing very specific custom agents / skills / MCP servers / whatever, but I have yet to find a client that would pay me to spend an ungodly amount of time fucking around with my toolbelt instead of delivering results.
> Three or four years ago, models couldn't cite their sources at all. Two or three years ago, they started to gain the capability, but a large proportion of the citations would either be hallucinated or irrelevant. About a year ago, significant improvements started to emerge.
Let's translate that: You don't understand what they're doing under the hood when they "do that", you don't understand where that "improvement" is coming from, and I'm not interested in spending my time teaching you for free. For as little as €50/h, I'd be happy to! contact at my username.
> but the hype and promises we started hearing a couple of years ago are starting to bear fruit.
You're gaslighting yourself again in order to justify the price you're currently paying. Downgrade yourself back to $20 subscription, stick to it for one whole month, learn its limits properly, and then if you feel like you need to upgrade to a higher tier again, do so! Spoiler alert: it's gonna appear "significantly crappier" for about a week, and then after that week, you will get used to it and realise you've wasted a fuck ton of money on nothing.
> but to argue that no progress at all has been made is nothing more or less than moon-landing denial.
Where's that coming from? You're putting words into my mouth again. I specifically acknowledged small improvements, but I dismissed drastic improvements. Zero of what you said convinced me otherwise. For the love of all holy, use your own brain a little bit to actually understand the tools you're advocating for. Saying that you drank too much Kool-Aid would've been a severe understatement.
> but I have yet to find a client that would pay me to spend an ungodly amount of time fucking around with my toolbelt instead of delivering results.
right, yeah, I got started by being able to expense the $200 plan, and now I don't expense it but there's no going back, mostly because this is extremely undervalued and its unclear how long this deal will be around
Claude's $200/mo Max x20 plan is the best deal in the game, its equivalent to about $2600 worth of API credits, and is 4x more ability than the $100 plan (Max x5)
all roads to not really... caring... about why you're resistant to this. it's going to be too late when Anthropic raises the prices, all the reasons behind your reservations grow, unless someone else undercuts them just as well.
This is so true, and it's been genuinely painful for me to realize how fucking lazy and close-minded many in our industry actually are when you get down to it.
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.
[*] 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."
> 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 :-)
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.
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.
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.
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)
> 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.
You hold ZIRP caused this, then cite crypto and AI as continuations, both post-ZIRP. Which is it?
> as long as cheap money is around you could endlessly "engineer" and pivot and bullshit around
I lived this in a particular industry firmly inside the ZIRP era. It doesn't begin to describe how things actually worked. Even if ZIRP is synonymous with endless money to you, on their end, they still had to choose how to allocate it, and it was finite. You're not going to a bank for a loan, you beg people with experience in software to believe you're trending up.
> During the ZIRP era it was all about "engagement" and DAUs/MAUs, then it was blockchain, and now it's all about AI.
Do you genuinely believe DAUs/MAUs stopped mattering once crpyto, then AI, arrived?
Your argument requires believing that engineers collectively ran a con that no investor, board member, or executive noticed for a decade, and the only people who figured it out were PE firms after 2022. That's conspiracy theory dressed in finance vocabulary.
The leveraged buyout model you're praising as "normal capitalism" is itself subsidized by cheap debt. You've correctly identified that cheap money distorts incentives. You've just misidentified which side of the transaction is the distortion.
ZIRP was the era of where any tech startup was seen as a good investment no matter how stupid. Take any stupid business that doesn't work, say you do it with tech, get millions thrown at you. Then it was blockchain - same story, conventional business that doesn't work, but with blockchain - boom, instant money. Now the same with AI.
> you beg people with experience in software to believe you're trending up
Considering how much stupid shit I've seen funded (that quietly "incredible journey'd" away or folded by now) I don't think much begging was involved. Capital was desperate to find a place, no matter how ill-advised. Everyone in the startup food chain enjoyed it.
> Do you genuinely believe DAUs/MAUs stopped mattering once crpyto, then AI, arrived?
What started mattering is a clear path to monetize said DAUs/MAUs. You can't just show up with (potentially flawed) analytics saying you have DAUs and you're gonna figure out monetization later. Now you need to actually figure it out now and show up with analytics + proof of actually monetizing those users. Well, except if you're selling AI - then it's ok to sell inference at a major loss and figure out monetization later.
> collectively ran a con that no investor, board member, or executive noticed for a decade
"Investing" in a Ponzi can still be profitable as long as you get out before it collapses. There was a lot of passing around the hot potatoes between VCs too, so a VC can rightfully determine something to be a scam, but still invest if they believe SoftBank will happily hold the bag (and those guys ended up taking a lot of bags).
> "except if you're selling AI - then it's ok to sell inference at a major loss and figure out monetization later"
So the dynamic you attributed to ZIRP is alive and well, just wearing different clothes. Your original framework was "ZIRP allowed this, now real capitalism is correcting it." Now it's "this is permanent, it just rotates themes." These are different arguments.
> "Investing in a Ponzi can still be profitable as long as you get out before it collapses... a VC can rightfully determine something to be a scam, but still invest"
You've just moved the con from engineers to VCs. If investors knowingly played hot potato, then engineers weren't running a grift, they were employees doing jobs while capital played musical chairs above their heads.
So which is it: were engineers "deadweight" padding out finished products, or were they ordinary workers caught in a game VCs were knowingly playing? Because "VCs knew it was a scam but invested anyway" is a very different story than "engineers tricked everyone into thinking the product wasn't finished."
You're retreating into "everyone knew it was fake."
I'm making the argument that past bubbles like ZIRP, blockchain and now AI have given many engineers the illusion that "engineering" the same product forever is a sustainable endeavor.
Turns out that's not the case and with each bubble popping more and more people get a rude awakening. Some are able to jump on another bubble and keep the gravy train going, but might be left in the dust in the next one and so on.
If anyone was conned, it's primarily the younger engineers who started their career in those bubbles, were never exposed to the financial realities or even forced to think about it, and now get a very unpleasant wake up call.
You may disagree with my argument - but in that case I suggest taking a short position on Bending Spoons & their competitors who appear to be making the same argument and putting their money where their mouth is.
You started by calling engineers "deadweight" that Bending Spoons correctly cuts. Now they're victims who were "conned" and given "illusions" and deserve sympathy for their "unpleasant wake up call."
These are incompatible framings. Deadweight is culpable. Victims of a con aren't. Which is it?
> I suggest taking a short position on Bending Spoons
Strip-mining is often profitable. That's not the disagreement. The disagreement is whether "profitable" validates your original framing that the workers being cut are deadweight rather than, by your new admission, ordinary people who were lied to by the actual decision-makers.
Note also the lack of understanding of finance, coupled to parroting pop-finance, continues. You're trying valiantly to hammer phrases we all know, into meanings they don't have. They sound epic, and are very "law of nature" feeling. I understand the appeal. Anyways, you cannot short a company without a stock.
I guess that was poor framing on my part from the beginning; I used the term deadweight meaning overhead that can be cut, not implying culpability one way or another.
Which positions are culpable or victims is besides the point here (I have other comments on ZIRP related threads if you are interested, where I do make direct accusations).
> ordinary people who were lied to by the actual decision-makers
Were they truly lied to? They got paid for years of service. Now whether they got lied to by Bending Spoons denying there will be layoffs I don't know (or whether the lie matters - for all we know they got a fair severance package, at least in places where that is legally mandated?).
But for those who started their career in the "good days", I would say they got misled by an environment that rewarded raw engineering without concern for the business outcome of said engineering (and often rewarded over engineering in fundamentally unsustainable businesses). Now the business outcome is suddenly becoming the most important thing and these people are taken by surprise.
---
Now it's clear you have some kind of beef with me; I'm either talking complete shit, or I struck a nerve. Maybe a bit of both. Either way I will not pursue this conversation further - best of luck!
I don't have some kind of beef with you. I react personally too in these long discussions, don't begrudge you the impression.
Just saw what I thought was youth, but it was a fellow older fellow*, so chased the interlocution more than I usually would because I was curious and wanted to make sure there wasn't insight I had missed and you were speaking loosely (as is normal, we are not robots)
re: motivation, I took a lot of pride in not taking money back in prime ZIRP, early-mid 2010s and felt it was vindicated by what I saw happen to competitors.
What I saw was proto-"Bending Spoons" behavior. Frankly, Bending Spoons seems ethical and right-headed at its face. i.e. after 30 seconds with their website. but what do I know.
What I saw was private equity rollup iPad-based point of sale software who couldn't justify another round, and let the business owners using their point of sale systems flounder until they got the energy to switch. Explicitly. the rug pull wasn't just on engineering or further development of the system, it was support too. That might sound stupid (who needs support w/software?), but its necessary for point of sale due to credit card processing. Multiple companies, same playbook.
Cheers & apologies, I went too far, I left you feeling like it was a grudge.
FWIW it's also important to me because I want a fellow wide-eyed college-dropout-waiter soaking in HN from a small town to know VCs involved in these messes will continue acting as they have post ZIRP, as you've established.
* via your HN profile, not stalking off site or based on username
No worries, all good! It's difficult to convey emotions and tone online.
> it was a fellow older fellow
~11 years professional experience only - still got plenty to learn, but unfortunately seen enough shit to be cynical. Started out starry-eyed in the middle of the ZIRP era ~2015 and made some salary off it but no exit money, though something felt off and I never understood the over-engineering at the time.
Then as I gained experience, switched to consulting to boost my earnings and looking back at it my (admittedly very jaded) opinion is that a lot of that "engineering" was performative bullshit enabled by cheap money, which continues to be the case in some verticals (blockchain; now AI).
Senior engineers of the time would've likely known it was bullshit and were just happy to play with new tech while subsidized by VCs, but unfortunately this "quiet part" was never said out loud to those who started their careers during this period and for whom their only experience of technology was through this distorted lens of cheap money and no financial/business pressures.
The result is a lot of very senior people tech-wise but with little exposure to the business side of their craft, who the readjustment hit like a brick wall. The fact my statement about maintaining a (well-built) product requiring much less manpower than building it is apparently controversial suggests many people have yet to experience this brick wall.
But for those who looked into the financials, the selling out and subsequent layoffs should've come at no surprise - it was never sustainable to keep paying those tech salaries perpetually. The same thing happened to blockchain/web3/crypto, and the same will eventually happen to AI.
There is still and will always be money to be made in technology, but it will be made by applying technology to business problems and approaching every problem as "how much money does this make/save and how big of a cut I can negotiate". Permanent employment is just letting someone else do said negotiation on your behalf in exchange for a promise of stability - well, turns out when the times are tough they don't have to keep that promise: plan accordingly.
(btw, this ZIRP-era distortion was not limited to technical roles - there were plenty of "startup founders" and executive roles too who got there because of the cheap money rather than earning said position through demonstrated skill - unsurprisingly, a lot of those people have since quietly transitioned back to the rank & file once the money fueling their little startup escapade ran out)
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.
> 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.
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."
Fair enough, a minority of businesses are run as public benefit corporations. But the vast majority is ran to generate profit. Bending Spoons especially.
> I wouldn't want to be just another tool to "extract" things from my customers
I assume you're independently wealthy and acquired said wealth from a generous donor who gave it to you with no expectations in return?
Because otherwise we're all "extracting" something.
I take pride in my work too and I believe the prices I charge for my services are fair - but nevertheless if I gave the choice to my clients between paying me for those services or getting them for free, they'd prefer free.
> This the type of thinking that gave us Windows 11
What's giving us enshittification and the terrible quality of software nowadays is the lack of healthy competition, because of lacking anti-trust enforcement and adversarial interoperability being effectively illegal. Companies thus take their customers hostage and raise prices/decrease quality.
Ideally we'd just make competition in tech a reality again which would put a limit on enshittification.
I'd question why your "head of Communications" isn't already aware of alternative vendors for important pieces of their domain. After all, companies go out of business, get bought out, change pricing all the time. And Vimeo was bought out months ago - this person didn't start researching then, just in case? I'd suggest the CEO start "looking for alternatives" for this employee.
I'd question why your "head of Communications" isn't already aware of alternative vendors for important pieces of their domain.
I don't like the guy, so it's not like me to defend him, but perhaps because he's busy being the head of the Communications department, instead of a tech nerd?
My company produces thousands of pieces of communication each year in many different forms. Video is a small part of what his department does, so you make the false assumption that this is an "important piece" of his domain.
I wouldn't be surprised to learn he doesn't have some internal cronjob to constantly search for alternatives to every single one of the (probably hundreds) of vendors we have around the world.
It's very weird that you feel that you're in a position to second-guess a person you never met, in a job you've never done, in a company you don't know, in an industry you also don't know. That's Olympic-level hubris.
You said: 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.
And now you're saying he might have a "cronjob" constantly searching for alternatives? Well then your original point is neutered, he's not going to "start" since he's already been looking.
And video is only a small part? Not an "important piece"? Well then why should Vimeo's owners manage their company based upon what low-level users think? Again, you've minimized the point of your original post to irrelevancy.
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)
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.
> 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.
I agree you don't need a large software engineering headcount for maintenance. But there's multiple factors that change the estimate:
- You need redundancy in case someone leaves, is hit by a bus, gets sick, wants to go on vacation
- The software is bespoke, so staff need to know the ins and outs of all of it
- The more software to maintain, more knowledge needed, and more maintenance tasks
- Poorly built software/systems need a lot more maintenance
- The business leaders may (erroneously) keep asking for more changes, which creates a greater engineering load
- If the business value is based on technological capability, you will eventually need radical changes to keep up with new tech
Now, in a few cases, you can cheat. Wordpress requires less maintenance if you rely on canned plugins. But security patching is constant, and eventually you have to upgrade the entire thing as old plugins and core version go EOL. Managed instances help a lot here but still break from upstream changes. And as browsers change, so do the frontend software's compatibility.
The more complex software you depend on, the more expertise you need to fix things. If your usage keeps growing, but your app wasn't designed to scale ("just use Postgres" is not a scaling solution; some things even buying more hardware won't fix), now you need someone to bust open walls and add extensions to the building. That's a lot more dangerous with software contractors than the original engineers.
If your entire stack and app is bespoke, and you run your own VMs, or god forbid, run your own metal, it's a much larger maintenance burden (to keep it running well; lots of people limp along for years on broken equipment and software, at high risk to the business)
If we actually did build software more like we build buildings, we could bring in contractors for short stints to do either maintenance or new construction. But the complexity of current software engineering trends makes that fail a lot of the time.
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.
> “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?
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.
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.
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.
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.
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.
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.