The world of SaaS is very alluring for entrepreneurs not only due to the huge profit margins but also the fact there is no inventory or shipping of physical products to worry about. It’s simply buy and start using immediately for the consumer.
On the surface, the business model looks very attractive… but there are many drawbacks. I recently dove headfirst into the world of outsourcing a developer, bug fixes, creating templates, and mapping out so many possible scenarios my head is about to explode.
In this article I’m just going to talk a bit about my experience thus far in the development process as a non-technical SaaS founder.
What is a non-technical founder?
I think that the term “non-technical founder” is a spectrum. There are some people who have trouble checking their emails who would fall into this category. Then there’s people like me. I was actually a web designer WordPress developer for over 10 years, so I feel like I have a leg up on some other non-technical founders.
I can’t code, but if needed I can read through some code and get the gist of what is happening. I can find specific files in an app and figure what function is being called and why… stuff like that. I can write some very basic Python code and I can speak to my developer in a way that doesn’t make him explain everything to me like a 5 year old. I’m sure that helps him.
Even with all of that said, I am still 100% a non-technical founder because I can’t contribute to the coding. AWS is a mystery to me and code too complex is lost to me. So in short, a non-technical founder is someone that can’t code and doesn’t understand the code or the inner workings of a software.
Tips for non-technical SaaS founders
All of these tips are assuming you already have your idea and are no trying to figure out how to make it a reality. It also assumes that you are taking the same path I did which is outsourcing the parts you can’t do yourself. Some people find “technical co-founders” and split the business 50/50 but I honestly didn’t like the sounds of that for a variety of reasons.
1. Interview many developers
As a business owner I’m used to interviewing, hiring, and firing. The whole process is not new to me so I treated this hiring like any other. The big difference here is that I couldn’t do what I was hiring for, whereas with any of the other jobs I hire for I can do myself.
I created a detailed job post with all the requirements and expectations of the job. I then posted it to Upwork and got a ton of replies. I used my own methods to filter through the applicants and decide which ones I didn’t like. Out of the ones that were left I started messaging all of them.
Almost all of them replied and we chatted back and forth a little, this was me deciding if I should schedule a call with them. Out of these developers, I chose 7 to do interviews with and it was out of those 7 that I found the developer I am now with.
2. Choose a common programming language/framework
This is where me being a quasi-technical founder came in handy. No, I can’t code… but I am up-to-date on all of the most common programming languages, frameworks, and libraries. Before I even got started I had probably 3-5 combos in my mind.
With that said, I discussed this with the applicants and all agreed that these were solid options. Each could achieve my goals in different ways. We ended up going with Python/Django/React because it has such a strong community and documentation behind all of them.
These technologies aren’t going anywhere and if any problems arise, someone else has already had the same problem and posted the solution online.
3. Set a budget, but have some padding
Doing this isn’t going to be cheap. Sure you can try something like no-code and do it yourself. I knew this was an option and I researched it. Ultimately I decided not to go the no-code route for my own reasons.
With that in mind, I had a general budget I was hoping could get this done. After narrowing it down to the 4 final candidates for my job, the quotes from 3 of them were within this range and one was way below it. I dropped the low quote because I felt like he didn’t understand the scope for quoting so low.
Out of the other 3, I obviously chose just one of them. I ran with the quote he gave me and added about 50% padding to the cost of version 1. Essentially, the goal was to get to a helpful software for this amount.
I know how it goes, nothing is ever as cheap as you initially hoped…. I’ve done freelance. My rule for client quotes was to come up with the amount I thought would cover my hours based on my research, then double it.
4. Don’t go for the cheapest developer
It may be tempting to go with that guy offering to do all of the work for $20 – $30 per hour, but they’re probably that cheap for a reason. Conversely, the guy charging $150/hour is that expensive for a reason.
I found someone that fell somewhere in the middle. It ended up being a very experienced developer who was new to Upwork and his rates were low for this reason, he’s already increased them significantly but I’m locked in for now.
5. One person can’t do everything
Finding a full-stack developer that is a one man show is rare. Yes, a full-stack dev can do your front-end and back-end work but who is going to do your design? Who is going to make all of the decisions about the logic in your app?
A full-stack developer can do a lot, but in the end it’s your app and you have to make the decisions about how it will work. A full-stack dev may not be able to create buttons for you or banner designs etc.
Just keep in mind that if you are trying to do this with a sole developer, it can be done, but you are going to have to pitch in and do some of the work. In my case I created a bunch of HTML pages for most of the pages and view states that my dev could easily convert to React templates.
Because I’m well versed in HTML and CSS I was able to create pages that looked identical to how I want them to appear. It’s all fairly basic looking for now, but we’re focusing on functionality.
6. Have regular check-ins
Check in regularly with your developer. It’s likely that your developer is freelancing for other clients and you could fall between the cracks if you don’t ping them every so often and make sure they know you’re still there.
Me and my dev check in usually once a week and discuss bug fixes, future updates, different user scenarios, and timelines. Usually a 20-30 min Google Meet call is all that’s required.
7. Make sure you own the code
This probably should have been higher on the list, but this list is in no particular order… it’s just a brain dump of tips.
Sign up for Github immediately if you haven’t already and create your organization there. Once you’ve done this, it’s where your code will live. You will invite your developer to this account and he/she will create all code for your app here.
Changes that are made to your actual website will go through here. It’s called a development pipeline and is something that will be set up from the beginning, Github plays a huge part in this. Refuse to work with a developer that won’t allow you access to the code you’re paying for.
Additionally, if you are using AWS make sure that the account where the code is being pushed to is one that you own. A good developer will help you set up both your hosting and your Github accounts so that you have access to everything and they are simply working on a project owned by your organization.
8. Get suggestions from your developer
There are going to be more times than you can count where your developer will ask you a question that you don’t know the answer to. You will also have your own questions that you don’t know the answer to. These questions should be brought up in your meetings.
Always ask your dev what they think is the best solution. Don’t just default to going along with anything they say, because it’s your business and your dollar. You should listen carefully to what they say though, ask them if certain things are possible and if so are they feasible or will it be expensive to do so? Is there a better solution to achieve xyz without having to worry about abc?
Really pick their brains, software developers are masters of problem-solving and and you are going to have more problems than you know what to do with. As much as you thought you had this all planned out, you’re going to learn you barely thought of anything. A lot goes into building a SaaS app from scratch.
9. Don’t spend money you can’t afford to lose
This should really go without saying, but don’t do this on a credit card or with money you can’t afford to lose. Set a budget for a chunk of capitol you can afford to lose. If the whole SaaS amounted to nothing and was a waste of time, it doesn’t hurt you. Sure, no one wants to lose $10k – $20k on a failed startup idea, but if you do you’re ok.
Another option is to build very slowly. Maybe you don’t have $20k sitting around but you can afford to fold $500/mo into your budget. In this case you can simply hire a developer for a few hours per month and try to do a lot of the easier stuff yourself. There are ways to cut costs and stretch the whole thing out.
10. Know when your developer is developing
By this I simply mean have something set up so that you are alerted when actually changes are made to your site. Don’t just wait for Upwork to bill your card and then ask “what did you do this week?”
I have notifications set up in Github so that any new code added to my project triggers an email sent to me. I also have email notifications set up in a shared Slack channel that gets AWS front-end deployment notifications.
Between these two channels of notifications, I have a pretty good idea of when work is being done and how much is done on my project. By this point I believe my guy to be trustworthy, but it’s still very nice to get that notification that has notes of exactly what changes were pushed to production.
Final notes
In summary, hiring a developer to build software as a non-technical person is not impossible. It can be quite risky though. Getting an untrustworthy or unskilled developer is the worst-case scenario, either can result in a huge waste of time and money.
If you are considering doing something similar, just think it through carefully and resist the urge to hire some cheap yes-man developer. Also, as a bonus tip I strongly suggest you hire a developer from your country and in your timezone. Yes, a foreign dev can be just as talented and smart as a local developer… but that’s not the problem.
If there’s a language-barrier problem you are screwed. A communication issue is a terrible problem to have and could be the difference between a successful hire and a bad one. Additionally, if your timezones are too far apart then communication is going to be a pain anyway.