This is dated. There's no rules to founding your own company.
As a non-technical founder I can
A) Get a technical cofounder which takes me weeks to find, dilutes my ownership, and with whom I have no recourse if their work is sub-par (or we end up just not liking/trusting/vibing with each other)
or
B) Build an MVP with any number of offshoring partners in a matter of weeks and for far cheaper (money, time, opportunity cost). If I don't like the work, we can modify the contract, or I can quickly pivot to another team.
This is also true for technical founders as well, to be clear. You can probably do a lot of the business stuff by outsourcing. You can worry about gelling a team once you've got to 1.
Heh, good luck. As a tech cofounder, I attempted to do just this and I have extensive development and management experience. It was a nightmare, EVERY SINGLE offshoring company tried to play us as a group that didn't know their stuff, and when put to the iron they couldn't produce anything that would stand up--technically--against a mild sneeze.
If I hadn't been there, my other founders would have gotten up to their eyeballs in offshore dev debt and would have a giant hairball that even the most experienced tech people would be unable or unwilling to make additional progress against once the offshore team stops delivering.
So, good luck trying to lead an offshore team that's only interested in absorbing as much money from you as possible before moving onto the next sucker. If you don't think a tech cofounder is worth their ask, then you deserve to get exactly what you pay for.
Sorry you've had those experiences, but mine have been consistently profitable and pleasant. I think a big part of that was that I asked around before I selected an offshore partner, instead of just choosing the cheapest or the first.
I'm not the GP, but I know many of the tricks to watch out for:
- Offshore partner delivers software, but you dont have any code. Successive rounds of updates become more expensive. You cant walk away because you have none of the code. (Business co-founder has no idea and goes to new partner with binaries expecting updates to be delivered, then gets told they need to start from scratch)
- Offshore partner delivers software and code, but not the code corresponding to the software. You try to switch partners, but realize you start from zero, because you dont have the code
- Offshore partner delivers software and correct code, but only for the app/UI. Only they retain code for the backend.
- Offshre partner delivers code for UI and backend, but not the right code, UI is secretly pointing to a different backend with different code
- Offshore partner delivers correct code all around, but only they have the build scripts, dependencies, and cloud images required to run it.
- Offshore partner delivers everything, but only they have the data required to start up the system. New partner spends as much time figuring things out and eventually wants to re-code the whole system.
For each of the above, business co-founder goes thru the rounds two or three times. Each time, they spend 20 or 30k and each time they walk away with binaries they cant do much with. Eventually they give up, or find a technical co-founder.
whoa. these are obvious in retrospect (they're the same ftbfs and saas tricks debian spends most of its time fighting) but i wouldn't have thought to expect them in this context. thank you
to get from zero to one, which i think is what you're referring to with your 'once you've got to 1' line at the end, you need to first find a market that's at zero; a product/service that doesn't exist. but that isn't enough; then you have to take it to one, a product that does exist. there are three piles here:
1. product categories that are technically feasible and profitable and where products already exist;
2. product categories that are technically feasible and profitable and where no products already exist;
3. product categories that are not technically feasible, so no products already exist.
anyone can tell the difference between pile 1 and piles 2 and 3. but you need a technical cofounder to be able to distinguish between pile 2, which is very small, and pile 3, which is enormous. and that's not something you do once; it's an ongoing process that happens at many levels of detail in your product, and even at the largest scale it's a gradual process of reduction of uncertainty, because you don't really know that something is technically possible until it's been done
then, you need to actually build the first product in that category, which involves identifying, prioritizing, and mitigating the risks that could destroy it. probably in banking a lot of this is things like regulators, market moves, and bank runs, but in companies built on software, a lot of those risks are software risks, and you need technical acumen to do this
as a nontechnical cofounder, what value are you bringing to the table? your family's money? invest in a vc fund, or start one, though without technical cofounders you'll waste all your money on companies in pile 3. your business knowledge? that's worthwhile in some cases. your leadership and management skills? likewise. but you're going to have to offer convincing evidence of something like this to be a good option for anyone to invest their money in
> you need a technical cofounder to be able to distinguish between pile 2, which is very small, and pile 3, which is enormous
Huh? A technical cofounder doesn't have any sort of monopoly on feasibility, and there's dozens of ways to understand opportunity space, PMF, and all the many other key considerations early-on.
As a nontechnical cofounder, what I bring to the table is enough wisdom and experience to get to a stage where I do need a CTO and technical team.
> technical cofounder doesn't have any sort of monopoly on feasibility,
it's hard to tell what you're trying to say here, but people with the technical understanding of a field do in fact have a 'monopoly' on understanding what is and isn't technically feasible in that field, to the extent that anyone understands it at all
for some products they also have a 'monopoly' on understanding what products there's a market for in the field. if you're developing a new kind of swiss lathe, your customers are going to buy it, or not, in large part based on technical features like mrr, repeatability, and cycle time. if you don't understand the technical field, not only won't you understand what is technically feasible, you won't understand your product's value proposition. this obviously doesn't apply to mass-market products
in a gold rush, though, selling shovels to gold miners is more reliably profitable than mining gold
Nothing you just described requires an entanglement with full-time technical cofounder. I could get a ROM estimate on, say, your lathe from a product design/engineering firm for a few thousand bucks, use that as PRD + go/no-go, then take it to prototype/evt/dvt/pvt with any number of experienced partners on contract.
Don't know why we're having this argument. Outsourcing is a very common thing.
Honestly as a technical guy: You come off as greedy.
As a technical founder, I face the EXACT same risks. What if the business guy can't drum up money? What if he can't sell the damn pen.
Most companies fail, the strongest firms will have strong business and technical people.
If you want to stand on one leg. Go for it. You'll piss your money away overseas. When you need someone to help you get across that line... there is nobody at your side.
Founding a successful company is hard. You will face days where you don't have the answer. Things will happen that are outside your experience... and yes, you can buy, buy, buy your way there... but remember, you are buying mercs. I've been a merc. Win or lose... I get paid, so, yes sir. How high sir?
Rework is just more money.
... You sure you want to be on the other side of the table from someone like me, without someone like me at your side?
Because all those off-shore firms... are more merc than I am.
I just mitigate as much risk as I can, as early as I can, and it's worked so far. Tech is littered with hundreds of companies that died because of personality conflicts - which can be readily mitigated with an MSA and SOW.
As I note in my original comment, my approach can absolutely be utilized by technical founders.
No contract can save you from what you don't know, and don't understand.
Different points of view, if they can stay respectful. Can be a great strength.
I see the world in terms of risk. If X will help me derisk something. Even if it isn't totally EV+ it can be a good play, because risk of ruin is real. Especially with large amounts of money, and small numbers of trials.
25% less to have a 10% better chance at making 75m vs 100m? Probably worth it a that level. Because 75m or 100m is life changing money for 99.99% of people at least. The amount won't matter as much as your chance of getting to it.
As a non-technical founder I can
A) Get a technical cofounder which takes me weeks to find, dilutes my ownership, and with whom I have no recourse if their work is sub-par (or we end up just not liking/trusting/vibing with each other)
or
B) Build an MVP with any number of offshoring partners in a matter of weeks and for far cheaper (money, time, opportunity cost). If I don't like the work, we can modify the contract, or I can quickly pivot to another team.
This is also true for technical founders as well, to be clear. You can probably do a lot of the business stuff by outsourcing. You can worry about gelling a team once you've got to 1.