8 Lessons Learned as a Programmer in a Start-Up

Lessons Learned as a Programmer Launching a SaaS Start-up

It has been a bit quiet around this blog lately but for good reason. My free time outside of my full time job for the last 11+ months has been dedicated to being the sole developer (and founding member) of a small SaaS start-up. We launched back in the May / June 2015 time frame and there have been many ups and downs both leading up to the launch and since. I have owned a handful of businesses in my life but some of the scenarios around how this one unfolded taught me some things that I have never ran into before. Below are 8 key things that I have learned along the way being the developer / IT person in this small SaaS start-up. I wanted to share these 8 lessons with you so that hopefully you don’t make the same mistakes launching your business.

#1 – Create a Requirements / Spec Document

Creating a requirements / spec document didn’t seem all that important in the beginning. I mean it was just me and my business partner who were working on the business and creating the product. We met bi-weekly for months and I would jot down notes on what was talked about and decided upon in a notebook. I would bring in the pieces of paper where I had sketched out my thoughts on how the flow of the web site should be from page to page and we would discuss that as well. I would then use those notes, the flow sketches and things I had just filed away in my head as my design spec as I was developing the site. I thought this method was working great until my partner started running through the site and had quite a few misconceptions about what we had decided on and how things would work. Even with just the 2 of us, it became clear after a while that we should have taken the time to create an official document of how the web site would work and all the business rules around it. I think the process of writing the document would have forced us to think things through a little more precisely as well. Creating this would have given us that official document to go back to if either of us at any point questioned how we had decided something was supposed to be implemented.

#2 – Don’t Be the Lone Developer in your SaaS Start-Up

There are several reasons why you may want to be the lone developer within your start-up. Maybe you just want to be THE man (or woman) and build the whole thing yourself and be responsible for all the decisions regarding how your software is constructed. Or maybe you don’t want to take on any additional developers as co-founders because you don’t want to reduce your ownership stake in the company. Regardless of the reasons, I would suggest that you resist the urge to be the only developer (except for maybe the smallest of projects). For me it was the combination of wanting to code the whole thing myself for the learning experience and not wanting to give up any ownership percentage in the company. Again, me working as the only developer was going great for quite some time. I was learning a ton and making pretty good progress developing a complex web application on my own. Granted I was working anywhere from 4 – 7 hours a night after putting in a full day at my regular job. When being the only developer started to become an issue was when deadlines started to tighten around the launch. Then, unexpectedly, we needed to swap out our payment processor ASAP. Then there were major and minor changes that needed made to the site based on user feedback. New features and enhancements were coming in rapidly as well. Now the somewhat loose deadlines I had grown accustomed to pre-launch were no longer good enough. There were users on the system and they want the changes made yesterday. This is where burnout and frustration started to set in as I was finding it harder and harder to keep up. I had to start cutting some corners here and there to get things done faster. Maybe it would have been different if developing for this start-up would have been my full time job. Regardless, my advice is to have multiple developers on board from the beginning. You can still run the project and make all the decisions but you’ll have help there when it is needed most to keep your customers happy. Not only will it help you keep your sanity but you will probably end up with a more solid product as well.

#3 – Have a UI / UX Designer on the Team

I believe I am like most developers. I can put together a user interface that is functional, and if given enough time, I can usually even make it look pretty good too (after several iterations). The thing is, design is not what I know and it is definitely not what I am best at. I found myself getting increasingly frustrated as we worked through building out our application because I was spending a large amount of time on trial and error with the UI/UX design instead of focusing on the code and architecture of the system. Even worse is that in the end our user interface still wasn’t as good as what a UI/UX designer would have come up with AND our code quality suffered as well. The design and flow of your application is what your customers see and interact with. If the design is clunky or the flow doesn’t seem natural or make sense then your user will quickly become frustrated and stop using the application. Quite a few of the common complaints that we have heard from our application have been user interface and user experience related. Users have high expectations of the software that they use these days. Just having a working piece of software that solves the problem is no longer good enough. Go the extra mile and make sure to have a UI/UX designer on your team. Had we done the same, I think we would have saved ourselves and our users a lot of time and frustration.

#4 – Don’t Wait Until the Last Minute to…

When you are starting a business there are always 101 things that need to get done on any single day. With all there is to do, it’s easy to get into the mindset of just working on what NEEDS to be completed for tomorrow and put off things that aren’t necessary at the moment. This mindset is fine for smaller tasks that can be completed quickly but can become an issue for larger tasks that require more time or outside resources to complete. For months we had been working on things related to getting our SaaS app completed. We had bi-weekly progress meetings, talked through new features, the flow of the web site, colors, branding, pricing, etc. We were working on tasks related to completing the web site and ignoring things like legally registering our business, signing up for our production merchant account and contacting our lawyer about the terms of service agreement. We were ignoring these tasks because they weren’t necessary at the moment. One day my business partner threw out the seemingly crazy idea of trying to launch our SaaS product at a large industry conference that was being held in a few weeks. We decided to give it a shot and focused on getting everything done to make the launch happen. The problem we ran into was that our short timeline didn’t always mesh with the timeline of the government, our lawyer, or the payment processing company approving our production merchant account. Moral of the story here? Don’t wait until time is running out on your launch date to tackle the tasks that are critical to your business. As a developer, building the app is the fun part but you have to remember that you are also building a business and there are critical tasks that need completed there too.

#5 – Get Customer Feedback Early and Often

Not getting customer feedback early enough may be one of the biggest mistakes that we made. The whole time we were building out our web app, we weren’t putting it in front of end users to get their feedback and ideas. My partner had a bunch of connections to potential end users in the niche our app was for and would run ideas past them, but we never put the actual web app in front of potential customers until it was close to “done”. This was a huge mistake on our part. We have found that the end users didn’t like numerous decisions that were made on how features work and how some of the data was defaulted. Now we are spending a ton of time going back and making changes to accommodate their wishes with the site already in production. It would have been much easier to make these changes pre-launch. If I had it to do over again, I would enlist the help of 10 – 20 pilot users to work very closely with from the start. I would get them using and critiquing the app all throughout the development process. This would have put us in a much better place when we launched in terms of the design and feature set meeting the end users expectations. Plus, we would have had a group of 10 – 20 highly invested users to champion our product to their friends and acquaintances within the industry. No matter how much you think you understand your potential customers and what they want, don’t skip this step!

#6 – Have a Closed Beta Tester Portion of Your Launch

Having a closed beta tester portion of the launch is something else that I wish we wouldn’t have skipped since we decided to quickly launch at an industry conference. In hindsight, we should have had a beta tester sign-up landing page on our site while we were developing the app and working with our “pilot” users from lesson #5 above. Doing this would have allowed us to collect email addresses from interested people to build a list to notify when we had launched. We could have then used that list to pick 50 or so additional users to include in a closed beta. Having the closed beta would have allowed us to scale up our user base to get additional feedback and insight into our product without freely opening registration to anyone. This closed beta would have confirmed for us that the product we developed with the help of the pilot users was something that they wanted and met their expectations.

#7 – Don’t be Afraid to Take Chances

When my business partner first approached me about joining him to launch a SaaS start-up and build his idea, I was excited and nervous all at the same time. Excited because I really liked his idea and I had been looking for a start-up to get involved with. Nervous because I had never built a web app even close to the size and complexity of what his idea would require. Most of my software development career has revolved around building large, corporate, desktop applications. I did go back and forth a few times on whether it was a good idea to accept his offer knowing that this would be taking on a project that was far outside my software development comfort zone at the time. I am glad that I didn’t give into those doubts and decided to go ahead and join him in his SaaS start-up. I spent the first month or so just reading, learning and studying all the different technologies that would be used to develop the site. After that first month I started laying out the architecture for the site and then started to code. Sure I’ve had to research things along the way but all in all the development has gone much smoother than I could have anticipated. Plus, I’ve added some very valuable skills to my toolbox for any projects or jobs that may come my way. If you find yourself in a similar situation that would require you to step outside of your “development comfort zone” for a job or joining a start-up like me, don’t be afraid to take that chance! Trust in your abilities and push yourself!

#8 – The Body is not Meant to Sit 24/7

For several months leading up to the launch of our SaaS start-up, my daily routine would be something like this. Wake up and head to my day job to sit and code for about 8 hours. Come home and have dinner with my wife. Head to my office in the basement to sit and work on the web site for roughly another 7 hours. Crawl into bed for the night around 3:00 AM. This was more or less my schedule day in and day out for several months. Sure I noticed that I was gaining weight and was overly tired from not sleeping much. It took me getting to the heaviest I’ve been in my life along with developing persistent side and stomach pains for me to realize that something needed to change. I changed my diet to be more healthy, I started exercising daily and I did my best to quit sitting as much as I had been. It has been 5+ months and I still don’t feel like my health has completely returned to where it was although I do feel much better than I did. Sitting a lot is not healthy and as programmers we generally sit all day for work. Do yourself a favor and make sure you are getting up regularly and moving around. If you work from home, you can take it one step further and look into getting a standing or a walking desk. Don’t ignore your health!