└── README.md /README.md: -------------------------------------------------------------------------------- 1 | ### Overview 2 | A checklist of all things to consider for CTOs of SaaS startups. 3 | 4 | ### Who is this for? 5 | The CTO, first engineer, cofounder, or anyone at a pre-seed startup who is accountable for building the SaaS application. 6 | 7 | ### Checklist 8 | 9 | - [ ] Before you start building 10 | - [ ] Choose the boring technology 11 | - Focus on tech that helps you build your product, not keeping up with fads. New tech popularity is fleeting 12 | - https://mcfunley.com/choose-boring-technology 13 | - [ ] Have an opinion/a point of view in how you plan to work along with what you plan to work on 14 | - https://rubyonrails.org/doctrine/ 15 | 16 | - [ ] Tools 17 | - [ ] GitHub 18 | - [ ] Pick a Platform as a Service/cloud computing that you are most comfortable with 19 | - Minimal devops & easy deploy > cost efficency or performance 20 | - [ ] Have a CDN instead for providing assets from your web server 21 | - [ ] Start a wiki (use GitHub for it) 22 | - [ ] Setup Continuous Integration (CI) 23 | - Require CI to pass for PRs to merge 24 | - Enforce codestyle as part of CI 25 | 26 | - [ ] Architecture 27 | - [ ] Pick a lane 28 | - Server Side Rendering v/s Client Side Rendering 29 | - Monolith vs Microservices 30 | - [ ] Pick a framework that you are most comfortable with 31 | - [ ] User authorization and policy-based access, enforce authorization checks 32 | - Sooner or later, you will want to setup MFA/2FA 33 | - Start with password-based authentication. Eventually you will need to support SSO 34 | - [ ] "Admin" User 35 | - [ ] When setting up data models, think about teams/groups that you will eventually need to support 36 | - [ ] You will likely need to support a change/addition of domain name/subdomain/host in the future 37 | - [ ] Where will your marketing site and company blog run 38 | - If your marketing site is built within your app, you will become the bottleneck for growth/marketing 39 | - Having your app running on app.yourdomain.com from day 1 might make it easier to switch later 40 | - Avoid use of naked domains for hosts. They're inflexible when migrating between services. 41 | - [ ] Eventually you will need to provide an API 42 | - [ ] Set up servers with repeatable code 43 | - [ ] Automate DB backups, and regularly test restores (if self-managed) 44 | - [ ] Maintain a staging environement 45 | - [ ] Setup uptime monitoring early with appropriate notification processes 46 | - [ ] Never restore/run production data to non-production envs 47 | 48 | - [ ] Code 49 | - [ ] README should describe steps to setup dev environment from scratch, always up-to-date 50 | - [ ] Adapt a style guide from day 1 51 | - [ ] Start adding spec tests from day 1 52 | - [ ] Decide on comments or no comments in code 53 | - [ ] Use linters to help standardize code as well as make code reviews better for everyone 54 | - [ ] Set and document guidelines and best practices for logging 55 | - [ ] Set and document guidelines and best practices for exception handling 56 | - [ ] Set up runtime errors and exception reporting 57 | - [ ] Set up realtime analytics for performance reporting 58 | - [ ] Set up ability to track changes to your records at database level for auditing or versioning 59 | - [ ] Define and document process and expectations for code reviews 60 | - https://mtlynch.io/human-code-reviews-1/ 61 | - https://mtlynch.io/human-code-reviews-2/ 62 | - [ ] Early code will likely hit product limitations before performance/scalability becomes an issue; focus accordingly 63 | - [ ] Seed development env databases with code 64 | 65 | - [ ] Engineering Team 66 | - [ ] Hanlon's razor: Never attribute to malice that which is adequately explained by ignorance/stupidity/lack of knowledge. 67 | - [ ] Always be looking forward and "recruiting" 68 | - [ ] Once you have at least one more engineer, define engineering levels 69 | - [ ] Set up a structure to allow for experimentation 70 | - [ ] QA: You will need QA earlier than you think you do 71 | - [ ] When you are no longer effective managing the team, look for a Manager/Director/VP of Engineering who is 10x better than you 72 | - Choose to manage or write code. Doing both will result in poor performance of both. 73 | - [ ] Decide whether you will be a setup for remote or not, and if remote, what "type" of remote team you will be 74 | - Remote teams give you a large talent pool, but have unique management challenges. Hire for skill and autonomy if hiring remotely. 75 | - http://klinger.io/post/180989912140/managing-remote-teams-a-crash-course 76 | 77 | - [ ] Day-to-day execution 78 | - [ ] stand-ups, sprints, retros, milestones 79 | - [ ] Use simple "project management" to keep a healthy product development rhythm, no matter how small your "team" 80 | - [ ] A team member's failure likely stems from a decision you made (or didn't make) 81 | 82 | - [ ] Product 83 | - [ ] Use "feature flags" to release new features and selectively enable them for existing customers. 84 | - [ ] Don't make the thing more awesome, always look for how to make your users more awesome 85 | - [ ] To make a decision, look for answers in analytics and metrics 86 | - [ ] Reporting: Sooner or later, the data you can query from the database will need to be turned into reporting features for your customers 87 | - [ ] Customer suggested solutions are usually wrong. Dig into the "why" before weighing the "how"; the need is usually legitimate 88 | - [ ] Never implement a feature just for one customer; it will hurt you more in the future than help you in the short term 89 | - Exception of paid/sponsored features, which should take maintenance and support into consideration 90 | - [ ] Ensure existing customers want a feature before you start building it 91 | - Potential customers always want the moon; rarely will just-one-more-feature! start landing customers. Choose features many leads want, not just a few 92 | - [ ] Have a vision for your product and work towards it. Passing on customers because of features that don't fit your vision will be painful, but will pay off in the long run. 93 | - [ ] Aim for a "simple" product. Simple is not easy, but it's what your customers and users need. The craft of product is doing the hard work of figuring out the complexity to make using it simple for your customers. 94 | - [ ] Support deep links; your users and your support staff will thank you 95 | 96 | - [ ] Support 97 | - [ ] Have an Admin interface from day-1 98 | - [ ] To ensure the "health" of your application, set up a status page 99 | - [ ] Provide an "impersonate" feature to Admins to help experience what the customers are experiencing 100 | - [ ] Engineers on rotating support schedule builds empathy, this means you and other co-founders too 101 | - [ ] Have a support ticketing system in place from day 1 102 | - [ ] Define support schedules and communicate them to your customers; enforce them with your support staff 103 | - Customers who "need" 24x7 support will be willing to pay a premium for it 104 | - [ ] Define and document supported Browsers from day-1 105 | - https://beta.caniuse.com/ is your friend 106 | - If you plan to support IE, ensure that you and the team is setup to test and debug bugs in IE 107 | - [ ] Setup a read-only SQL-query interface within the app for Admins (authorized users) and block use of external clients 108 | 109 | - [ ] Security 110 | - [ ] Go through the SaaS CTO Security Checklist 111 | - https://www.sqreen.com/checklists/saas-cto-security-checklist 112 | - [ ] Prepare a set of assets to share with Enterprise customers 113 | - [ ] Run static code analysis security tool for your frameworks 114 | - [ ] Look into a third-party pen testing and code audit service/tool sooner than you think you will need to 115 | - [ ] Implement a bug-bounty program 116 | - https://www.hackerone.com/ or similar 117 | 118 | - [ ] Compliance 119 | - [ ] Get familiar with the top 3 compliance standards in your industry 120 | - [ ] Create a skeleton of what it would take your company to get the top 3 compliance certificates in your industry 121 | 122 | - [ ] Misc 123 | - [ ] Find a way to mentor someone (within or outside your company) 124 | - [ ] Join a community of CTOs, engineers, technical leaders who you can knowledge share with 125 | - [ ] In your day-to-day, balance big projects and small enhancements/bug fixes 126 | - [ ] Group email address for ownership of all external services 127 | - Use your password manager's sharing feature to ensure access doesn't rely on you personally 128 | - [ ] All dependent service's payments on a company Credit Card 129 | - Role changes, aquisitions, canceled card, etc could make this painful 130 | --------------------------------------------------------------------------------