A Company of One(rishad.substack.com)
rishad.substack.com
A Company of One
https://rishad.substack.com/p/a-company-of-one
57 comments
I suspect that AI will be an accelerator for this.
It's not gonna replace us. It will help us to be more productive.
It's not gonna replace us. It will help us to be more productive.
The biggest issue for founder-type programmers is not code volume, its code quality.
Most founding code of products I have seen is the most fucked up, horrible, over- or under-engineered, hacky, buggy, usually platform-specific and NIH covered pile of hot shit.
Strong dependencies on half-assed internal data structures, stretch marks everywhere ("we did it like this because we had time pressure, and it was wrong, and now we cant get rid of it"), weird protocols ("we will just use a stringly-typed header for our high performance TCP communications, its easier to debug!"), lack of documentation ("no bro, the code is the documentation!"), and very little if any devops or testing (lol testing).
Thats good that way, too, otherwise products would never be launched. Thats why a lot of engineers will not launch a product, ever - their standards are too high and theyre too hung up on doing it right, that their window of opportunity for their niche fades.
The one thing I haven't seen a single startup or upcoming product struggle with is quickly churning out a lot of code that mostly/fully does the job and sells.
Unless AI can replace engineers like me, half of who's job experience is cleaning up, streamlining and refactoring these "quick launch" codebases, in order to make the code last even if core engineers leave and to make onboarding easier, we are NOT going to see a massive revolution of AI programming tools.
Most founding code of products I have seen is the most fucked up, horrible, over- or under-engineered, hacky, buggy, usually platform-specific and NIH covered pile of hot shit.
Strong dependencies on half-assed internal data structures, stretch marks everywhere ("we did it like this because we had time pressure, and it was wrong, and now we cant get rid of it"), weird protocols ("we will just use a stringly-typed header for our high performance TCP communications, its easier to debug!"), lack of documentation ("no bro, the code is the documentation!"), and very little if any devops or testing (lol testing).
Thats good that way, too, otherwise products would never be launched. Thats why a lot of engineers will not launch a product, ever - their standards are too high and theyre too hung up on doing it right, that their window of opportunity for their niche fades.
The one thing I haven't seen a single startup or upcoming product struggle with is quickly churning out a lot of code that mostly/fully does the job and sells.
Unless AI can replace engineers like me, half of who's job experience is cleaning up, streamlining and refactoring these "quick launch" codebases, in order to make the code last even if core engineers leave and to make onboarding easier, we are NOT going to see a massive revolution of AI programming tools.
> The biggest issue for founder-type programmers is not code volume, its code quality.
> Most founding code of products I have seen is the most fucked up, horrible, over- or under-engineered, hacky, buggy, usually platform-specific and NIH covered pile of hot shit.
I dunno your background, but I think you have it almost completely, 100% incorrect in your first paragraph, while being completely, 100% correct in your second.
The summary is this: if you're launching a product, you want to do it as soon as possible, damn the quality of the code as long as the quality of the product is sufficient.
The reason for this is because, 9 times out of 10, you're going to be throwing all that code away anyway! It's rare that the first product you ship is successful.
And if it does get successful? Well, then you have the money to redo it, refinish it, polish it, address tech debt, whatever.
There's only two outcomes: the product succeeds or it fails.
If, in the rare case, you launch a successful product and the code is clean, perfect, etc, you haven't gained anything over the person who launched a half-assed, broken-but-still-sufficient successful product. The competitor can still get his product to your standards because they succeeded.
If you fail, then you have spent unnecessary time determining what doesn't work, while the competitor has spent less time and can attempt another product after his failure, while you're still perfecting your first failure.
> Most founding code of products I have seen is the most fucked up, horrible, over- or under-engineered, hacky, buggy, usually platform-specific and NIH covered pile of hot shit.
I dunno your background, but I think you have it almost completely, 100% incorrect in your first paragraph, while being completely, 100% correct in your second.
The summary is this: if you're launching a product, you want to do it as soon as possible, damn the quality of the code as long as the quality of the product is sufficient.
The reason for this is because, 9 times out of 10, you're going to be throwing all that code away anyway! It's rare that the first product you ship is successful.
And if it does get successful? Well, then you have the money to redo it, refinish it, polish it, address tech debt, whatever.
There's only two outcomes: the product succeeds or it fails.
If, in the rare case, you launch a successful product and the code is clean, perfect, etc, you haven't gained anything over the person who launched a half-assed, broken-but-still-sufficient successful product. The competitor can still get his product to your standards because they succeeded.
If you fail, then you have spent unnecessary time determining what doesn't work, while the competitor has spent less time and can attempt another product after his failure, while you're still perfecting your first failure.
> if you're launching a product, you want to do it as soon as possible, damn the quality of the code
I think this is where I disagree - cutting corners is really not faster. Especially now a days with the tech and libraries we have available, you don't have to overthink or overbuild either. Cutting corners saves no time, and then the startup needs to pivot and can't easily due to the ham strung code.
"Useful tech debt", etc is usually just an excuse for impatient devs or people who aren't very good.
I think this is where I disagree - cutting corners is really not faster. Especially now a days with the tech and libraries we have available, you don't have to overthink or overbuild either. Cutting corners saves no time, and then the startup needs to pivot and can't easily due to the ham strung code.
"Useful tech debt", etc is usually just an excuse for impatient devs or people who aren't very good.
I should have qualified my statements with "probably" and "the majority of the time". There is more nuance to this than I considered when I wrote my reply.
However, that being said ...
> I think this is where I disagree - cutting corners is really not faster. Especially now a days with the tech and libraries we have available, you don't have to overthink or overbuild either.
Cutting corners saves a boatload of time if you're only ever testing the Happy Path. HP-only testing, alone, roughly halves the time to ship a product, once you realise that no dependency-injection would be required so you just hard-code the dependencies in the class hierarchy or data structures.
More time can be saved by sticking to a single platform ("Does this Go program work on Windows too?" "Meh. Who cares?"), yanking in every library there is ("Why does this run so slow?" "Because developing for Electron is faster than making a native app").
The point is, quality takes time. It takes longer to prepare a great meal from fresh ingredients than it does to simply assemble a picnic from nothing but KFC, McDonalds and Krispy Kreem. It takes longer to build a house from concrete and block than from wood and siding.
> Cutting corners saves no time, and then the startup needs to pivot and can't easily due to the ham strung code.
If the startup is pivoting, then they're likely throwing away most of what they built anyway. That's the whole point of the pivot - you switch from producing a product for solving $FOO to a product for solving $BAR.
If you aren't throwing away most of what you have written, you aren't pivoting.
However, that being said ...
> I think this is where I disagree - cutting corners is really not faster. Especially now a days with the tech and libraries we have available, you don't have to overthink or overbuild either.
Cutting corners saves a boatload of time if you're only ever testing the Happy Path. HP-only testing, alone, roughly halves the time to ship a product, once you realise that no dependency-injection would be required so you just hard-code the dependencies in the class hierarchy or data structures.
More time can be saved by sticking to a single platform ("Does this Go program work on Windows too?" "Meh. Who cares?"), yanking in every library there is ("Why does this run so slow?" "Because developing for Electron is faster than making a native app").
The point is, quality takes time. It takes longer to prepare a great meal from fresh ingredients than it does to simply assemble a picnic from nothing but KFC, McDonalds and Krispy Kreem. It takes longer to build a house from concrete and block than from wood and siding.
> Cutting corners saves no time, and then the startup needs to pivot and can't easily due to the ham strung code.
If the startup is pivoting, then they're likely throwing away most of what they built anyway. That's the whole point of the pivot - you switch from producing a product for solving $FOO to a product for solving $BAR.
If you aren't throwing away most of what you have written, you aren't pivoting.
I absolutely agree with you, and I should have phrased my first sentence better:
The biggest issue for founder-type programmers [when their product is successful and now they need to grow it] is not code volume, its code quality.
The biggest issue for founder-type programmers [when their product is successful and now they need to grow it] is not code volume, its code quality.
Simply not true, and this post represents the biggest fallacy most technical founders struggle with.
The most common problem is they never ship anything.
Or they ship something no one needs.
Or they ship something people need but don't know how distribution works so those people never find it.
I'm someone who's spent enough time writing high quality code that my default thinking is in line with yours, but the truth is it's a privilege to get to a place where you can afford to hire people to clean up your "quick launch" codebase.
Even if you look at it from a place of personal pride, there is more pride in proving your idea solves real problems for real people today, than there is in chasing an ideal codebase that scales better tomorrow when you don't even have proof anyone wants it.
The most common problem is they never ship anything.
Or they ship something no one needs.
Or they ship something people need but don't know how distribution works so those people never find it.
I'm someone who's spent enough time writing high quality code that my default thinking is in line with yours, but the truth is it's a privilege to get to a place where you can afford to hire people to clean up your "quick launch" codebase.
Even if you look at it from a place of personal pride, there is more pride in proving your idea solves real problems for real people today, than there is in chasing an ideal codebase that scales better tomorrow when you don't even have proof anyone wants it.
Each software framework, whether they be java, python, js frameworks, would have its own finetuned llm, which the foundation maintaining the framework would provide. It's the next evolution of documentation. Instead of consulting the docs, people would consult these doc-llms. Thank God, we have llama 2 for this purpose.
Some stuff won't be needed in more quantity.
So if what was needed had five people and now three people can do that same job, two are let go. Of course, things will sort themselves out eventually, but whenever fast shifts occurs, a lot of throwing under a lot of buses will occur in the meantime.
So if what was needed had five people and now three people can do that same job, two are let go. Of course, things will sort themselves out eventually, but whenever fast shifts occurs, a lot of throwing under a lot of buses will occur in the meantime.
It will replace some people, and the benefits of productivity will be reaped by someone else.
[deleted]
The most liberating insight I had in studying economics is that every person in a relatively free country already is a company of one, even if each individual is “employed” by another company. The negotiation of salary or wage is one in which the employee is negotiating the price of his/her labor, and in that sense is selling something, or purchasing services/facilities from the employer, or in reality both.
This might be a controversial take but by that reasoning, I don't think America is a particularly free country. Most people need to work whatever shitty job they can get and class mobility is relatively difficult even with things like higher education and the like
“Most people need to work whatever shitty job they can get”
Even as someone who grew up well below the poverty line, this wasn’t true ime. The vast majority of adults aren’t impoverished. They’re quite clearly choosing not to work the shitty jobs that would make them impoverished, usually through skills they’ve chosen to acquire.
While I don’t have the stats on what percentage of people exercise job choice — these stats are completely unobtainable - I don’t think there’s an argument that can reasonably suggest it’s >50 (or even 20)
Even as someone who grew up well below the poverty line, this wasn’t true ime. The vast majority of adults aren’t impoverished. They’re quite clearly choosing not to work the shitty jobs that would make them impoverished, usually through skills they’ve chosen to acquire.
While I don’t have the stats on what percentage of people exercise job choice — these stats are completely unobtainable - I don’t think there’s an argument that can reasonably suggest it’s >50 (or even 20)
I think that most people have the possibility to choose, but the cost of choosing (in terms of lost income, lost vacations, uncertainty and risk to immigration status) are prohibitive enough to favour the employers.
Sure, people can upskill or move across the country, but that's prohibitively expensive and not guaranteed to work. A lot of people are trapped by this.
Sure, people can upskill or move across the country, but that's prohibitively expensive and not guaranteed to work. A lot of people are trapped by this.
You're right. Employees do tend to have a lot of options. But I think the balance is still in employers' favor for most workers when it comes to making decisions for the employee.
Running your own business is not necessarily more freedom than being employed. It's easy to think you can decided everything yourself, but you have customers pulling you here and there, you have rules and regulations, accounting, taxes, bills. Maybe sales is not going as well as you want or you have too much work on your table which is hard to off-load.
Companies with only one customer are generally not very stable.
Defense contractors beg to differ
That's an exception, for several reasons. The US government isn't going away any time soon, and can't just die or go bankrupt like a normal customer. Also, the government has an interest in keeping multiple contractors competing with each other, so they'll intentionally spread work out among competing contractors to keep them all busy and in business. It's just not like any other company.
Also, defense contractors frequently have multiple customers, in a way. First, many contractors sell their stuff to foreign customers (after getting approval from the USG of course, frequently with degraded capabilities). Lots of countries are buying the F-35 for instance. Also, contractors frequently have multiple customers within the government. They might sell to the Air Force and the Army, for instance, or the CIA and the NSA. Those are all different agencies, and act like different customers, without that much coordination between them, and each has its own funding and does its own contracts with contractors.
Also, defense contractors frequently have multiple customers, in a way. First, many contractors sell their stuff to foreign customers (after getting approval from the USG of course, frequently with degraded capabilities). Lots of countries are buying the F-35 for instance. Also, contractors frequently have multiple customers within the government. They might sell to the Air Force and the Army, for instance, or the CIA and the NSA. Those are all different agencies, and act like different customers, without that much coordination between them, and each has its own funding and does its own contracts with contractors.
All good points.
Go further. On the outside, you've got maybe 75,000 hours to sell. After that, the warehouse is empty. Better try to get the best price you can for each one.
Most workers in the USA and elsewhere cannot negotiate their salary.
I am all about small companies but they lost me at web 3.
Came to say the same
> Web-3 while out of favor will eventually enable more ownership and equity for individuals.
Giant red flag not to trust anything this guy says, since he has zero clue.
> Web-3 while out of favor will eventually enable more ownership and equity for individuals.
Giant red flag not to trust anything this guy says, since he has zero clue.
what's not being said: unless you're rich, it's much better to aim for a small, profitable business within the first 3 months and a low 7 figure exit. If you can't figure out how to do this, work for someone else until you do.
I think the genz are very aware of this.
I think the genz are very aware of this.
Three months? Can you share any data or case studies around such a number? Part of me finds it unbelievable (and part of me really wants to believe).
From a look at the two books mentioned here, though, neither seem to clear that bar.
Zero to Sold is about FeedbackPanda, which took 2 years. (Still impressive.) And Company of One, from a skim, appears to focus on services businesses — totally reasonable to get to six-figure revenue and therefore seven-figure valuation, but not terribly interesting as product companies and fairly difficult to exit via a sale.
I'd love to see some case studies of the 3-month number. The more I think about it, the more possible it seems (with a fair bit of luck).
From a look at the two books mentioned here, though, neither seem to clear that bar.
Zero to Sold is about FeedbackPanda, which took 2 years. (Still impressive.) And Company of One, from a skim, appears to focus on services businesses — totally reasonable to get to six-figure revenue and therefore seven-figure valuation, but not terribly interesting as product companies and fairly difficult to exit via a sale.
I'd love to see some case studies of the 3-month number. The more I think about it, the more possible it seems (with a fair bit of luck).
Both the services companies I started were profitable within 8 weeks. (6 and 8 respectively.) One was sold 14 years later, the other is still going.
Services companies are very fast to get started, and very easy to make profitable.
Building a product company on the other hand...
Services companies are very fast to get started, and very easy to make profitable.
Building a product company on the other hand...
The rationale behind the 3-month number is that most people will need an income by that time since savings will have run out. It's entirely possible to start a service-based business and be profitable from day 1.
I think they mean join a company within 3 months of its founding, to max out shares/options.
As I read it, the working for someone else (a company) is the alternative, for the case in which you can't get profitable in 3 months.
I think you're right. Hell, a lot of GenZ'ers find the very idea of billionaires to be abhorrent, let alone strive to become one. Can't say I disagree.
I always find the anti-billionaire sentiment a bit weird in the sense that it's not like they have literally been given billions of dollars in cash. Most billionaires net worth is highly centralised in the stock of the companies they founded, which at some point were worth nothing.
When people say they find the "very idea of billionaires" abhorrent, what exactly is the solution here? After the stock in your company becomes worth > billion you have to give it away for free? Because selling it means you are still a billionaire. I think there is something to be said about inheritance taxes and limiting the infinite perpetuation of wealth through generations but unless we are talking asset seizure I am not quite sure how you would do away with the Musks, Brins, Gates' etc. of today.
When people say they find the "very idea of billionaires" abhorrent, what exactly is the solution here? After the stock in your company becomes worth > billion you have to give it away for free? Because selling it means you are still a billionaire. I think there is something to be said about inheritance taxes and limiting the infinite perpetuation of wealth through generations but unless we are talking asset seizure I am not quite sure how you would do away with the Musks, Brins, Gates' etc. of today.
> When people say they find the "very idea of billionaires" abhorrent, what exactly is the solution here?
There’s a quote[1] which makes the rounds occasionally and I think sums up the sentiment pretty well:
> Ok how about this:
> No more billionaires. None.
> After you reach $999 million, every red cent goes to schools and health care.
> You get a trophy that says, “I won capitalism” and we name a dog park after you.
---
> Most billionaires net worth is highly centralised in the stock of the companies they founded[...] unless we are talking asset seizure I am not quite sure how you would do away with [billionaires]
Marginal asset tax rate of 100%? (Really, the main difference between that and the inheritance tax you favor is the timing.) The Wikipedia article[2] has a bunch of arguments for why that might be a bad idea, but it’s reasonably straightforward in principle.
[1] https://twitter.com/Mikel_Jollett/status/1241843944238923777
[2] https://en.wikipedia.org/wiki/Wealth_tax
There’s a quote[1] which makes the rounds occasionally and I think sums up the sentiment pretty well:
> Ok how about this:
> No more billionaires. None.
> After you reach $999 million, every red cent goes to schools and health care.
> You get a trophy that says, “I won capitalism” and we name a dog park after you.
---
> Most billionaires net worth is highly centralised in the stock of the companies they founded[...] unless we are talking asset seizure I am not quite sure how you would do away with [billionaires]
Marginal asset tax rate of 100%? (Really, the main difference between that and the inheritance tax you favor is the timing.) The Wikipedia article[2] has a bunch of arguments for why that might be a bad idea, but it’s reasonably straightforward in principle.
[1] https://twitter.com/Mikel_Jollett/status/1241843944238923777
[2] https://en.wikipedia.org/wiki/Wealth_tax
This already exists.
It's called taxes, death, and children. Billionaires only have a single lifetime to spend their wealth, taxed at pretty high rates when they actually liquidate their assets, and it eventually evaporates over a few generations.
There's ~3k billionaires and they're powerful enough that they'll be able to avoid those caps through loopholes, like through shell companies. There's no real practical way to prevent someone from accumulating wealth if they wanted to continue to do so.
That quote about no more billionaires is from someone that cares more about making a point than actual policy.
It's called taxes, death, and children. Billionaires only have a single lifetime to spend their wealth, taxed at pretty high rates when they actually liquidate their assets, and it eventually evaporates over a few generations.
There's ~3k billionaires and they're powerful enough that they'll be able to avoid those caps through loopholes, like through shell companies. There's no real practical way to prevent someone from accumulating wealth if they wanted to continue to do so.
That quote about no more billionaires is from someone that cares more about making a point than actual policy.
> There's no real practical way to prevent someone from accumulating wealth if they wanted to continue to do so.
Not within a capitalist system, no. There are other systems though.
Not within a capitalist system, no. There are other systems though.
This worked surprisingly well in the communist countries. Look at China and Russia. There has never been a black market where distributors go rich. Never once.
That's easy. They shouldn't even come close to being billionaires. How? Stock should not be theirs in the first place.
Investors are buying the company's stock, why would it be theirs?
Especially after going public, it's not "your" company anymore.
Investors are buying the company's stock, why would it be theirs?
Especially after going public, it's not "your" company anymore.
And the investors aren’t billionaires themselves? Do you think investors give away their money for nothing? What are you even talking about?
> When people say they find the "very idea of billionaires" abhorrent, what exactly is the solution here? After the stock in your company becomes worth > billion you have to give it away for free?
Yes. Arguably it was never rightfully theirs to begin with—owning someone else's labor output without working yourself is a pretty antisocial act.
Furthermore I'd argue that billionaires have repeatedly demonstrated they are unable to invest in public good. Philanthropy used to be a thing; even the Bill and Melinda Gates foundation is a pathetic shadow of that practice with obvious ideological blind spots.
Yes. Arguably it was never rightfully theirs to begin with—owning someone else's labor output without working yourself is a pretty antisocial act.
Furthermore I'd argue that billionaires have repeatedly demonstrated they are unable to invest in public good. Philanthropy used to be a thing; even the Bill and Melinda Gates foundation is a pathetic shadow of that practice with obvious ideological blind spots.
>owning someone else's labor output without working yourself is a pretty antisocial act.
This is what happens when you buy literally anything. What is the distinction you are trying to make?
This is what happens when you buy literally anything. What is the distinction you are trying to make?
> This is what happens when you buy literally anything.
Well presumably if you buy from the sole creator of a product, they're justly compensated as they could simply refuse the sale. Buying from a privately owned enterprise allows the owners of the enterprise to siphon off of the work of the people who actually build the phone without contributing anything themselves. That doesn't sit right with me, and it doesn't sit right with a lot of people. This creates hugely perverse incentives that magnify to global economic dysfunction and inefficiency and irrational resource distribution and social volatility. The world we live in!
Well presumably if you buy from the sole creator of a product, they're justly compensated as they could simply refuse the sale. Buying from a privately owned enterprise allows the owners of the enterprise to siphon off of the work of the people who actually build the phone without contributing anything themselves. That doesn't sit right with me, and it doesn't sit right with a lot of people. This creates hugely perverse incentives that magnify to global economic dysfunction and inefficiency and irrational resource distribution and social volatility. The world we live in!
> what's not being said: unless you're rich, it's much better to aim for a small, profitable business within the first 3 months and a low 7 figure exit. If you can't figure out how to do this, work for someone else until you do.
That is basically what the book Company of One says, yes. Zero to Sold is also another good book in the same vein.
That is basically what the book Company of One says, yes. Zero to Sold is also another good book in the same vein.
thanks for the rec
low 7 figures after how long?
Had a boss sell after 3 years. The last two were ramping up and then two big clients boosted the books. Sold the contracts with clients for about 6x revenue.
Why do you need to exit?
You don't need to but you might not enjoy having all your eggs in your one basket.
because the whole point of starting a business is to get it to run by itself.
Eventually you (the founder) won't be needed anymore.
Eventually you (the founder) won't be needed anymore.
It took me a while to realize this, as I began my startup journey over valuing software skills and under valuing business skills, but you truly need marketing, sales, and legal (business ops) in addition to product and engineering. As a solo tech guy you can do product and engineering, but the other areas are neglected unless you can pivot away from development and focus on those.
Small, highly profitable companies are totally feasible. But making a big splash with a product (not just consulting / freelancing) is extremely difficult as a single person.
Small, highly profitable companies are totally feasible. But making a big splash with a product (not just consulting / freelancing) is extremely difficult as a single person.
I am wondering what is the greatest product-based company in terms of revenue and impact that had no more than one programmer. To be strict about the definition I am looking for a company that generated cash (not raised it) while still having a relatively small programming team.
Top of my head plentyoffish and minecraft are the two main ones that probably everyone heard of? If you relax the condition of 1 programmer a bit then whatsapp is certainly up there.
Also if you consider btc a product (although I am not a fan of crypto) and don't believe the theories about satoshi being a group, then btc is definitely up there. In fact this one needed almost less than one programmer since you had to do very little 'maintenance' after the codebase stabilised.
Top of my head plentyoffish and minecraft are the two main ones that probably everyone heard of? If you relax the condition of 1 programmer a bit then whatsapp is certainly up there.
Also if you consider btc a product (although I am not a fan of crypto) and don't believe the theories about satoshi being a group, then btc is definitely up there. In fact this one needed almost less than one programmer since you had to do very little 'maintenance' after the codebase stabilised.
Battlebit 3 people team and it seems just 1 dev https://joinbattlebit.com/meet-the-team/
Flappy Bird
Ludeon Studios, the guy behind Rimworld. They raised a kickstarter though.
> The Avengers are successful not just because they work together but because each one of them whether it be Wonder Woman or Iron Man have their own unique powers. They have powers of “one”.
I think if you're going to use analogies, you should stay away from things you don't really know about.
Wonder Woman exists in a different universe from Iron Man - One's DC (Justice League, WW, Superman, etc) and the other is Marvel (Avengers, Iron Man, Hulk, etc).
I think if you're going to use analogies, you should stay away from things you don't really know about.
Wonder Woman exists in a different universe from Iron Man - One's DC (Justice League, WW, Superman, etc) and the other is Marvel (Avengers, Iron Man, Hulk, etc).
> how life could fit into work ?
This should never have been the question in the first place!
This should never have been the question in the first place!
As with most paradigm shifts, many are sleeping on this. But expect small teams to be behind more and more of the most influential software of the next decade. And the traditional mindset on what is a company and how growth happens will also evolve.