As a non-technical founder of a startup, especially a tech one, at some point you will have to build some custom software. How do you do that? Who do you hire? Software is complicated and expensive, the wrong decisions early on can be very costly. In this article I’m going to go over some of the higher level concepts and point you in the right direction to get started.
MVP
An MVP (Minimum Viable Product) is essentially the least amount of effort software you can build that lets you start engaging your users and learning something valuable. It’s a way of testing assumptions and getting some validated learning without spending a ton of effort doing the wrong things.
Originally, Eric Ries came up with that term in his Lean Startup methodology. While building products at his startups, Eric noticed that he was spending a massive amount of time building the wrong thing, only to then go back to the drawing board and throw out most of it. My experience has been very similar, both in the products that I’ve built and at the startups that I worked at. In fact, I would say that overbuilding in a vacuum is the most common mistake that I have witnessed at startups. Research seems to agree, CB Insights did a postmortem on 100 startups, and the number one reason that startups fail is that they fail to fill a market need. These startups spent months or years building products that no one actually needed.
To understand why that problem exists we have to fundamentally understand what a startup is and why it exists. The entire point of a startup is to discover a sustainable and scalable business model. It’s mainly a learning experience. That’s different to say a small business that sells burgers, where the business model has already been discovered. And so what happens is that the founders have some kind of an idea and a vision for their product. They go off and build it for many months without any input from users (or incorrect input from users). They get the software just perfect: fully featured, polished, maintainable, and scalable. Then they take it to market and find out that users don’t really want it, they either don’t adopt it or don’t want to pay for it. The disconnect is that the product is based on what the founders think the market needs instead of what the market actually says it needs, and those are two very different things. It’s very rare for founders to guess what the market needs right like that out of the gate. In fact, most companies go through multiple pivots. Uber originally was a limo sharing service, Twitter was a podcast subscription platform, Paypal was a PDA “beam” payment platform, etc.
Ultimately, what you have to remember is that the most beautiful, polished, full featured app that doesn’t solve a market need, still ends up in the trash can. So with an MVP, you figure out what is the minimum product that you can build to start testing and validating your assumptions with actual market feedback.
Development Models
Now that you know what you need to build to get some learned feedback, let’s discuss the two main models for getting software developed: Fixed-bid vs Iterative, or Waterfall vs Agile.
Fixed-bid
With this model you know exactly what you want, you go to an agency, describe in detail what you are looking for, and they then build it for X number of months. It’s the same as Watefall if you had an in house team, you would describe what you want for version 1.0, and they would go off and build it. The main thing to understand is that with this model you are pre-planning your product a few months in advance.
Iterative
With iterative or Agile development, you frequently change what you want your developers working on based on changing priorities. In it’s most basic form, you are working closely with a developer and just meet/email them with changes that you want. In a more formal setting with a larger team it’s Agile with 2 weeks sprints or Kanban type of workflow.
What to Choose?
Just like we discussed above, this all comes down to the type of business that you are running. If you know exactly what you want to end up with, you can go with a fixed-bid project, where all the costs and times are mostly knowable upfront. If you are selling burgers and need a McDonalds type of restaurant, you get quotes and have builders build it for you.
But in my experience, fixed-bid is the wrong way to go for most early stage startups. As we discussed above, there is just too much shifting that goes on too frequently. You could potentially fixed-bid outsource your MVP, but since you are thinking up of all the possible features you will need up front, those MVPs end up being too bloated. And once the MVP is done, you will then need to switch to iterative mode anyway. An MVP doesn’t mean that your product is done any more than a child that enters first grade is done with school. An MVP is just a first step to get some validated learning, then it’s a continuous process to learn more until you finally get to a business model, and that can take years.
At one of my startups, initially the founder came to me to help review a proposal. It was a fixed bid proposal with an agency, 7-8 months of development at $400k. We ended up turning down the proposal, and it’s a good thing that we did. What we had at 7 months was nothing like what the founder wanted in the proposal. If he would have gone with the agency, he would been on the phone with them in one month asking to change half of the proposal.
This isn’t an absolute truth. I had someone come to me with a desktop application that they wanted to convert to a web based app. They still had documentation from the original project describing all the business logic and you could reference their existing software. If you can plan out your entire business in great detail and know for sure that it will not change during those months, fixed bid is the right option. But most startups are very dynamic and chaotic, and they need a dynamic development model to complement the business side.
The Developers
So now that you know what to build and how to build it, the next step is to figure who should build it.
Agency
There are many software development companies to choose from. You can google for the specific type of a agency you are looking for, and use sites like https://clutch.co/ to read some reviews about them. Agencies typically like to do fixed bid projects, but they will generally go along with whatever you want – team building, outstaffing, etc. Agencies are typically more expensive and rigid than individual developers. For example, with a freelancer you can arrange 30 hour weeks, temporarily pause a project, or have them work extra hours when needed. With an agency the developers are just full time employees of the agency, they are interested in having them work a steady 40 hours a week, with a normal schedule and a familiar workflow process.
Freelancers
They are lower cost, more flexible, and deliver quicker overall. But you are also getting fewer guarantees. A freelancer might be great or might just waste a ton of your time and money. They are also less reliable, a freelancer might find a full time job or juggle too many projects and end up disappearing on you at any time.
You can find freelancers on https://www.upwork.com/ or sites like https://www.toptal.com/. Toptal is more expensive, but vets their freelancers for you.
In House Employees
They are reliable and have an interest in delivering high quality products, since they will be on the project long term. Costs overall will be similar to freelancers, it’s less per hour, but you have to pay benefits. You can also try to reduce the cost by giving away equity. The major downside with employees is lack of flexibility. You can ask a freelancer to reduce hours and wait, you can’t do that with an employee. It’s also much easier to let go of freelancers. An employee is a long term commitment.
Technical Co-Founder
If you are just starting you might consider bringing on a technical co-founder. It’s a really great choice for non-tech people and can really simplify software development for your startup. If the technical co-founder is good, they will be able to recruit other developers later on as well. You have to make sure to really vet them, a bad partnership is going to be bad with a technical co-founder, just like with anyone else. And of course, you will have to give up some of your company.
Who to Choose?
That again depends on your situation. Bringing on a great tech co-founder for a tech company is extremely valuable and will save you a lot of headache in the long term. But it’s risky, a bad co-founder can jeopardize your entire company, the 3rd reason on the list for startup failures is the wrong team. If your tech co-founder can’t deliver on the MVP, ends up being a bad team player, or (in one case I witnessed) is more committed to the code than the product, it’s going to end poorly. And again, it really depends on your situation, if you just have an idea and no funding, a tech co-founder might be a must, but if you are well capitalized you might not want to go that route.
In general, if I was in the shoes of a founder with an early stage startup, I would go with freelancers. It goes along with the rest of the article, there’s too much uncertainty and you need the flexibility early on. Agencies are rigid and more expensive, they are generally better for the fixed-bid model. In house employees are more stable and long term, but they require a commitment, which you can make when you have a much better understanding of how your business functions.
For example, eventually you will make connections with developers, have a company culture, and be able to hire the right in house developers for your business. But early on, you probably will not know how to vet developers correctly. With a freelancer, you can give them some milestones, some test assignments, watch how you work together and switch them out very quickly, if necessary. With in house developers you don’t have that flexibility, hiring full time is a serious, lengthy process.
Getting Started
Hopefully, I explained some of the basics enough for you to get started with software development for your startup. The next step is for you to define what you want to build. Figure out what assumptions you are making about your business and customers. Figure out what’s the quickest way for you to test those assumptions and start engaging your customers. If it’s custom software (it’s not always custom software), spec out exactly what you want built for your MVP. Then figure out who you want to hire and go from there….