Ask HN: Important nonobvious startup/business lessons you've learned?
Running a business is hard. Startups are even harder. A lot of it comes down to not actually knowing what you're doing wrong.
What are some important observations and lessons you've learned working at startups and running businesses that were not immediately obvious (both technical and non-technical)? Did you learn the hard way?
255 comments
[ 3.2 ms ] story [ 274 ms ] thread* This message pre-censored by HN in order to preserve curiosity.
For consumer products, your product must cut through the clutter. For business products, it must exceed the hassles of buying (and it usually has to be a top 1-3 priority for the buyer).
Although absolutely start selling before you get there. For the feedback, not revenue.
How are these things non-obvious? Isn't that like business lesson numbers 1, 2, and 3?
2. Expect your startup/business/product to morph into something else, and that you'll change names and domain names, maybe multiple times.
3. You need an origin story, especially if you want any press. It also helps to be good looking.
1. If the idea is any good, you‘ll quickly encounter others who are better funded and need to execute extremely well. „Build it and they will come“ has worked for the tiniest minority or orgs I‘ve worked with and for, it certainly hasn‘t for us.
2. If your original idea is well researched and partially proven or already sold before building, why pivot? We didn‘t regret to sink a tenth of our initial invest into a great domain and brand.
3. True that. If you can‘t put your business model into a one sentence elevator pitch that includes a real-world problem and its solution that someone will actually pay for, din‘t even start…
I would respectfully disagree with this.
There are a few startups (e.g. Facebook), whose market timing is so perfect, that it's a sure-fire hit from the start.
But I have known so many companies that had founders struggling to make sales, as their timing was off. Then some market shift occurs, and what once was hard becomes easy.
COVID is a great example of something which induces a seismic shift everywhere. Remote work companies for example, would have suddenly found sales an order of magnitude easier.
Attention is scarce and there are already lots of good alternatives for almost any product idea. You better be good at sales and marketing if you want to cut thru the noise. A good product is not good enough.
Most startups don’t need press - unless you are asocial media app, chances are customers won’t pay simply because TechCrunch or CNN mentions you. They pay to get their problems solved.
What is a fair way of measuring someone's effectiveness. It is easy to try and be kind but if you e.g. have a salesperson who is not selling, they need to go.
It is tempting to think you can't afford great people early on but plenty of businesses prove that great people sometimes put belief in the product or an interesting job/challenge or potential equity above a base salary.
I read and bought into Basecamps reasoning about no-by-the-seat-pricing(1) and tried it for Submotion. Now, it's always hard to know why people don't try your product out, but two people kindly hinted to me that they were confused by the price and thought that it meant that they didn't really understand what they were getting.
Obviously, as with any advice, this applies in specific situations only but it's now something that I keep in mind, not only in pricing: remove any unnecessary source of confusion, even if it's clever. Not unlike code :-)
(1) (https://m.signalvnoise.com/why-we-never-sold-basecamp-by-the...)
The sad thing is that the boss is right.
Experience can't be shared to team member. I don't mean that experience can't be documented and read. But that readers don't have visceral feeling upon reading. It goes both way.
First, team members with limited experience don't internalized why certain things is done certain way. They "know" it through indoctrination. It could be cultural or technical. This leads to reinventing wheel or people sharing some random blog article and following advice blindly. You want to exploit your experience.
Second, it is hard for yourself to identify blindspots. Trust and delegate is easier said than done. You want to explore unknown hence expand the island of experience.
Have a mental model on where you and your teammates are on the relative experience spectrum and switch between explore and exploit is important. Fast iteration/feedback cycles help you identify that relative position on the spectrum.
Because results are ranked by some metrics, if you make your thing 10% better (watch time, play time, CTR etc.), it will not only reap the direct benefits of being that much better, but the indirect benefits of now outranking others whenever the situation arises where it can get recommended vs. others (recommended videos, games, search results).
So it can make sense to put in more time into making something just a little better than would seem intuitively reasonable. MrBeast and Tim Urban of WaitButWhy both talked about this in their podcast interviews.
There will come a time when someone in a very large organization will take an interest in your product. You're going to feel very validated because now you can tell friends, family, investors, potential customers that X is using/piloting your product. They may or may not give you money, but it will certainly be less than your time is worth. They will definitely take a very long time to make any kind of decisive move. It is very likely that they will destroy your focus and never actually become a real customer. The longer you engage with them, the more you will want to make something come out of it and the worse the impact will be.
The Basecamp pricing model (flat monthly fee) is not often emulated by other startups, but it's worked well for Basecamp.
Why we never sold Basecamp by the seat ( (2017): https://m.signalvnoise.com/why-we-never-sold-basecamp-by-the...
if a component is core to your strategy or product then by all means make sure it's rock solid.
but if you're iterating on your product and you don't know which feature is going to be used then don't waste time perfecting it.
we put together in days products that we shutdown in 3 months, we would have never been able to move at such speed if we took our time plan, design, develop ...
and business people do come with a lot of things that go nowhere (depending on your company sales culture of course and product maturity)
But as a counter point, early in a product lifecycle you don't even know if the product you are building is what you are going to find a market fit for. So spending a lot of time getting the tech perfect is sometimes a waste. It's a constant calculation of balancing the risk of not scaling with the risk of taking so long you never get to the point where you can scale.
The talented person that built the thing knows exactly what a change will require, and how to test it before pushing his code.
Don't be an enterprise too soon.
The opposite. Tests are for people who know exactly how the product works. It's very hard to write good tests if you don't understand the product (or at least your piece).
I really hope you are being sarcastic. Tests when done properly speed up development and make your product more robust and resistant to breaking changes.
For a proof of concept that will never see production, sure, by all means don't write tests. But in my 15+ years in CTO and Principal role at smaller companies, the most expensive projects with the most downtime are always the ones without tests.
Tests make software cheaper not more expensive. And the ROI isn't even that long... all it takes is for two to three iteration / release cycles.
This post outlines how to destroy a new (or any) business.
There will never be anything approaching 100% clarity between different people talking about a thing that doesn't yet exist.
We all have to see it and feel it in order to truly understand it.
This experience almost always leads to creating new, better ideas, discarding old ideas and digging deeper on others.
That's all before we even leave the building and learn from customers.
I shudder to imagine trying to get a start up off the ground and needing to wait 3-6 months for the first commits only to then have to argue about change orders with my eng team.
Though I empathize with the overall desire, you sound inexperienced to me, as in, you might have had some failures that you attributed to lack of planning or business decisions, etc, but you haven't learnt from successes, because some of the stuff you're saying is just extreme counterproductive wishful thinking to the point where it sounds like trolling.
For example, 'building cool rock-solid code' is typically not a business goal or at best, a nice to have. Developers are hired to solve a business problem. If the code doesn't solve the problem, you're wasting precious resources. 'cool code' is a personal choice.
Compromising is essentially a trade-off like any other, and it requires careful deliberation in every context. Your opting to not compromise by default means that you're introducing friction in the team, in the business relationship and potentially affecting the life of the business, not to mention that it's a 'us vs them' mentality when you're supposed to be part of a team to deliver a product together.
Your reasoning about hasty decisions biting you is also backwards. Notice how you're just assuming that a product will start getting enough users to need to scale. Guess what: like most products, the product you worked on was actually not that great, didn't have a good product-market fit and if you hadn't spent all that time polishing and planning the cool non-junior code, you might have saved everyone months of time.
Also you go from 'never skip planning' to 'take as long as you need'. Those are 2 extreme approaches. It turns out that a little planning goes a long way. You can come back and iterate on the plan. No plan is going to be perfect from the start, because you don't have all of the information available to you when you start a project. As you develop a project, you get more information on hidden requirements, user expectations, non-functional requirements and various other metrics that you couldn't have thought about ahead of time.
What you are describing is the waterfall approach to software development and the only way it doesn't fail is if the domain and the product are very well understood (e.g. "build a grep clone in Rust"), but most products aren't well understood ahead of time, only in retrospect, so it's a constant back-and-forth between acquiring new understandings about the product and applying them in practice by changing what's already there. It requires your code to be flexible, not 'cool' or 'rock solid'.
Consequently, you will never get 100% visibility into what you are building. If you find yourself thinking "gee I know exactly what we are building" you are setting yourself up for disappointment when 'the business people' pull the rug under all your diagrams and schemas and types that you spent months designing instead of getting a usable POC out the door asap.
Honestly, it's just a phase you're going through. Once you get burned by your current approach a few times, you'll internalize the need to avoid either extremes and you'll start looking for that middle ground with each project. I know it because I went through the same phase in my career. Good luck!
The only reason why this becomes a phase that burns developers out is that writing high quality software is hard, under-appreciated and needs to be painstakingly learned by experience and guidance by experienced mentors. But most projects in the industry are complete shitheaps where the seniors need to spend all their time fighting fires instead of teaching the craft to juniors. No wonder developers get burned out.
You're hitting the nail on the head about burning out though. I suppose it's just the way the cookie crumbles.
Thanks for your awesome reply! Means a lot to me! Let me dive along! To make this discussion more interesting from the start, I'm going to say that we managed to raise $2M with an MVP written in 4 months, and now I have to rewrite everything because the business team pivoted 180 degrees. Bear with me a little.
> Though I empathize with the overall desire, you sound inexperienced to me, as in, you might have had some failures that you attributed to lack of planning or business decisions, etc, but you haven't learnt from successes, because some of the stuff you're saying is just extreme counterproductive wishful thinking to the point where it sounds like trolling.
The only failure I feel is that I haven't really managed to employ the right people for the right job. This forces me to take care of everything - really, like I have to refactor Typescript interfaces or CSS for other people, which are trivial things but time consuming. On one hand, I have to move fast and deliver features as a team, but on the other hand, I have to teach people how to properly do their job.
> For example, 'building cool rock-solid code' is typically not a business goal or at best, a nice to have. Developers are hired to solve a business problem. If the code doesn't solve the problem, you're wasting precious resources. 'cool code' is a personal choice.
The expression 'building cool rock-solid code' might've been just me venting my frustration - it's not that hard to do a good job it if you know what you're doing. But you're 100% right: I'm wasting resources if I don't implement the business needs in a timely manner. I actually managed to pull that off before raising the money.
But I'm also aware that difficult problems have more than ordinary solutions. I took care of our infra, from Proxmox, docker, Google Cloud, Jira, Confluence, Cloudflare, to Slack, emails, Jira, Confluence and others. The business team just says: "we could've employed anyone to do that".... really ....
> Compromising is essentially a trade-off like any other, and it requires careful deliberation in every context. Your opting to not compromise by default means that you're introducing friction in the team, in the business relationship and potentially affecting the life of the business, not to mention that it's a 'us vs them' mentality when you're supposed to be part of a team to deliver a product together.
Actually you're right and this is the reality. IMO, I see the grand scheme of things, where I know what "should" be done, so we could attain 100% autonomy and be able to scale without coding anymore, whereas the business team needs some features NOW, forcing me to do shortcuts. This is why I'm pushing to build a roadmap, but it's obvious we cannot do it right now.
> Your reasoning about hasty decisions biting you is also backwards. Notice how you're just assuming that a product will start getting enough users to need to scale. Guess what: like most products, the product you worked on was actually not that great, didn't have a good product-market fit and if you hadn't spent all that time polishing and planning the cool non-junior code, you might have saved everyone months of time.
We have 10k users, we have the market fit, we have the funding. The only problem is that I built everything for a specific business case, and now I have to abstract it to support the previous business case, plus new others, which are completely different. It's like building a new product from scratch. And my pain is that we could've thought about it from the start - this would've allowed me to abstract some of business logic.
> Also you go from 'never skip planning' to 'take as long as you need'. Those are 2 extre...
It doesn't get sharper if you sharpen it indefinitely. You'll be wasting time and metal.
There's always a point of diminishing returns. Just get the tree down, because another task is waiting.
Trying to convince managers to do something won't always work. Presenting them with a growing problem and a solution will help convince them.
You might think your product is bad, but there are likely people making more money than you with worse products. Start selling early.
- After building a high growth / high churn product, I am OK sacrificing decreased growth for a significantly decreased churn rate. Great product with high churn is a hard business to build, even when customers love the product.
- One of the highest leverage decisions you'll make is deciding what to build. You can achieve a 1x, 10x, or 100x outcome with the same blood, sweat, and tears depending on what market you decide to build in.
- Choose something that aligns with your strengths. A good idea for me, might be a terrible idea for you if it doesn't leverage your specific knowledge (Naval calls this product / market / founder fit).
- Product is really freaking hard and relying on external contractors sucks, give someone technical a significant % of your company to own product development.
- Google Search & YouTube are likely one of your most important acquisition channels, because these are the only two platforms that consistently surface old content. Chances are, G can distribute your content better than you can yourself via email / social / copromotions, etc.
- High performers are cool, but high performers that document what they know so junior level team members can execute at the same level, or better is even cooler. Document everything you expect to hold someone accountable to doing in a specific way.
- Email recaps let me skip 10-15 meetings per week. I get the agenda, notes, and decisions that were made, and can jump in (but usually don't) at my leisure without sitting through the meeting.
All business are different, there is not one road to success, there are as many as successful companies. As a result non-contextual business advice is usually useless.
In B2B Enterprise also. Most companies fails not because they don't have a good product, but because they don't sell well enough
1. Few business problems can't be solved by more sales.
2. Cut expenses when the storm is approaching, not when you're soaking wet.
3. You can't eat assets or inventory. Don't get emotional about what you own, only about your cash balances.
4. Banks are your friend only when you don't need them. Corollary: One bank for borrowing, one for cash balance accounts.
5. 70 completed calls per week. Not emails, calls. You can do it, start now.
6. Don't be an asshole: https://en.wikipedia.org/wiki/The_No_Asshole_Rule
7. Hire and retain "T-shaped" people. In difficult times those employees execute across multiple domains.
8. Client, vendor or employee drama is quicksand. You assist with a stick or a rope, you don't jump in with them.
9. Don't romanticize work & try to avoid romance getting in the way of work.
10. You're only as happy as your unhappiest child. Prioritize good parenting over work. Good parenting = SOS: Self awareness, objectivity, selflessness.
11. Get a prenup. No, really, do get one.
12. Pay yourself according to a financial model that prioritizes healthy business cash balances, and not your personal desires.
Your children - their physical wellbeing, emotional and mental health, behaviour - have a profound impact on you that, for good or for ill, will absolutely colour your own behaviour and decision-making at work.
But the important part is to diagnose why you have low or declining sales. Sometimes it's because you don't have good sales people. But other times it's because the product you have isn't a good market fit, or it's really buggy, or your salespeople oversold and now your customers are unhappy with the actual functionality of your product.
So then the sale is made, but in a way that ends up destroying the long (and even medium) term health of the business. Product/engineering goes on a death march to get things done, by the end of it many of those folks are burnt out, customers are unhappy, and sales folks see the writing on the wall and are happy to bail with their fat commission.
It's like saying "do whatever you need to raise your stock price." There are healthy and unhealthy ways to do that, and the advice is useless if you don't carefully distinguish between the two.
Sales are important. However, as you note, sales now should not come at the expense of sales later (or lead to returns later, or etc). And debugging low sales is non-trivial.
Focusing on sales to solve internal problems is like focusing on work to solve internal problems.
It can work to an extent, but sometimes you need to solve the internal problem before you can get the results you need.
So it's a feedback loop that leads to circular thinking. The problem is when we try to blame the external side of the feedback loop, to avoid seeing that our internal side is the problem.
If you need "more sales" to fix it, the problem often lies somewhere else.
To a founder or CEO the word "revenue" is used where you're using "sales", it isn't wrong except in context but the intention was unambiguous to me.
(I’m noticing elsewhere in this thread that others are interpreting “sales” as sales departments or salespeople. Perhaps it’s a cultural thing, where the meaning of the plain word varies depending on where you live.)
Few problems (a/k/a most problems) can be solved with more sales (a/k/a sales as a P&L line item equating to revenue); but OF COURSE its what you do with the increased revenue/sales that matters. Buying a Bentley isn't going to solve the business problem.
Expressions like "A 20% increase in sales" are almost never used to describe an 20% increase in the sales department's headcount or budget. Most people would interpret that as a 20% increase in revenue from sales.
"Cost of Sales (COS)" in finance refers to the cost of making a sale, including all the costs required to produce the good or service sold, not just the compensation and other expenses associated with a sales department.
"Sales" as a noun does often refer to teh sales department, but there are times when it absolutely unambiguously means that, times when it almost never is interpreted as that, and times when it could go either way and a word like "revenue" would be clearer, but that doesn't make using the word" sales" to refer to revenue wrong.
The original comment which said "more sales"; I've never heard someone in business refer to salespersons with the cutesy "sales" so I don't think it's reasonable to think "more sales" refers to people, and if they meant a larger department they would have said "larger department", not "more (department)".
The comment below that also says "sales fixes everything", which, again, same logic as the original (and has the same author as two below where they clearly say "we're talking sales of things").
The comment below that is the only one clearly confusing sales people/department, with sales of things, "I don't think you can solve it with more sales people".
The comment you're directly responding to said "We're not talking about sales people or the department, we're talking about actual sales of things".
And you're saying someone, other than the person being corrected, 'clearly' meant the department or role? Nah.
no one said hire sales people; rather if you've got a problem, first look at increasing sales before you put your efforts elsewhere. This will either fix the problem or explicitly identify it.
Answering that later question can lead you into any direction. Maybe you need more sales people, maybe your product sucks, maybe you must spend more on marketing. The point is not on how, the point is that the later one is the one goal you can have more impact on, and it will lead you into solving the former.
1 - On this case, with higher salaries, but there isn't enough money to increase them, thus the actionable question.
AFAIK Engineers have an axe to grind with the sales department, not actual sales. Giving credit for a sale is a very subjective matter, and more often than not every sales person who so much as sent an email to the opp want credit - effectively taking advantage of the subjective nature as much as they can get away with. Even if in reality the customer had to pretty much talk around everyone on the sales team and speak with an engineer to gain confidence in the product. Then the engineer has to go play catch-up from the 1 hour meeting while the sales member gets % of the sale.
Corollary #2 - Nobody cares. You might love your baby (i.e., idea / product / startup) but nobody cares. At all. See Corollary #1 for more details.
I'd add: ARR is a metric, cash is king. (related to 2-4 from your list)
This obviously completely wrong. The only problem that can be solved by mores sales is when your are not selling enough. And even in this case just having more sales not always work.
I'm the first to say that what matter most for a company is its ability to have more customers. But having more sales when you sales org is badly structured will make you loose a lot of money. Same products problems won't be solved by more sales, same for Marketing problems, or People problems or actually any problem.
You might familiarize yourself with Rule #6 before commenting on Rule #1.
Read the original point. The OP is not saying sales globally optimizes all things, like how your sales department is organized, rather it mitigates (i.e "fixes") the problem. All your other points are secondary, and definitely don't hurt as much if you've got lots of sales.
Larry Ellison of Oracle definitely fails rule #6 but he gets at least one big thing right. There are only two roles: You're either building the thing or selling the thing.
I've seen companies where more sales has amplified the problem
EDIT: I use Sales as a shorthand for "Salespeople" but OP use Sales for "revenue" maybe ?
Yes, definitely.
"money brought in" is air that your company breathes. "lies to customers" is poison that your company drinks.
But calling 70 people to get 70 new advertisers is OK, or if it's early days 70 people who can get you some traffic.
While true, unfortunately in many (blue-leaning) states, they're starting to become at the judge's discretion. Absolutely sickening to be honest.
> Couples who have been living together for two years share the same legal rights as married couples in BC, including a 50/50 split of debts and assets—excluding pre-relationship property, inheritances and gifts.
With a rate of 40% for divorce, a pre-nup may no longer be just for marrying couples, it may be needed for any relationship where cohabiting occurs. Also, there is absolutely no chance the judge will side with the men in places known.
One of the reasons for me to consider leaving California.
Sorry to hear that.
> One of the reasons for me to consider leaving California.
You do realize that California is not an administrative subdivision of Oregon, but a completely different state, right?
It's required on HN for rich tech guys to threaten this from time to time.
https://news.ycombinator.com/newsguidelines.html
Instead of HN constantly defending California, I want us to take a hard look at what's wrong with this state and improve it; but I see a bad future and looking out for myself. I want California to be the best place on the planet to live. It is regressing at an ever increasing pace. I was talking to a SaksFifth employee in SF – he is working there since 1995. I talked to him for good 30 mins talking about how things were in Bay Area specifically. It is night and day compared to 90's.
Are you able to mention some of the things he said?
His ex-wife was a trainwreck, they faught and for so long, lost $100k+ in just attorney fees and yet, the Portland judge wouldn't give him a break. I couldn't fault a single thing in his character and offered to be a witness. His attorney did their best to put forth a case, had a psychology auditor evaluate his mental health, everything is flying colors. Still, the judge wouldn't give more time with his child.
FUCKED UP. Makes me angry just thinking about it. It made me realize that there is evil in this world in the most visceral way.
10. You're only as happy as your wife. If she's unhappy, you're unhappy.
As in people who have broad knowledge but also specific expertise?
Basically, but more like "capable in many areas but an expert in one (or two)".
https://en.wikipedia.org/wiki/T-shaped_skills
I know a startup that failed because they thought they were doing ok on sales, but it turned out: lots of people were signing up for the product, but then not using it, or not being able to, and un-signing soon after.
The venn diagram of tech skills and a non-tech business is where the opportunities are. This applies to many other unrelated skills.
You’re chances of success are 10x higher trying to build technology for tanning salons than it is building the next new docker kubernetes react native infrastructure as a service.
Unsexy sells.
Except tanning salons (or hairstylists or dog walkers or plumbers) usually a) dont have cash to spend b) Dont see their problems as software related c) are in many cases hostile to software, due to geniune bad software
I remember some time ago when I used to hang out in bootstrapped.fm, every week a person would come in and say "Oh I built a software for salons/hairstylists/dog walkers" how I can sell it? 4 weeks later they had shutdown their business, and a new person would come in, rinse and repeat.
This is also why this (very good) advice is not so easy to follow in real life. You need multiple skillsets.
If you're not as well placed as the incumbents at the core product (salon, sure), software will not save you.
If you're better placed than the incumbents at the core product, software doesn't matter.
If you're (roughly) equally placed as the incumbents at the core product, software can help you, but it will likely take a while to realize any competitive advantage.
And, I say placed, because there are a lot of factors at play. There's the quality of the service/product (itself a huge set of variables), pricing, location, and availability, to name a few. None of those will custom software directly help you with.
Guy owned two carwashes in Cary, NC. Thought technology could enable mobile carwashing. Got connected with the right technology people ...
Not for me; it has to be sexy, world and life style changing. I’d rather build something like one of the top used apps or just be an employee at a tech co.
Good if someone can pull it off. But, I believe that company might have sold that feature as an add-on to their existing customers. Otherwise, you know “Sales” are the hard part
That's what I also meant. Even if you start a business, the features that your product would have, will be sold as a "solution" - in layman's terms.
Why we are talking about low-hanging fruit instead of picking them up? I have a hunch they aren't low hanging after all.
The reason for that is the same reason your idea works, most businesses outside the tech bubble stand to gain a lot form software. Currently they have no way to act on it except to hobble together a ruby goldberg of SaaS services or try and cram their businesses into a monolithic piece of software that expects your business to run a certain way.
Most mid-sized companies don't have the skills to manage and deploy software developers that can solve their problems. Those skills tend to be expensive, and the software project, historically, has a high chance of failure.
So, yeah, the high price of tech wages seems to be correct.
I speak from experience in executing some of these kinds of software projects, as I live in a market not influenced by the SV bubble. Our market has a bunch of bootstrapped software businesses too, because the economics of it are more favorable to that kind of enterprise and you're not competing with 200k+ wages. I'm talking about Australia as well, an expensive first world country.
In fact, going into some market and solving a problem with software is almost always done by people not used to work in development that go and write something by themselves.
The answer that I think is a hard pill for some to swallow, is that for a long time we have been the tool required by special kinds of high return business ventures, so we can command high wages. The same is true of remote miners in Australia, the difference is there is no use for a miner in the rest of the community so there is no loss since no one is competing for their wage anyway.
My argument is simply that the rest of the economy could really use software developers, but they are too expensive due to the distortions on commandable salary that the tech bubble has created. It would be nice if software developers returned from the high heavens and integrated their skills more readily with the greater community.
I am a software developer, and I understand the audience I am talking to is the very audience benefiting from the status quo. I don't expect it to be a popular view but I do hope people give it a thought. Think of ways your talent could help your community, and then that is what I am hoping to see more of.
Another way of saying the same thing is that few businesses can see their revenue double by employing even the most skilled plumber. However, many businesses can see there revenue double (or their costs halved) by employing even a mediocre software developer.
So, I would agree it's true that we live in a special time in history where the translation of business needs to computer languages is being demanded at an ever higher and higher rate. But I would disagree with the framing of this phenomenon as a "tech bubble" or a "distortion on commandable salary".
Another way to look at the status quo is to see that the beauty of capitalism is that those areas that consumers see to be the most important areas to focus on having software developed ARE having software developed. Software developers are working on the most important projects they can be working on right now. However, the problems software developers are working on will change over time as: On that last point, I think it's interesting that the behemoths of software development are all seeing huge tectonic shifts in their industries occur. FB/Meta responding to Apple's/EU's/California's privacy enhancements. Google desperately trying to find a non-ads source of revenue, knowing that their cash cow could dry up in the not-too-distant future. Twitter being on the bleeding edge of discovery of "How much content moderation is too much?". Netflix figuring out it's tech moat wasn't as wide as it thought it was. Amazon...well, I'm not sure what tectonic shift is hitting Amazon yet, but it can't be far off.How many of these companies will be around in 10 years in the same form that they are today? Ford has been making vehicles for over 100 years. What will give Meta, as an arbitrary example, that kind of staying power?
As those companies come and go over the next 10-20 years, I think your concern that "the rest of the economy could really use software developers" will be ameliorated. Maybe everyone's actually working on unimportant problems right now, and the wider economy has more important problems for us to solve, but the best and fastest way we've figured out how to discover that we've misallocated resources (whether human or any other kind) is to let everyone make their own decisions and realize the individual gain or loss of their decisions.
In practice the most common option is to have everything run on massive Excel sheets, with spaghetti formulas and VBA coded by long-gone employees or interns. But it works.