So… How are you going to get all that tech built?
For the vast majority of startups, the technical components of their company and product are easily the riskiest. Custom development is expensive, whether it’s for the product itself or just for the support tech to enhance, deliver and manage that product.
On top of that, the choices are confusing, sometimes arcane, and constantly changing.
- Do you build a complete full-stack solution or piece together some hybrid of off-the-shelf products?
- How will your store your data? How will you protect it? How will you keep it private?
- Offshore development is just hackers and headaches, right?
Do not just jump into these questions. There are a couple of pre-check steps you need to take before you start spending money hiring technical help. The trick is to do your due diligence on these pre-check steps, because what you learn will tell you how to hire your tech team.
Pre-check #1: How much tech do you understand?
The first big factor in who to hire comes down to the size of the gaps you need to fill.
So the first question to ask yourself is: What knowledge do you already have on hand? The answer to that question will tell you what you need to learn. Then you can figure out: What do you need to hand off to someone else?
Code it yourself? I started out as a developer and still consider myself a technical entrepreneur. I can get pretty far on my own. If you can do this, I’d recommend it.
Learn to code it yourself? If you have a technical aptitude, or even just a can-do ethic, you’ll be tempted to take some time to learn to code so you can at least get started.
But here’s the thing.
If you’re the CEO or playing any role other than the lead developer, you don’t want to be the lead developer. One of the reasons I don’t code much anymore is the opportunity cost of my time spent reinventing wheels because I don’t live tech and I’m not up to speed on the latest developments. The time I’m taking to figure out which AWS service to use is time better spent elsewhere.
So regardless of how much tech you can sling, I’d spend less time learning to code and more time learning to understand how technology works for your specific needs. This is one time where you’re better off talking the talk than walking the walk.
Pre-check #2: What exactly are you developing?
When you do eventually line up your development resources, you don’t want them reinventing the wheel either. You also don’t want them spending time developing great tech that ultimately winds up not being critical to your startup’s success.
For this reason, you should always get as far as you can with a stitched-together manual solution that uses off-the-shelf software that most closely mimics what you want to do. Limit the feature set, fake the tech, prove the idea and the model.
I’ve always been a huge proponent of a crawl before you walk before you run strategy. Lately, I’ve started implementing a new step: Crawl +
Crawl is when I use a mix of off-the-shelf software, manual processes, and limited custom technology to acquire the customers, conduct the product or service, and deliver and support the product or service.
I limit the number and type of customers I can serve, I scale the feature set way down to only what is possible with what I have, and I deliver and support in a clunky way that I know won’t scale. This allows me to learn a ton about the viability of my product and my system.
Here’s the problem.
When startups take the next step from crawl to walk, they usually fail at scale, because there’s no good way to prepare for all the outliers and crap that comes with a firehose of users and customers.
Crawl + is a period where I start learning from the crawl process, then addressing each part of the process and figuring out how to do the manual stuff quicker, smoother, easier, and better.
Almost every single time, the Crawl + step uncovers more wheels that don’t need reinventing and more need for flexibility than I thought was necessary. So when I’m ready to take the walk step, I build out only what needs to be customized and for the love of God I make sure it’s flexible.
After Crawl +, I know what kind of developers I need and what I need them to do. Now it’s decision time.
Your first tech hire: Kid vs. Pro
You’ll need both an experienced hand designing your tech and a bunch of labor to write your code. But now you should have a handle on how much of each.
When we broke down our system into Crawl and Crawl +, we realized there are three stages that we’ll need tech for: Acquiring customers, executing the use cases, and transacting and delivering the product.
From pre-check #2 we learned that at the edges of the system— acquiring the customers and delivering the product — we don’t need a ton of custom tech or deep technical experience.
From pre-check #1 we figured out our comfort level with understanding the tech we need for the step in the middle of the system: Executing the use cases.
The conclusion: How much initial tech experience we need on-board comes down to how much tech we need to execute the use cases and how comfortable we are guiding that tech, both in terms of understanding and time spent.
My last two startups did this very differently. At Startup A, we hired a bunch of junior developers and I guided them. At Startup B, we had an experienced CTO who spent a lot of time coding.
At Startup A, I spent way too much of my time guiding the development. At Startup B, we were overpaying for and nearly killed the CTO with low-level coding tasks. But in both cases, the tech eventually reached equilibrium.
So what I’d do, if possible, is structure your CTO path so that the CTO can start part-time and increase their involvement as the tech gets built out. I’d also start with contract roles for the junior developers, because you’ll end up with too much junior talent at some point, and some of them won’t be able to grow with you.
Other early tech hires: In-house vs Outsourced
The next big question is around how much of your tech is a commodity, because if the answer is “a lot,” then you may be able to find a trusted third-party development partner and stay with them for a long time into the life of your company.
Going back to your system: Acquiring customers, executing the use cases, transacting and delivering the product. The middle part is filled with important and critical intellectual property, the edges are not.
Anything involving IP needs to be in-house, and that needs to be under the control of you or your CTO or your CPO or some other trusted tech partner, be that an advisor or a consultant. If you don’t have a lot of IP in the tech, meaning your secret sauce lies somewhere else, you can and probably should outsource your tech.
Just remember that as you become more successful, everything will eventually need to be brought in-house, including all your tech. The risk of relying on third-parties to handle your critical functions will always grow past the risk of hiring full-time resources to manage those functions.
Outsourcing: Offshore vs Local
The last big decision really comes down to the caliber of the firms you can find. Because honestly, these days the only downsides to offshore hiring are the time difference and the language barrier, while cost remains a huge upside.
The point is, you can find good coders and bad coders both locally and offshore. You can find shady third-party development shops both locally and offshore. You can find bad management of outsourced teams both locally and offshore.
So again, it all comes down to how much tech is intellectual property, which comes down to how much tech is involved in executing the use cases. If you’re comfortable managing the management of an offshore team to handle that part of your development, the cost savings speak for themselves.
Hey! If you found this post actionable or insightful, please consider signing up for my weekly newsletter at joeprocopio.com so you don’t miss any new posts. It’s short and to the point.