(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
Backup
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
OWASP
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
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”.
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.
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.
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.
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.