Raising is tricky for every founder. There will always be 10s, even 100s, of nos before that final yes.
As a non-technical founder of a tech startup, it’s not necessarily harder, just a different game made easier if you follow the right steps and know what to avoid.
We’ve worked with, and helped, 30+ startups raise capital, have raised ourselves, and are now also investing in startups ourselves. Here’s our advice.
It’s easier to raise with tech than without.
In this day and age, pretty much any business can be tech-enabled in some way. Whether that’s starting a tech business from scratch, or transforming an offline business into an online one.
If you have an offline business that has found some level of product market fit and is generating revenue, you can put tech behind it, maximise your revenue, minimise clunky processes and save time and money.
If you have an idea for a business, it can be built with tech to maximise revenue from the very start.
For both of these reasons, raising money can be a lot easier. VCs and investors generally prefer tech because of higher valuation multiples and hence higher valuations on exit as well as easier scaling of the business.
So, it’s super important to consider how you can put tech behind your business. This does however mean that how you raise, when you raise, and what investors think of your business changes.
Here is what we recommend, and our tips:
This isn’t specifically for founders who don’t code, but it’s important for everyone to understand, and as you have to spend money on a development agency (no-code or custom code) an accelerator, venture builder or offshore developer, it’s an even more important point.
Our advice is to raise a small bridge round (at a sensible valuation), rather than a large, priced VC-led round, build a small, scrappy MVP, spend as little as possible and release it for customer feedback.
This means you spend as little as possible to prove the concept, prove you have a market and start to build traction. If you’re raising a friends and family round, don’t raise at an inflated valuation just because you can - you’ll end up regretting it later when you come to raise from serious investors.
One of the most common mistakes we see working with startups is founders spending too much money on the first version before validating the problem-solution, finding there isn’t a market and running out of money. A small bridge/initial round means you can prove traction without raising too much, giving away too much equity and then raise a much bigger round at a higher valuation.
Equally, most investors won’t be interested unless you prove traction. For VCs specifically, they tend to prefer 10k-20k MRR. You need your MVP/first version to build this traction and to have done this by spending as little money as possible.
An MVP that proves concept + good traction + a protected, lengthy runway = a startup worth investing in.
Custom code takes time and money to build. Often most tech businesses can prove initial market and traction without code altogether. Consider if you actually need it, at first.
Of course, it won’t necessarily scale, but you can build your MVP/website/online storefront with no-code tools like Caard, Shopify, Squarespace or Webflow, or with a no-code agency.
The natural instinct for a founder who doesn’t code is to jump to an agency/developer to build code for them. You may not need it.
Sometimes code just isn’t necessary and there’s no point in overcomplicating.
If you can build and not spend money on custom code and prove traction (even offline first) you can sell this to investors, showing how you’ve generated traction and protected your runway/been savvy with your cash.
The most important thing is proving your solution works, not what language/framework your product is built in.
The most important thing to investors (who themselves are likely not technical either) is selling the problem-solution, not the code that solves the problem.
That’s why we love working with non-technical/commercially-focused founders and they can be super successful– they sell the vision, they sell the problem, they sell the solution (and look past the tech).
Make sure you focus on selling the solution and how this makes the lives of your customers better, rather than the product/how it will be built.
And, if selling isn’t your forte, you need to learn to make it so.
We have seen a fair few non-technical founders getting caught up in the latest tech advancements and thinking including them in their proposition will mean they are more “investable”.
Often, the words AI/blockchain/Web 3 are included in a deck without any clear vision of how they actually enhance the proposition. The simpler really is the better and you don’t have to compensate for being non-technical by throwing tech buzzwords in.
All you need to do is solve one problem really well for a select group of people, adding in web 3/AI/blockchain will only overcomplicate things, cost more on development and cause confusion.
Resist the temptation to add in unnecessary tech.
As a non-technical founder, the tendency can be to bring in a CTO/tech lead because you feel you need to/or it will help you get investment.
Depending on the investor it may do, but it’s absolutely not necessary and can lead to some failed relationships that end badly.
Rushing to bring on a CTO for any reason is more often than not a bad idea. An experienced CTO who has likely worked in a big company won’t be able to build a small scrappy MVP and help you build from scratch (especially pre-revenue). They will likely not believe in the vision truly and will have skills far more advanced than what you need.
Equally, bringing on a CTO too quickly, without knowing them previously, often leads to misaligned vision, values and priorities. These things then lead to co-founder breakdown and, as equity is given away, a very messy breakup.
A failed CTO relationship means equity given away that becomes dead equity, and with investors involved too, you end up with an extremely small percentage of your own business.
Dead equity is of no use to yourself or to investors. Consider these relationships carefully.