"Best Practices" for bootstrapped software companies in 2015?

(I don’t particular like the term “Best Practices” but for want of a good alternative…)

What are the practices that a one- or two-person bootstrapped software company should be performing in 2015? I’ve been trying to find up-to-date books and websites that describe this in some kind of rigour, but I’m getting nowhere.

I guess the Joel Test is a good starting point albeit a dated one.

Kinda scared to share this, as I hope to launch a mailing list reminding people to do these sorts of things, but here’s the outline I’ve collected:

Document procedures

Test procedures


Verify backups

Store recovery information offsite

Take down a subsystem and see how rest of your system handles the problem

Perform a load test

Run an intrusion test


Patch software

Document all software versions

Build a hot backup

Switch to hot backup

Document your database schema

Perform a database dump

Verify you can load your database dump

Automate manual procedures

Make a smartphone control panel for your system

Verify you can recover site using only a smartphone

Design for scalability

Design for recoverability

Evaluate technologies used

  • can you easily hire contractors
  • is it still being supported

Prepare support for when you are away

Have an unannounced vacation/emergency and see what happens

Evaluate your overall readiness

Create a business continuity plan

Create a succession plan

A/B test

Review your pricing, segmentation

Get detailed feedback from a customer

Think about how you could pivot your product to a different market

Test your (contact) forms, contact email addresses, etc.

“Simple exercise: use an actual credit card to buy an actual copy of your product quarterly. That experience is important but hidden to you.” —Patrick McKenzie @patio11


Steve’s list looks comprehensive but there are best practices for every step of the journey and some may not apply to you depending on where you are.

I mean are you really going to spend time creating a succession plan before you have your first customer?

Hmm that list looks very devops too… and there is no marketing on there?

Ok maybe the list isn’t good after all. I have no idea why building your email list isn’t on this but restoring from a backup on your phone is…

John, yes, it’s a very incomplete list heavily weighted toward devops tasks. I thought it would be helpful even with those limitations, so I posted it. Would love to see your take on the business side.

Here’s one that I find invaluable, eg when I made some build-breaking changes this morning:

Always be building

Every committed change triggers a new build on a dedicated build server that uses “continuous integration”.

  • If you’ve broken anything, you find out in minutes.

My mantra for 2015 is: “If we add this feature/make this change to the app, will it attract new customers and/or help retain existing customers”.

I’m spoiled in a way because I own a software company that was bootstrapped, and have a lot of developer resource available to Staff Squared. As a result it’s incredibly important to make sure that any dev resources I use are aligned with the happiness of our customers.

1 Like

I think as software developers we tend to come at everything from a software developer mindset but marketing and sales/onboarding/support is far more important.

Customers will forgive you if you ship a bug by accident.

Customers you don’t have because you’ve focused too much effort on development and not enough on marketing won’t.

Sure I’ve got automated backups and continuous integration and deployments and all that jazz but I would never list it is as being important enough to be in a “best practices” list.

1 Like


You make a good point. However with regards to competitors, then it is powerful to be able to produce better software than them, quicker that them. That’s where the best practices come in to effect, IMO.

I have to agree, that development shouldn’t be the sole focus, but it is necessary. Great marketing + lousy product might be a more viable business than lousy marketing + great product, but it’s hardly the dream. How many of you went in to business saying “I want to deliver a mediocre product that more-or-less does the job, backed by kickass marketing”?

Here’s my top-of-mind list for an early stage SAAS.

  1. Do you have at least one customer?
  2. Can you reach more customers?
  3. Is the cost of reaching those customers less than LTV? (although, maybe this isn’t an early stage concern)
  4. Do you have SMART goals for 2015? Do you have a plan to achieve them?
  5. Do you have processes for the repetitive tasks involved in running your business?
  6. Are you outsourcing the repetitive tasks involved in running your business?
  7. Do you use a PAAS like Heroku?
  8. Automated build
  9. Automated test

The requirement around PAAS might be controversial, but for a one or two man shop it adds so much value that there really isn’t any other way to get. PAAS gives you a 24/7 team of expert devops. That, for me, beats by a country mile either learning to do devops yourself or hiring a single person to do your dev ops.