We currently use a small US contract manufacturer that works pretty much as you say. The turn times are terrible (7+ weeks, not 7 days), and this is a major issue, but there are exactly two reasons we continue to use them:
1. Line of credit - we are not billed until we take delivery of tested product.
2. Willingness to handle high mix, low volume products. One product line example: a dozen SKUs with 95-98% parts in common on 2 PCBs, a single set of parts (that we aren't billed for up front) and quoting to build 20 of SKU 1, 50 of SKU 2, 10 of SKU 3, etc. without charging 2-3x the price.
We manufacture in the research / test equipment / defense space and I've heard similar things from other small hardware companies that are like us.
My experience with lines of credit isn't unique, and I think it's one of the underrated advantages of doing business in the US: we have a sufficiently stable commercial legal system that a huge amount of the economy can run on credit.
I have thought that there is a big opportunity financing components by optioning the sale of overstocked parts ahead of time. For a consumer electronics product that had heavy Q4 sales, my annual sales were entirely dependent on how many chips I could order by October 19, but then I'd have excess stock every January because things are sold in reels of varying sizes.
The improvements were for things governments (fuel/pollution efficiency) and insurers (safety) wanted, not necessarily you.
A new 2010 Toyota likely wouldn't even be legal to sell today in many jurisdictions, and this is in fact one part of the problem.
Another part of the problem is that all the big automakers need to design a new car roughly every 5 years in order to keep from losing the ability to design one at all, as people age and retire. What's really been settled on is that "minor updates every year and a major update every 5-6 years" actually does work in terms of keeping know-how to design these things, as well as handle supply chain problems.
For example, if a chip you need goes EOL and you have to redesign around that, it's much better to have that happen in the last 1-2 years of your manufacturing, you do a last time buy to get through that last year, and move on. Much harder to do on a longer lifecycle: that 2010 design, sold new in 2026, and operated until 2040+. How many suppliers go out of business over 30 years, or stop making a critical component?
Run on server, chroot into target environment, configure compiler flags for eventual target, done. It's really just an afternoon of setup and then the problem is solved.
Who actually pays for what and how is so mangled that if you want to reallocate someone to another project (or even just pay them out of a different pool of funds!) often the easiest approach is to rehire them through a contractor, or a different contractor.
This is especially useful when projects are wound down. Let's say you've contracted to an org for support or management on a project that you want to kill, you've already obligated some amount of funds, and you don't really want to make that organization angry by ripping millions away from them (the pool of contractors is not large). What to do? Well, you could take Joe and give him a raise by suggesting he work for the contractor instead of you directly. Money's already spent, anyways. So you save your own money that you can use for your pet projects or whatever, Joe gets a raise, the contractor doesn't get a termination that pisses everyone off. Everyone happy, right? Smh.
There's a lot of maintenance that is much easier/cheaper to do when the apartment is unoccupied, so the default is "do nothing, then when the tenant moves out in a year or two, do a couple years of maintenance much more affordably."
With your gym, for example, when it's new, you can do all the work you want. Once people are using it every day (especially if it's a 24/7 facility!) how exactly do you get in to do major work without making a bunch of people annoyed that half the gym is out of service for three weeks? You don't, until it gets to the point that people would prefer the downtime ... and this takes a surprising amount of grime.
Uber's situation is exactly the same. OpenAI is offering inference for a bunch of industries at prices that make it more competitive than hiring humans to do the same work.
If the break-even price to actually provide the service wasn't actually economic compared to humans, would there be nearly as much of a market? That's the real question. OpenAI is basically betting that they can live long enough that AI systems get built around them, which creates enough of a lock-in that they still have customers when prices increase by a lot.
I think you underestimate the price by a few orders of magnitude where it makes sense to pay a model instead of a human. If someone earning 200,000 a year gets replaced by paying 500 a day to Anthropic or OpenAI their employer comes out ahead.
There's likely always going to be value in limiting the number of $200k+ SWEs you have to pay. But that's not the interesting case.
What about the $10k/year offshored employees that are getting replaced by AI call centers? If that were the break even, then once you close down the whole building and develop the systems to not need them, then how much would inference costs have to go up before all that gets unwound and handed back to humans? It's more than you think - there's real margin there.
One heuristic I use to avoid this exact problem is "minimize the number of places that the next poor soul has to look in order to understand how this code works", where place is loosely defined as about the number of lines of code that fit on a screen or two.
This has given really good results in terms of helping decide whether to extract these helper functions or not - they have to both be memorable enough in name and arguments that the code calling them can understand what's going on without always having to dive in, and also provide a meaningful compression of the logic above so that it can be comprehended without having to jump across many hundreds of lines.
Mobile users (or other locked down devices where adblockers are forbidden) are still a decent chunk of traffic. It's much easier to just read the overview and not click through to the ad infestation, or even use a chatbot of choice as the search engine instead of going to Google, because "websites is how you get spammed with ads".
The part where you are forbidden from using a web browser that isn't Safari (Chrome + FF use Safari under the hood) without jailbreaking the phone?
On my Android phone, I installed Firefox. It synced my extensions and installed uBlock automatically. That was it.
The last time I tried on iOS, I gave up. The adblockers I found didn't really work, they were painful to install, and the platform is so locked down that I couldn't figure out other options.
Not on iOS, there Firefox is actually Safari under the hood and you can’t use extensions…
Haven’t found a good solution yet (other than avoiding websites with ads)
2. Brand quality went down to equivalent or less of no-name dropshipped goods in order to keep similar dollar prices for goods.
3. Cost of real estate spiked incredibly, putting even more pressure on retail margins.
4. American logistics is seriously good, in cities 24-hour delivery can be common even for small or inexpensive things.
5. Once there wasn't a quality or convenience reason to prefer the shopping mall, many were already struggling quietly, they just hadn't run out of cash yet.
6. The pandemic happened right as all these things converged, accelerated all of them, and wasn't really recoverable.
It allows the code to be fully public domain, so you can use it anywhere, while very strongly discouraging random people from forking it, patching it, etc. Even still, the tests that are most applicable to ensuring that SQLite has been built correctly on a new compiler/architecture/environment are made open source (this is great!) while those that ensure that SQLite has been implemented correctly are proprietary (you only need these if you wanted to extend SQLite's functionality to do something different).
This allows for a business model for the authors to provide contracted support for the product, and keeping SQLite as a product/brand without having to compete with an army of consultants wanting to compete and make money off of their product, startups wanting to fork it, rename it, and sell it to you, etc.
It's pretty smart and has, for a quarter century, resulted in a high quality piece of software that is sustainable to produce and maintain.
1. Line of credit - we are not billed until we take delivery of tested product. 2. Willingness to handle high mix, low volume products. One product line example: a dozen SKUs with 95-98% parts in common on 2 PCBs, a single set of parts (that we aren't billed for up front) and quoting to build 20 of SKU 1, 50 of SKU 2, 10 of SKU 3, etc. without charging 2-3x the price.
We manufacture in the research / test equipment / defense space and I've heard similar things from other small hardware companies that are like us.