I co-founded a startup that had a technically-solid product that people swore they wanted. It failed. I've also worked for a number of successful startups. And I've consulted for startups that succeeded, and ones that sank without a trace.
If there's any pattern I can see with the non-technical founders, it's that some knowledge of coding is certainly nice, if only so the founders can talk to the actual coders. But coding's not the most important thing. The two most important things for a non-technical founder are (1) understanding their market, and (2) closing deals.
Steve Blank (a respected startup expert) proposed a way to prove that you can do (1) and (2): Collect non-binding letters of intent from future customers. These letters should say something like "If you can produce software that does X, Y and Z acceptably well, we would would like to negotiate a contract with you for $1000/month." (See Blank's classic "Four Steps to the Epiphany" for more details.)
If you can collect 10 of those letters, then you should have no problem finding a technical co-founder, and you'll be bringing strong assets to the table.
(The details might be different for your startup. Maybe your product is only worth $200/month, or whatever. But the key point is that you can go talk to customers and close deals.)
I cannot echo this enough. If you're eventually trying to be the CEO: sell, sell, sell, and then sell some more. If you've got customers waiting, you have so much more of an advantage when it comes to finding a technical co-founder. "I've got this great idea." pales in comparison to "I've got this great idea and 10 letters of intent/1000 people on a waiting list/$X,000 in revenue using gmail and a spreadsheet." (not all of those but the more the better), you'll easily be able to find someone.
If you're eventually trying to become the CTO with someone else doing the selling, then learn to code it up yourself.
If someone came to me with 10 letters like that I'd probably jump at becoming a technical co-founder depending on my life situation at that moment. If it was bad timing for me I could connect that person with a few other people who would jump at that opportunity too.
I’m a CTO in a 20 man startup and have been through the ringer on several different projects through my career.
This is a difficult situation as positive founders that you can build a company with are hard to come by (been there) and outsourcing is a minefield. I would suggest not to engage with an offshore outsourcing company, I have had terrible experiences here (they may tell u they are under NDA so cannot share any of their ‘successful’ projects, of which there are probably none), and if they know you don’t know tech, it’s a free for all. The other issue is they will try to bleed you up front and most startups are based on iteration, but you will probably have no cash left to incorporate the feedback into another version. Also, the quality will be terrible and they will not care about your project. What could
Work, to get you started, is to find a single engineer you can work with (and pay) to get an MVP up and running, this could be a young guy or an off shore engineer but someone who will to work with you. This can keep your costs reasonable. The only issue here is that you have to think about how to move that MVP into a real product so you are really kicking the can down the road, but this can get you started.
In summary, avoid out sourcing like the corona virus.
Getting it right is not tracing a path on a map. Once you start traversing the terrain your perception about the thing will change. You will hit dead ends that you hadn't considered when looking at the map. You will realize you should have used another road or that you made a bad turn. You may realize the trip is not worth it after all. Etc.
Outsourcing when you're trying to figure it out is super expensive. Even more when you don't have the technical knowledge. Like John above said, it's better to find a cheap dev to produce a quick a dirty MVP, knowing this won't be the final product.
Another great metaphor I've found that helps think about this is that you don't build a car from scratch by building each part independently. You start with a kick scooter, then you make a bike, then you make a motorbike... until you finally make a car. The bigger the product, the more complex it will be, and the more interactions between all the involved parts.
> OK, so how do we talk about the prevalence of awful off-shore software-development firms without being "xenophobic"?
We don't, when the problem under discussion is endemic to outsourcing firms and has no particular connection to their location. The fact that there are lots of outsourcing firms that are, relative to where the demand for their services is, also offshore is completely beside the point.
No xenophobia intended, the same can happen with onshore. But, there is a tendency to jump off shore due to costs and if you are inexperienced it can go very badly. That’s all. I’m experienced and it has gone badly on past experiences.
I have been in companies where we'd outsourced to firms in India. The experience was not good for us, at all. The arm of the company that set up this arrangement, it went under. The offshore firm did not deliver.
I realized what seems to be a cultural thing with folks I'd worked with from offshore firms. They would nearly always exude absolute confidence in their ability to deliver what you'd requested from them, no matter how complex the task.
"Oh yes. Sure. No problem. We will get that done for you. Absolutely, yes. No problem."
You never heard humility in the sense of, "well, I/we aren't experts in _________ but we'll research and get back to you." It was always confidence, to the extreme.
I wonder why this is?
The reality ended up being entirely different. Many times, they had no effin clue. These were with some very big-name offshoring firms.
The flip side to that same coin… the folks from those firms that were genuinely skilled… they weren't in India. They got brought over on visas and were working in the US.
I once read that if you open a restaurant and know nothing about running a kitchen then the cooks own the restaurant.
With tech it's similar. You could supervise the end result but there are so many decisions taken "in the kitchen" that will have an impact in the product. Maybe 6 months from now you will want to implement a feature and because the developer decided to use XYZ it's not feasible to do it and you have to rewrite that from scratch.
I'm not saying all founders should be technical, but at least one should be. It's a software company after all.
> Also, worst case, the project fails but the technical skills I acquired make me more marketable for tech-type jobs.
This. The chances of hiring folks to build an MVP and getting enough paying users off that to bring them on full time or getting enough traction to raise money are absurdly small. If you're already both very wealthy and are the single most famous person in your industry then maybe there's like a 10% chance of it working, if neither of those things apply then the chances are much closer to 0%. What will happen is that you'll spend a ton of money to build something, not really validate any assumptions or de-risk anything, and then be stuck with this poorly constructed prototype that's too complicated for you to modify yourself.
Spend six months learning to code, then try to build your product. If you're not making progress at a reasonable pace then just get a job as a full stack developer and spend a couple years learning from the best people in the industry while getting paid for it, and then finish your prototype on nights and weekends. After a couple years of working professionally as a developer, things that would have taken you a month you'll now be able to do in a day.
I would tend to agree with this but there are also stories of successful non technical co-founders who managed to pull it off, although it could be selection bias. Airbnb is an obvious one but another example is DiDi in China. Their story was pretty crazy, they outsourced the production to a third party and that company outsourced it to another company who apparently found some university professor who asked his grad students to build it as an assignment or something. Then they took the shitty app and ran around trying to get investors and I guess in the end they pulled it off
> What about the chances if you build yourself? Any better?
If you have the skill to build yourself you avoid (really, reduce by some amount) the portion of the risk attached to getting people to build it (skill and counterparty and other risks) but you still have the market risk.
Hello - exciting times. I would reconsider learning to do it all from scratch. The economic law of comparative advantage, I believe, also applies to people allocating their time. Pair up with 1-2 people who have complimentary skill sets so you can each bring your best to the table, motivate each other and drive toward your final outcome faster. Time is your enemy.
I’m a non technical cofounder and CEO of a 70-person SAAS company (that’s bootstrapped). We could not have gotten where we are with without the other cofounders (there were three) and me pretending I could do everything and doing nothing well. We each were responsible for doing a job the others hated.
Anyway just food for thought. Email me if you want to hop on a call.
Learning to program will give you resilience. As a founder you are "the last resort" of the project. You will find yourself in this scenario many times and it's better to not depend on anyone.
When it comes to starting up, resilience and determination are much more important skills than outstanding programming skills. Or at least that's what experience has taught many of us.
Nowadays you can do a lot with few resources thanks to no-code tools , try to keep it simple and reduce LoC as much as possible. If you need a backend, tools like Firebase/Netlify/Saasify  are enough to build an MVP and get the ball rolling. And of course, do not try to build something that has 0 demand, just try to build the MVP that meets the demand you have identified and then take it from there.
As a founder you are "the last resort" of the project. You will find yourself in this scenario many times and it's better to not depend on anyone.
So glad you said this. Applies to other kinds of ventures, not just software.
I learned this lesson the hard way in my first venture. Co-founder flaked, left me swinging in the wind.
Vowed to start something new on my own as a solo founder where I could at least prototype and iterate early versions AND revenue was coming in the door from the beginning. This enabled me to hand off things that tested well to contractors and grow that way. Goes against YC "you must have a co-founder" dogma but it works.
As someone previously on your shoes, and. who now is able to code. do it yourself, seriously it's not that hard and you won't regret it, you can get an excellent CTO later when you need to scale and have already gained some momentum/traction/product-market fit.
There is an explosion of no-code tools these days - companies have gotten paying customers and become profitable without writing a single line of code. I'd try making a PoC and seeing if you can find interested customers.
Glad someone mentioned this. Tools like Bubble.io can help a relatively non-technical person get a MVP up in a matter of weeks. It’s particularly useful for any kind of CRUD app (which most SaaS apps are at their core).
As a bonus, using these no code tools forces you to learn how to architect an application at a high-level, which can be useful if you choose to learn how to code “for real” someday.
It looks like a win-win i.e. you develop a product and also develop technical competency however it is not, my suggestion is to keep them separate, you can always delve deeper into technology if you wish to do so. Learning technology will just put additional constraint on what you can deliver and when you can deliver your product. Decide one thing whether it is developing product or tech competence and give it 100%.
So for example if you decide to go for product than take the most efficient path to develop it either by using no-code tools or using laravel saas template or whatever language template that would make your job easier to get the product out.
If you decide to go for tech, to maximize your chance of getting hired you should go for leet code and associated sites to make sure that you are able to clear the interview, there are countless tales of technically competent people not able to clear the interview because the interview process in industry is rigged in favor of leet code type interviews.
Divide your SaaS project in small unit of task, explore each section unit by some video tutorial at first-good for first. try on youtube, freecodecamp or udemy. gain knowledge of subject and make small function to demonstrate the part of your saas products capability. Explore and learn, you can later hire some dev, co-founder or CTO of tech background.
Hi I am actually on the same journey as yourself though I am engineer from a different domain. This has been stated so many times here on HN but I will repeat myself again. Please ensure that you are solving a problem that exists. It could be a problem that you face in your own domain or a persistent friend that a friend has. Recently I phoned around 50 coffee shops that run on Shopify to see if they have a problem that needs solving. Talk to your customers and know them inside out. Know where they hang out and devise a plan to reach them.once you know your customers and where to find your first 10 you can then apply the frameworks presented by lefstathiou and others to go about building something either solo or with a co-founder. Email: vsap78 at gmaildotcom
Basically, it turns an un-used domain into a content aggregator (e.g. Reddit). But it does have quite a lot of features to build..
- contents via RSS and keywords
- membership, subscribers, automated newsletters
- traffic via sharing on twitter, tumblr etc
- monetization through ads
- SEO with sharing links with other users and building backlinks
The reason I mention is that many no-code people I spoke to found it an interesting way to "test out" the particular interest market and build some traffic (or at least try out) before diving in.
I have no idea what stage you are at for your idea, but I'd recommend trying to line up customers who love the product based on something you sketch out on a notebook (piece of paper) as a step one.
I'd also validate that the problem you are trying to solve is a really strong pain point for whoever is running into it. Having someone offer to pay you lots of money to solve it as a consultant is a good sign.
You can actually get pretty far with validating an idea before writing a line of code. You can even get potential customers to commit to paying you once it's built (some will renege later)
- there is a ton you can do before writing a line of code. In many cases since you are new on this journey, and your background is technical (stats, dabbling in code) the EASIEST part of the journey will be learning to build saas apps and/or finding a technical cofounder.
I’m a technical founder and would be happy to chat. Glad to try to point you to the next step, give a big picture overview of technical requirements, and possibly even be involved if we are a good match. Feel free to drop me a line email@example.com