It’s Time to Hire a Real Tech Team for Your Startup

Hiring experienced technical help is one of the most important and most expensive decisions a startup founder is ever going to make. The problem is, most startups bring on dedicated tech resources either too early or too late, and, in either case, the results are usually disastrous. So how do you know when the time is right to take such a huge risk?

I’m currently building Teaching Startup, a tech-based product with a self-imposed rule of using only no-code tools  —  and it has very quickly become a revenue-generating product that already has tons of customers. On the other hand, I’m also head of product at a startup with the best tech team I’ve ever worked with.

I love no-code. I love minimum viable products (MVP). I love getting maximum value for minimal effort. But I’m also a former developer, so I know the pain of limping along to product-market fit then and spending hours every day working around the product’s shortcomings, especially on the administrative end.

Right?

Maybe. Here are the seven reasons that will convince me to take the plunge and hire real developers to build real software and robust business tools.

Get More JoeWhy ‘Fail Early and Often’ Is Wrong

You’re Making Money

I’m a big detractor against professionally coding an idea that has no hard evidence it will return a profit, let alone runway-sustaining profit down the road. At the very least, you should have an MVP that’s generating income and poised for growth.

But once sustainable revenue starts coming in, your job as the visionary has to become selling the vision to your employees, your customers and your investors. When the time you spend building what you envision is cutting too deeply into the time you need to spend building on success, it’s time to hire.

You Spend Too Much Time on Manual Tasks to Please the Customer

When you have customers, you will have expectations, questions, issues, requests and demands. These can come in sporadically or at once. When they do come in, you have two options:

1. Address the expectation, question, issue, request or demand right away.

2. Analyze and document the request, methodically strategize a solution when you see a pattern and develop that solution so it benefits both the customer and your company.

In the early days, your customers are your lifeblood. If one of them is unhappy, you might not only lose that customer, but chances are they aren’t the only customer in that boat — and you might lose those customers too. However, if you’re fixing every bug, tweaking every process and enhancing every feature, it’s not long before your tech gets out of control.

When the customer noise becomes overwhelming, it’s time for you to stop using option one and only use option two, handing off the prioritized, strategized solutions to someone else to implement properly.

You Spend Too Much Time on Backend Tasks

In the early days, it’s usually fine to lean on Google Docs and QuickBooks, maybe a free SaaS CRM, but at some point (and usually pretty quickly), the data around your product, your customers, your progress and your finances will become too intertwined to live in several different places. The duplication of effort alone can produce an inordinate amount of manual work and human error.

It’s my opinion that, eventually, your tech should absorb all your business functions — and I’m not alone. All the data you collect about marketing, sales, usage, revenue, costs and profits should have a single source of truth that is displayed in real time and under your company’s control.

For example: I’m still entering monthly revenue hits into QuickBooks manually for the no-code project. It’s just 30 seconds per entry. But as we’ve grown to over hundreds of customers, that 30 seconds is now a few hours. And if I don’t want it to constantly distract me, I’ll save the manual entry to do a bunch at once, which means my information is always at least a couple days old.

Someone needs to build me some APIs — stat.

You Spend Too Much Money on Third-Party Software

I could have run the no-code project on Substack. I didn’t do that for two reasons. First, it would have severely limited my scope, and thus limited my customer reach. Second, using the no-code route, I saved about 4 percent per transaction. It doesn’t seem like much, but at higher levels of revenue as I grow, that becomes a big number.

As it is, I now run five paid versions of third-party software, all of which started with a free level that I quickly outgrew. Now, as the project matures, I’m spending a lot more money. It’s a good problem to have, but much like I cut that 4 percent out by not choosing Substack, I’ll soon want to build those third-party functions internally for more flexibility and less overall cost.

You See Too Many Roadblocks on the Path to Scale

Every idea that goes into your product and your company infrastructure should have three stages:

1. How does this work today?

2. How will this work when it gets a ton of usage?

3. What happens when that usage outgrows the limits of my tools?

When that third stage starts to become an unknown —  in other words ,  if you don’t have a fallback plan for when you outgrow the limits of the tech tool — then it’s time to bring in tech help.

You’re Seeking Investment

This is kind of a garbage reason, but the vast majority of investors will still expect traditional tech that is built and managed by traditional technicians. We’re still a ways off from no-code and low-code being acceptable substitutes for the “real thing,” even though, when they’re done right, they theoretically and philosophically check all the boxes.

This is more of an understanding gap than a technical gap, but the lack of understanding will work against you.

You’ve Found the Right Partner

This is as good a reason as the rest of them. Whether you’ve found a willing resource you can hire on or a contractor that you can depend on (and if they fit your budget), it might make sense to establish a working relationship to secure their talents earlier than you need those talents.

In a startup, timing is everything — and sometimes that timeline might diverge from what you expect. But as long as you have the right expectations already in place, a little divergence now and then is a good thing.