Developing MVP without a Technical Team: Part 1

By: Nicholas Wilkins, Sign-Speak CTO 

Here at Sign-Speak, we are tremendously lucky to have a diverse founding team which mixes both business and technical skill sets, and respects each others’ strong suits. This has enabled us to move extremely fast, such as when we iterated our product 14 times over three weeks. However, as the Chief Technical Officer at Sign-Speak, I often have founders asking me “how do I find a technical cofounder” or “what should I do if I cannot find a technical cofounder”. To help answer those questions, I decided to write down some of my thoughts for those that might find this information helpful. 

For some high-tech and technically risky startups, finding a CTO is a necessity. For example, we’re training language models on a low resource language with a novel modality, so naturally, we require strong technical skills to pioneer new machine learning techniques. That is not true for everyone. For many startups, you can reasonably get by your beginning stages without a technical cofounder.

It is important to note that the goal of this post series is not to say that you shouldn’t find a technical team or a solid technical cofounder.  Rather, I intend to demonstrate what some alternatives are if you cannot find solid technical talent pre-minimum viable product (MVP). Regardless, it’s important to stress that if you decide to take on technical development yourself, you need to establish realistic expectations and initially develop MVP. In order to do so, we must first establish the type of risk your product will encounter.

One large impacting factor on your technical journey is Risk. Specifically Product Risk and Technical Risk.

Product Risk refers to the chance that a market will reject your product. For example, your customers hate the product and leave a bad review, or you can’t find people willing to pay your asking price. Technical Risk, on the other hand, refers to the risk that you cannot develop the product or feature you’re envisioning.

Generally, technical risk is hard to quantify for non-technical folks, but there are good proxies you can use to estimate technical risk. One such proxy is Technical Novelty. A good way of identifying Technical Novelty is if something similar to your minimum viable idea has been done before or is currently in the market.

Note that technical novelty is different from novelty as a whole; an idea may be novel, but only requires established technical methods and platforms. For example, let's take a hypothetical company called LinkedIn for Medical which helps patients find doctors and chat with them before consultation to get a feel for their personality. While this idea may be novel and revolutionary, it is not technically novel as it only requires repurposing social networking type tools.

An MVP which has high technical novelty or high risk is likely to be more challenging to pull off without a technical team than one with low technical risk. Please evaluate where you stand on the scale of technical novelty and risk. Stay tuned as next week we return to talk about alternatives for co-founders ready to build their MVP without a CTO.