The One Man Show: Bootstrap your Business, by Yourself!
The opportunity to solve a challenging problem from scratch drives many developers to build great things. The attributes of a full-stack developer are much debated, and I’ve written extensively about what, in my opinion, makes a good full-stack developer. The true test of ability, the measure of one’s mettle and dexterity as a full-stack developer, is in the application of a great diversity of skills to produce sustainable, maintainable, safe, scalable software. This diversity of skills includes infrastructure, systems administration, database administration, API-driven software development, and front-end design and development. In developing my latest web application, trakr.link, I had the opportunity to do this all again, but this time, I have done it alone and without external funding. Here’s how I did it.
“Software is a great combination between artistry and engineering.” — Bill Gates
As with any software project, I start with a vision of a completed product and work my way backward into a set of requirements. I draw them out, I envision their connections, and begin to put them on a timeline for development, developing the most critical features first and skinning them along the way. You must strip away everything that isn’t immediate and separate very early on — the must-haves of your software from the future requirements and nice-to-haves. Sometimes that involves pulling the trigger and putting your practice into motion without knowing for certain if you’re walking down the right path.
“If you are not embarrassed by the first version of your product, you’ve launched too late.” — Reid Hoffman
The product as it stands today will lack for niceties. I’m not a designer, and the front-end of applications is something I am particularly weak at producing, but to wait for perfection is Xeno’s paradox: you will only ever be halfway there. It is more important at this stage to understand the deficits in your application and document them appropriately. You probably already have milestones laid out that cover your features and have ordered them by priority, but there will be a million little things that need fixing as well. Whether you do this in code, formalized on a wiki, or scattered in notebooks across your desk (I have to-dos throughout my JavaScript and back-end code, personally), keeping track of this will enable you to make incremental progress going forward without losing site of both your big goals and small wins.
“Documentation is like sex; when it’s good, it’s very, very good, and when it’s bad, it’s better than nothing.” — Dick Brandon
My first big goal when developing an application is building out infrastructure that doesn’t force me to sacrifice either maintainability or scalability. In this particular instance, even in doing this on a small budget, I was determined to have a high-availability application. This includes at least two web instances running at any given time behind a load balancer and a database with automatic backups and rollover across multiple availability zones within AWS. Driving my need for this is a desire to not worry. What we often overlook is the mental aspect of maintaining services. In this setup, I don’t worry about server uptime, outages, or availability, AWS will alert me if need be, in particular for database limitations, and more to the point I can set automated scaling based on my comfort level (i.e., my available budget). Make things as easy as possible in as many places as possible, because running the business yourself will be difficult regardless.
“A complex system that works is invariably found to have evolved from a simple system that works.” — John Gall
When I say “make it easy,” I mean not only to remove mental stresses, but also to reduce complexity. When discussing a minimum viable product it is more than producing a minimal set of features, it is also laying the groundwork that will remove impediments for the remainder of the project. I approach this through automation. Instead of worrying about product license expiration in a year, when my first customers will need to renew, I began by setting up my email service, my email worker, and my consumer messaging. To avoid hitting the boundaries of the capabilities of my relational database, in space or memory in particular, I use monitoring to identify trends that indicate a need for additional scale ahead of catastrophe. As a single person, I cannot watch for changes in traffic 24 hours per day (or in fact even four hours per day), and using AWS auto-scaling policies allows me to automatically react to traffic spikes and changes even as I sleep.
“Make everything as simple as possible, but not simpler.” — Albert Einstein
But what if you can’t do something, like systems administration or design? If time does not permit, there are always alternatives. Hosting providers that allow you to deploy applications (like Elastic Beanstalk in AWS, or Heroku, or any other PaaS), contractors that you can hire for reasonable prices (like Fiverr, or Upwork), are just some of the examples of outsourcing and offloading work that you can’t do. I recommend trying to do this work anyway, even if outside of your wheelhouse (especially if outside of your wheelhouse). Consider it a growth and learning opportunity to push outside of your comfort zone, even if it takes you longer than you’d like. This requires a balance, but learning something new is rarely a detriment to your life or livelihood.
“Just because you don’t know a technology, doesn’t mean you won’t be called upon to work with it.” — Mike Bongiovanni
You’ve only just begun once you’ve released. Software evolves, hopefully for the better. Incremental progress, no matter how small, drives me forward and creates the mentality of success. In this process, I try to do future planning from a technology and cost perspective that maps out various scenarios of user acquisition and DAUs (daily active users). Breaking this out allowed me to mark business milestones (and KPIs) that better enable me to manage costs and understand the growth trend of my budding enterprise, currently in its earliest stages.
“If you cling to a Waterfall view of the world while your technical staff adopts an iterative, incremental method, you won’t understand the status of your project or…predict where it’s going.” — John D. Williams
