6 ms·

Lessons from bootstrapped companies founded by software engineers

99 points by BerislavLopac 3y ago

GravityLab 3y ago
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?
vore 3y ago
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. What?? Push code on the weekend??? I hope the people at Formspree enjoy being inconvenienced at totally random times for when someone breaks something on a weekend!
- dudul 3y ago
  Better to break the build on a weekend when nobody is around to be inconvenienced.
- t1mmen 3y ago
  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.
  - wizofaus 3y ago
    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.
    - t1mmen 3y ago
      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.
      - wizofaus 3y ago
        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.
    - deathanatos 3y ago
      > 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?")
  - satvikpendem 3y ago
    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.
    - t1mmen 3y ago
      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.
      - satvikpendem 3y ago
        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.
        t1mmen 3y ago
        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 :)
- candiddevmike 3y ago
  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.
  - quickthrower2 3y ago
    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.
  - xyzelement 3y ago
    // 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!)
- slavetologic 3y ago
  This type of cynicism on hacker news is out of control
- quickthrower2 3y ago
  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.
- is_true 3y ago
  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.
- hcks 3y ago
  Imagine having nothing better to do on your weekends than coding for a form SaaS lol
- esafak 3y ago
  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.
dave333 3y ago
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.
- quickthrower2 3y ago
  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!
- benjaminwootton 3y ago
  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.
- makestuff 3y ago
  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.
  - Guvante 3y ago
    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.
- dinvlad 3y ago
Animats 3y ago
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.
- phonon 3y ago
  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
  - thenobsta 3y ago
    "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.
marcus_holmes 3y ago
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.

99 points by BerislavLopac 3y ago

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?

vore 3y ago

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. What?? Push code on the weekend??? I hope the people at Formspree enjoy being inconvenienced at totally random times for when someone breaks something on a weekend!

dudul 3y ago
Better to break the build on a weekend when nobody is around to be inconvenienced.
t1mmen 3y ago
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.
- wizofaus 3y ago
  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.
  - t1mmen 3y ago
    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.
    - wizofaus 3y ago
      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.
  - deathanatos 3y ago
    > 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?")
- satvikpendem 3y ago
  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.
  - t1mmen 3y ago
    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.
    - satvikpendem 3y ago
      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.
      - t1mmen 3y ago
        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 :)
candiddevmike 3y ago
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.
- quickthrower2 3y ago
  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.
- xyzelement 3y ago
  // 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!)
slavetologic 3y ago
This type of cynicism on hacker news is out of control
quickthrower2 3y ago
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.
is_true 3y ago
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.
hcks 3y ago
Imagine having nothing better to do on your weekends than coding for a form SaaS lol
esafak 3y ago
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.

dave333 3y ago

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.

quickthrower2 3y ago
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!
benjaminwootton 3y ago
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.
makestuff 3y ago
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.
- Guvante 3y ago
  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.
dinvlad 3y ago

Animats 3y ago

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.

phonon 3y ago
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
- thenobsta 3y ago
  "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.

marcus_holmes 3y ago

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.