Lessons from bootstrapped companies founded by software engineers(newsletter.pragmaticengineer.com)
newsletter.pragmaticengineer.com
Lessons from bootstrapped companies founded by software engineers
https://newsletter.pragmaticengineer.com/p/lessons-from-bootstrapped-companies
33 comments
Autodesk (ADSK, market cap US$45 billion, founded 1982) is a bootstrapped company founded by software engineers with their own money. Mostly mainframe UNIVAC systems programmers in their 30s. No VC funding; the IPO came well after profitability.
This was the VC term sheet they rejected, for reference...it's pretty bad! :-)
https://www.fourmilab.ch/autofile/e5/chapter2_32.html
https://www.fourmilab.ch/autofile/e5/chapter2_32.html
"Frank Chambers chose to forgo an investment of $500,000 which, if held until the stock price hit its 1987 high, would have appreciated to more than $37 million."
Oi, hindsight is great. The '87 high was about $3.50. ADSK is sitting at $210 today or $2.2B for that 500k investment.
Oi, hindsight is great. The '87 high was about $3.50. ADSK is sitting at $210 today or $2.2B for that 500k investment.
As co-owner of a mildly profitable bootstrapped software enterprise it seems to me the common major weakness is lack of sales and marketing expertise to make it go bigger. However for many software people this is a feature not a bug.
Yeah I have some decent side projects that I think could be useful in the marketplace; however, I have no skills for the sales and marketing of it.
It seems to be common advice to bootstrap your business, but at some point you need a salesperson to get the product into the hands of users. The only exception to this is if it is something truly revolutionary like the next Google/Amazon/etc.
B2C bootstrapping seems even harder because you really need to know how to acquire users.
It seems to be common advice to bootstrap your business, but at some point you need a salesperson to get the product into the hands of users. The only exception to this is if it is something truly revolutionary like the next Google/Amazon/etc.
B2C bootstrapping seems even harder because you really need to know how to acquire users.
There are no exceptions.
Google the search engine was paid for by Google Ads past the initial period and those are certainly marketing and sales.
Amazon certainly focused on sales stuff early on. And while AWS is a technical marvel the pricing scheme of hiding costs behind outbound data costs was brilliant. Evil but brilliant.
Having a good product is the goal of Engineering and that is the bare minimum.
Google the search engine was paid for by Google Ads past the initial period and those are certainly marketing and sales.
Amazon certainly focused on sales stuff early on. And while AWS is a technical marvel the pricing scheme of hiding costs behind outbound data costs was brilliant. Evil but brilliant.
Having a good product is the goal of Engineering and that is the bare minimum.
For indies, the making is the marketing. They don't need separate marketing because they build 100 MVPs openly in public, with an extremely fast feedback cycle (days), and see what to focus on next. So the secret is not knowing what to build, but just building it quickly and seeing what "sticks".
I don’t even think it’s expertise. Assuming you have a good and valuable product, sales and marketing is still just extremely hard.
You have to remember that 90% of the startup successes we hear about are VC funded, so can make a significant loss on sales and marketing. To fund it from cashflow makes the game even harder still.
You have to remember that 90% of the startup successes we hear about are VC funded, so can make a significant loss on sales and marketing. To fund it from cashflow makes the game even harder still.
How you deal as a co-owner with the fact that some mid-cap company can go after your product and make it a feature?
Yes, while more money is welcome, hiring staff beyond say 3 people is not really what a solo dev wants to do. Ideally hire no one!
Again, not much value without also interviewing bootstrapped founders who failed. I'll bet good money that there are plenty of founders who followed every single one of those lessons and failed because of some other reason.
Thanks for sharing, I enjoyed the read. Is there anything like this for how companies like these marketed their products to generate interest in potential users and onboard new users?
Instead of working fixed hours, I frequently spread out my work throughout the day and week. This is a distinct part of Formspree culture, that comes from how my cofounder and I prefer to work.
We encourage our team to choose their own hours, so if you don’t feel like working a particular afternoon, you can just take it off. On the flip side, when you feel the itch to get something done on the weekend, it’s ok to push code.
Weird take. Since when does “pushing code” equal “releasing to production”?
FWIW, I love this mentality for healthy, work/life-balanced teams. It works if you structure around it. I often get the itch during the weekend to do a little work, so I go for it, because I can balance my days as I see fit. Ride the wave of creativity when it arrives, go do something else — like taking a hike, or running errands — when you can’t get shit done.
FWIW, I love this mentality for healthy, work/life-balanced teams. It works if you structure around it. I often get the itch during the weekend to do a little work, so I go for it, because I can balance my days as I see fit. Ride the wave of creativity when it arrives, go do something else — like taking a hike, or running errands — when you can’t get shit done.
I assumed the GP was just concerned about somebody pushing code to a shared trunk branch that happened to break a build. Though as it happens I do know of some shops that literally do have a CI/CD pipeline that's so automated such a push would result in a production update (of course such a set-up wouldn't even allow a push if it did break the build, or cause any of the steps in the pipeline to fail). But yes, I'd normally interpret "pushing code" as pushing to your own feature branch, in which case I'd wonder "is it really so unusual for devs to do this out of hours"? I've certainly done it on weekends before, but with no expectation that anyone would review/merge the changes until normal business hours.
> pushing code to a shared trunk branch that happened to break a build
You revert that commit, then. It's broken. A revert shouldn't be take as some mark of failure or personal offense, it's just that your commit breaks the build, so it's getting removed from `main` until such a time as it doesn't do that. It happens to us all, from time to time. Those reverts almost always carry what at any profession organization should be an implied "feel free to bring this in a PR again, with fixes".
(And ideally, a bit of introspection as to "why didn't CI catch the failure when it was still on a branch?")
You revert that commit, then. It's broken. A revert shouldn't be take as some mark of failure or personal offense, it's just that your commit breaks the build, so it's getting removed from `main` until such a time as it doesn't do that. It happens to us all, from time to time. Those reverts almost always carry what at any profession organization should be an implied "feel free to bring this in a PR again, with fixes".
(And ideally, a bit of introspection as to "why didn't CI catch the failure when it was still on a branch?")
"You revert that commit, then. It's broken."
Personally I don't see why it's likely to cause major issues to allow people to merge PRs outside of business hours either, but depending on your team workflow and build pipeline (which may not be fully automated for any number of reason) it's not that hard to imagine cases where it's preferable to ensure all pushes to trunk occur during business hours (e.g. for cost saving reasons maybe you don't keep particular services running 24x7 that are needed to allow your integration test suite to run fully).
Personally I don't see why it's likely to cause major issues to allow people to merge PRs outside of business hours either, but depending on your team workflow and build pipeline (which may not be fully automated for any number of reason) it's not that hard to imagine cases where it's preferable to ensure all pushes to trunk occur during business hours (e.g. for cost saving reasons maybe you don't keep particular services running 24x7 that are needed to allow your integration test suite to run fully).
> e.g. for cost saving reasons maybe you don't keep particular services running 24x7 that are needed to allow your integration test suite to run fully
We did this at an employ of mine. They were on-demand, and spun up when you committed.
I was mostly responding to what appeared to be the fear of "but what if someone broke main off hours!"
We did this at an employ of mine. They were on-demand, and spun up when you committed.
I was mostly responding to what appeared to be the fear of "but what if someone broke main off hours!"
It’s blatantly obvious that the quote from the article isn’t talking about pushing to #main and potentially breaking production during the weekend. If a team practices true CI/CD, they surely have excellent safeguards and 1-click (if not automated) rollbacks in place.
I imagine the only people who would think otherwise have some pretty dysfunctional repo setups and/or policies.
I imagine the only people who would think otherwise have some pretty dysfunctional repo setups and/or policies.
I sadly suspect the number of development teams with dysfunctional repo setups/policies somewhat outnumbers those with best practice configurations! Actually I can't say I've ever worked anywhere that would truly have qualified for the latter category.
Is that with the understanding that your employer is more amenable to you taking time off during the weekdays if you do happen to spend time working on the weekends? Because many employers would want to have it both ways and not allow you to take time off the weekday just because you worked during the weekend.
Yes, everyone at my $WORKPLACE is free to adjust their work schedule to whatever best suits them; we don't care about ass-in-seat or hours of work, we care about output and impact.
This isn't just lip-service, either. May be hard to believe from a US perspective, but for a Norwegian based company, it can be taken at face value. It's the best place I've worked in my 22+ years.
Minor asterisk; we do have a few hours every week where you should be present (check-ins, meetings, all-hands, etc), but it's <5h/week for most people.
This isn't just lip-service, either. May be hard to believe from a US perspective, but for a Norwegian based company, it can be taken at face value. It's the best place I've worked in my 22+ years.
Minor asterisk; we do have a few hours every week where you should be present (check-ins, meetings, all-hands, etc), but it's <5h/week for most people.
No worries, it's very believable as I worked in a role like that as well. However, there were certainly issues like production-related, getting unblocked by teammates, etc that necessitated being on during much of the workday, so most people didn't work weekends on top of that either. It wasn't the US-centricity that caused this outcome but rather technical issues. I assume if your company does not have the same issues then it's much easier.
In reality, most people are working core hours, say 10am-3pm local time. Most are in UTC +/- 2 hours. I’m an outlier, remote from B.C, Canada.
It’s usually best to stick with a “normal schedule” for family/socializing reasons, anyway.
But, it’s incredibly freeing, being able to work when the mood strikes. I used to be a night-owl, often getting super creative in the evenings. I could force myself to bed, sure, but a 3-4 hour stint in the evening would regularly produced outsized returns. 8-9am+ couldn’t remotely compete, creativity-wise, so why force it? Build a culture around trust and impact, it works out a lot better than anything else I’ve seen in practice.
I rarely do late nights anymore, having transitioned to 6-7am starts, an hour or two hiking around lunch with the dogs, and a small handful of hours of wrapping up & planning for tomorrow. But that was all my choice :)
It’s usually best to stick with a “normal schedule” for family/socializing reasons, anyway.
But, it’s incredibly freeing, being able to work when the mood strikes. I used to be a night-owl, often getting super creative in the evenings. I could force myself to bed, sure, but a 3-4 hour stint in the evening would regularly produced outsized returns. 8-9am+ couldn’t remotely compete, creativity-wise, so why force it? Build a culture around trust and impact, it works out a lot better than anything else I’ve seen in practice.
I rarely do late nights anymore, having transitioned to 6-7am starts, an hour or two hiking around lunch with the dogs, and a small handful of hours of wrapping up & planning for tomorrow. But that was all my choice :)
I do it all the time. I prefer to enjoy the world while others are working. Weekends are also a nice moment to break things, most of the people I work with wouldn't notice.
Isn't this the penultimate goal of CI/CD? Release anything, anytime, anywhere? I'm envious of a business that trusts their process (and their employees) that much.
// Isn't this the penultimate goal of CI/CD
What's the ultimately goal then? :) (it took me forever to learn than penultimate means "second most" so I am passing it on!)
What's the ultimately goal then? :) (it took me forever to learn than penultimate means "second most" so I am passing it on!)
Yes. Also rollback plans/systems and canary releases and things like that should be used to minimize the effect of mistakes. CI/CD cannot prevent 100% of mistakes.
The slash between CI and CD means they can be decoupled. Push whenever you want, see if it builds. See it deployed the next business day.
Imagine having nothing better to do on your weekends than coding for a form SaaS lol
Better to break the build on a weekend when nobody is around to be inconvenienced.
This type of cynicism on hacker news is out of control
The culture you want is one of responsibility and ownership. If you push to production, you make sure there are some people around to help if there is an outage. You make sure there is a rollback plan etc.