What Non-IT Startup Founders Need to Know
If you’re going to try to launch a startup that has a website or app as its main product, and you don’t have a technical co-founder, you should read this blog entry. It’ll save you a lot of time, headaches, and a ton of money.
What am I going to learn?
I’m going to discuss the challenges you’ll face without a technical co-founder, and how to overcome them. I’ll also point out risks you might face regardless and how to help mitigate them.
I’ve worked with many startups: some as a technical co-founder or consultant, and others I came in much later to help rescue and do clean up. Although each idea is unique and the founders are all different, there are many patterns that I’ve seen. My goal is to give you a heads up and maybe some advice to make sure you don’t make these fully predictable and avoidable mistakes.
Spoiler alert: I’m going to advise that you get yourself a technical cofounder so you don’t have to read long articles like this as much.
Some terms / things to know to make this easier
I’m going to refer to the technical cofounder throughout the duration of this article. I’ve named them this for ease of writing and communication. In some rare cases, a contractor with a very long contract (2+ years) could also step in, but that’s not ideal.
The product we’re going to refer to is a website or webapp that is the main business of the company. So I may refer to programmer, or product, and that is the startup’s website and the website’s creator.
Why do I need a technical cofounder?
If you’re not a programmer or very experienced in IT management, you’re going to be at a loss. It’s not impossible that you can succeed, but much, much harder. You need a technical cofounder. Let’s talk about why.
Someone who knows how to do it
If your main product is software-based, not having a technical cofounder will introduce many more challenges into an already tough idea: launching a successful startup. If you look at the history of most successful businesses, it was a person who did the thing, then learned to manage, then expanded. A new auto mechanic shop started with a mechanic who wasn’t content with just spinning wrenches, they wanted to own something and grow something. A grocery store was launched by someone who built their career as a produce buyer. There are many examples of this - and the majority of successful companies are being launched by people who can do the thing during the first few years.
Just because you have technology in your life, doesn’t mean that you can manage and create a technology company. You have electricity throughout your whole house - that doesn’t necessarily mean you can wire your next house from the ground up. It’s easy to develop an ego, arrogance, or have basic ignorance about the complexity of IT projects because you’ve been using software products for your entire life. It can’t be that hard, right?
But they are. They’re very difficult. The reason that your experiences have seemed so easy is because many people who know what they’re doing designed, built, tested and iterated on something to make it seem easy for you. The easier some piece of tech is to use, the more work went into it to make it so. Easy to use tech doesn’t mean tech is easy - it means someone really invested in that tech.
You also need someone who is either a current programmer or who was recently one. Depending on your budget and your company size, you may create a programming team, or you may hire contractors under your cofounder. But, because startups move fast, you need someone who can jump in during an emergency. And there will be many. They need to be able to fix a last-minute customer issue when you’re first starting. They need to be the guiding force behind and beside contractors or other team members who are in the weeds trying to solve something for a deadline.
It’s about buy in, about saving time
Having this technical cofounder on your side is going to save you a lot of time. They understand the company’s goals, what you want, and have bought into the vision. This helps release you from the minutia and details that comes with building a technical product.
Even the best planned out products, with the most wireframes and customer stories, are missing something. Each time there’s an unknown, three things can happen: 1) the programmer can make up the answer (happens sometimes, most of the time the solution is wrong). 2) the programmer can ask you, the CEO, and then work pauses (ouch!) or 3) they can ask the technical co-founder, who will know 95% of the answers and can keep work going. They keep the little details off of your plate.
With a cofounder, you’ve done the work to bring them up to speed on your vision. You’ve worked through challenges with them - and they know what needs to happen. They have the added bonus of being able to understand the common programmer question which is usually some mix of business and technical stuff. You don’t have to unwind the tech stuff that you don’t understand and no one one has to wait for you to get off your next sales call.
A technical cofounder is worth their weight in gold because they’re able to keep the small stuff off your desk and move a project forward.
It’s about protecting your resources
Contractors are not bad people. I’ve spent many years as a contractor. But I go out of my way to always look out for the benefit of my client. I can tell you that most contractors don’t, however. They do what you ask them to do. They’re afraid to disagree with you or push back, because you can stop paying them. And it doesn’t matter anyway, there’s enough work - so if your business fails because of your mistaken requests, they’ll just move on to the next contract and more money.
A technical cofounder will and must treat the product as their baby. They balance a fine line: they know that business needs are necessary to produce revenue and growth, to get some take-home pay. But they also understand that building a palace on quicksand - while it may look beautiful - will fall apart in the long term. They will protect your investment by watching out for shortcuts that contractors could take and providing you with risk assessment on your decisions.
A good technical cofounder will be annoying - but just enough annoying - to keep the maintenance and the priority of the software product as part of the discussion, but will know enough to equate your choices to risk. They will know and be able to tell you what is acceptable risk, what is bordering on dangerous, and what is over the top. The only way they can do this is because of all the information that they know about the business goals and how they can couple that with their knowledge of the intricacies of the technical product.
Funding without a technical cofounder can be tough
There are many different schools of thought about investing. Some investors may feel that you can hit your first few milestones without having a technical team. Some may think that the lowest amount of money and equity spent on building out the product is best - at least for the short term. It also depends on what level of investor: an angel, a VC, an active vs passive one, etc. Most though, in my experience, have had a different idea.
When an investor is giving you money, they are doing a risk calculation. (I’m going to make up some percentages just for ease of explanation.) Let’s say when an investor invests their money in your company, they expect that they have a 10% chance of getting 200% back from their investment. So, they have a specific risk based on the understanding of your product and how your team will execute.
If you don’t have a technical cofounder to be responsible for how their influx of money is spent, you’re adding additional risk to the deal. When you have to contract the work out as a non-technical person, you’re introducing at least another 50% of risk. Non-technical people don’t know how to evaluate the product once they receive it. They also delay the product development because they’re not versed in speaking technically to a programming contractor. All of this adds up.
So, now, you’re added more risk into the deal with the funding partner. They probably aren’t going to take that risk, now. They’ll say get a cofounder, someone who is bought in, someone who is anchored to the company (likely with some stock vesting), and we’ll talk again.
That’s not to say you won’t find funding without a technical cofounder. But, it will definitely be harder (and it’s hard enough!)
An equal during the lonely nights
If you’ve never launched a startup before, it can be overwhelming and surprising how lonely it can get. All of your friends and family will continually ask you how you’re doing, but you’ll feel pressured to tell them everything’s going great. Even if you tell them it’s not, they can’t help but give you platitudes like “you’ll make it - you’re great!” They don’t know, though. They don’t know how hard it is. They don’t realize that while they’re having a barbecue, you’re sending your 400th email of the day. They haven’t seen the 6 designs you thought were going to finally make it work - just to have them fall apart in a different way.
It may sound like my point is that a technical cofounder can be your best friend during these moments. But that’s not what I’m saying. They may be - or they may not be. But they will be there working as hard as you are. And that’s some comfort and some solace.
When you work with contractors, they may develop a strong affinity for you and the project, but at the end, they’re still one step removed. It’s not theirs no matter how hard they work on it. Sure they can say they built it - but no one really cares. And when that one very tough problem comes up at the end of a Friday, contractors will be figuring out a way to tell you they didn’t get it done for the Monday morning status call.
A technical cofounder will be there with you. That Friday night problem will find a solution by Monday. Hey, they may need to complain to you all weekend while they’re solving it - but that’s the cost of having someone who cares as much as you do! Someone who owns the technical side will be there - because they know that any technical product without you and sales, is worthless. And you know that anything you sell that you can’t back up - is a worthless and damaging interaction.
Why you might not want a technical cofounder.
Maybe you think you still don’t want a technical cofounder. Or maybe you do, but you still feel some resistance internally. Let’s talk about why.
They’re hard to find
The first reason you might not want a technical cofounder isn’t about want at all - it’s a lie you might have convinced yourself of. You don’t want a technical cofounder because you can’t find one.
Finding a good cofounder is hard. But we’ll touch more on this later. But, even if you don’t have a technical cofounder, it doesn’t mean your business is at a standstill. There are still many things you can do successfully before and without one.
First, you can do your own wireframes and create your own logical decision charts. These workflows and these wireframes are important: they will help you get the idea out of your head, they will help you communicate to your cofounder what you want to build, and they will produce something you can use to test your ideas.
Let me expand on that a bit. If you have an idea, you have to record the specifics of it. If you have a problem, describe the problem and list your solution(s). You need to be able to articulate this onto paper so that your problem and solutions are consistent and reproducible. If you’re not willing to do this, it can be hard to find people to join your team. This is the bare minimum. It might seem hard, but it’s worth it. This is how you begin to communicate to your team what you want.
Second, you can test your ideas out with focus groups. (Notice I didn’t say friends: friends are the worst people to ask for advice. And chances are you’d rather have stranger’s money rather than your friends’ - so deal directly with your customer: strangers.) Your idea may be magnificent, but ideas are easy. (I’m sorry to burst your bubble.) It’s implementation that’s hard - and to prove that’s the case, look at the fact that you’re having a hard time even finding a person to be your cofounder. The implementation doesn’t get easier after this - only harder.
So, before you have your technical cofounder, you’re not dead in the water. Get textual or visual representations of your ideas and important decisions. Document what a successful customer interaction looks like. And then test, iterate, test and iterate. It’s cheaper and easier to iterate documentation and wireframes than it is to iterate software.
And speaking of cost, the first three or four times you try to solve the problem your startup is trying to solve, it’s not going to be right. You will invariably build a few versions of your software that you throw away - or that no longer even resemble what they did a year ago. Do that with wireframes, documentation, and focus groups first - you’ll save yourself a lot of money and your technical cofounder a lot of headache!
Why can’t I find one?
Like I said, it’s tough to find a cofounder. Think about it: you have to find someone who is basically willing to take the same risks as you, but who didn’t have the same epiphany or experiences you had. You are asking them to take a chance on an idea, to perhaps leave their own career behind, and to attach their name directly to your success.
Why would someone do this? Well, there are tremendous upsides to being a cofounder at a company - especially if you sell or cash out. But, what about companies that don’t want to sell - or can’t sell? What about companies that only become profitable years and years later? And what about most companies doing this little scary thing called failing?
Why can’t you find a technical cofounder? Well, first ask yourself: are you making it a priority? This relationship, as I’ve tried to demonstrate, is as important and equal priority to the actual software product. So if you’re not spending equal amounts of time networking, recruiting, connecting, interviewing and selling a cofounder, that’s why you’re not finding one.
I think a more scary reason, though, is that you haven’t sold your idea right. A technical cofounder isn’t just joining for the technology challenges. Trust me, there are a lot of challenges at well-established companies that they could solve - and make a high wage, get stock options, time off, etc. They’re going to join because they believe in you and they believe in the idea.
If you can’t find the technical cofounder, it’s time to take stock - to do an audit - of how you’re selling the idea and how you’re presenting yourself.
Let’s talk about you first. Are you on time? Are you accurate? Do you stick with your promises? Do you continue the conversation? You’re basically conducting professional dates. You need to be putting your best side forward. You need to make sure you demonstrate that you’re looking for a partner, an equal. Treat them with respect. Because, even though you came up with the idea, you can’t make it without them.
Second, let’s touch on the idea again. First of all, is it feasible? I can’t tell you how many people have come to me and said “I am building a Facebook killer.” No, you’re not. Your project could take away share, and it could eventually “kill” a competitor, but that’s not how you should pitch your product to start out. Tell what problem it’s solving - not how it’s going to take over the market. Is it feasible to solve this problem?
Then, is it technically possible? Could it be that you can’t find a cofounder (at least easily) because it’s not technically possible? Ask people if they think this can at least be done.
Then, consider the idea itself. Have you put as much work into presenting that idea to a technical cofounder as you do to people who you want funding from? Because they’re both putting in a tremendous amount of value. Or is the idea not baked enough? Did you skip ahead too fast because you’re excited? If you’re asking for a technical cofounder to buy into your idea, it has to be thought out enough that they can at least follow you to the theoretical goal. If they can’t, you’re not going to get someone to go along for a ride that you don’t know where you’re going.
I have to give away equity likely, and I don’t want to.
This is more of a business question that I can’t answer for you. But yes, you likely will have to give away some equity for a cofounder. It’s up to you to negotiate what this looks like, how they’re vested, etc. You may find you end up paying them and giving away equity, or some other combination of things.
But you have to give away an ownership stake, in my opinion, to have a cofounder. That’s why the name really is cofounder. They’re founding the company with you - so therefore they should have some skin in the game as well.
You’re not on the losing side of this negotiation, though, so don’t worry. You’re just an equal. They need you as much as you need them. The reason why you’re doing a startup is because you have the idea and you likely have the sales ability. They need you for that. You need them for their technical expertise and their ability to produce. It’s an equal relationship. If you begin your negotiation from a point of equality, you shouldn’t feel bad about investing some equity in them.
Remember, 50% of something that’s generating tons of revenue is worth much more than 100% of something that’s not generating any revenue.
How can I protect myself if I don’t have a cofounder (yet)?
This section is about things you can do now if you don’t have a technical cofounder to protect yourself. Actually, a lot of this is things that should happen even with a cofounder - but anyone worth that name will do these things for you and on your behalf.
Account Ownership
A successful tech product may take multiple services to develop and deploy. These can be domain name registrars, web hosts, email providers, and even things like Facebook apps and pages. Whenever possible, you should be the owner of these accounts.
Why wouldn’t you be? Often, it takes longer to get you to do a thing or set up an account, so the programmer will just create the account themselves. But, what if that programmer migrates away? What if they die? You could lose important access to your resources.
You should be an account owner of all services. If you’re not, make this a priority. This is probably the biggest problem I’ve seen with non-technical founders and can really risk - or at least slow down - a project handoff. Or even worse, lock them out of their own product!
Account Access
Some systems don’t have an account owner per se. They may have just admins. So, make sure you have an admin account to every product you’re using. You need to be able to have access to this service to add in new employees or contractors or remove ones that have moved on.
Now, here’s some straight talk: you need to have this access, but you need to promise your tech people that you’ll keep your hands off of the settings. Everything may be set up a certain way, and they may be reluctant to give you access because you’ll screw it up. A lot of people will think they’re knowing what they’re doing, but they’ll end up breaking something accidentally.
Demand access, but then leave it alone.
Password Manager
In rare cases, you’ll have accounts that you need to share the password of. You should already be using a password manager personally. Then, increase the functionality so that there can be shared passwords - likely this is some sort of team functionality. Invite any people who have to share that password with to use the team vault functionality.
When someone leaves the team, remove their access from the team. Then, change the passwords. I know what you’re thinking - I trust people and we separated amicably. Well, most security and hacking attempts come from those who had some form of access that is still active. Even if your former colleague didn’t purposefully attack your account, perhaps someone attacked their computer and then got access to your account through them (unwittingly / unknowingly).
Use a password manager. Rotate the passwords.
Source Control / Data Servers
The source code - which is the instructions that put together your technical product - is your most important asset. Then, your user data is a close runner up. These are two things that you should have some access to, always. Insist that your team use a source control tool and that you have access to export your data should you need it in an emergency.
Get access to your source code and your data, but don’t do anything with it.
Data Reporting
You should expect that your technical programmers and contractors will make reports for you to view your data. But, you need to have an idea how these are built and be able to reverse engineer them to some extent. It’s reasonably easy to fake numbers and information - either intentionally or accidentally - and this can’t happen. You’re likely going to make business decisions and try to gain funding based on your data, trends and information. You must be sure that you understand how a report is put together.
Have people build reports for you, but make sure you understand what the reports are saying. Also, make sure you understand how the report derived and created the data.
Wireframes / Mockups / Prototypes
Wireframes are visual representations of screens and product flows that are very plain and unadorned. They are likely black and white. They help you understand how the screens will flow and what data will be captured, without distracting you with design choices.
Mockups tend to extend into the design - they will represent screens using your colors, styles, and sizes. You can give design feedback with these - and they tend to come after wireframes because they take longer to create.
Prototypes may be actual working bits of code that represent functionality, but are not durable or integrated into your project. These are likely something that you can click and watch state change. This could help you “feel” how your product will function.
When you’re working with your programmers, unless something is a very small change, you should demand some sort of visual representation of the work from them. Wireframes at the very least - especially if you have an existing product and flow that you can build off of. If it’s brand new, you may want to push for mockups or prototypes as well.
Whatever you have in your head - even if it’s exactly the same as someone else’s thoughts and you’ve discussed it at length - is at least 20% different than what they’ll build for you. It’s more expensive to change code and product than it is to change wireframes and prototypes. And, when building these out you tend to discover more questions you have to ask and answer.
Define your requirements for a feature any way you’d like, but insist on having at least wireframes as well.
Relentlessly Question
If you don’t have a trusted cofounder watching your back, you must be relentless in your questions. Maybe you weren’t planning on learning as much about tech, but you’re going to have to. Constantly question your programmers until you understand. You are where the buck stops - not them.
Relentless questioning doesn’t mean to be disrespectful or to question their expertise - far from it. When I say that, it’s meant as a way to give you permission to invest in understanding their expertise. You may not be able to do what they do, but you should be able to explain it. If you can’t, how can you be responsible for owning it - let alone measuring if it’s the product you’ve asked for?
You need to ask questions about technical product concepts and decisions until you understand, comprehend and own the answers. What is being built, after all, is the main asset of your company.
Final thoughts
You need a technical cofounder.
In my opinion, it’s the single most important decision you can make at the beginning of a technical product startup journey. There will be tons of people out there that tell you this advice is old or out of date. They’ll say we have a lot of no-code solutions and that you don’t need a technical cofounder to make a tech company. They’re not wrong, but they’re not right, either. These tools help us get closer to a world where we can execute our ideas without the need to do some of the grunt work. But, there’s a lot more involved.
You need a cofounder to be your eyes and ears on the technical side, to free you up to do business development and sales, to watch out for your collective best interest when dealing with contractors, and to be a less risky option for investment dollars.
If you can’t find one, think about if you’re prioritizing the search and if your idea is polished enough. In the mean time, test out your idea and get it refined.
Finally, if you’re already beyond this state - or even if you do have a cofounder - make sure you’re set up to understand and access everything should your technical resources or cofounder disappear. You are only held hostage by technology if you let it be that way.