When should you hire full-time?

Written by


The featured image for this blog post.

Prototype? Check. ✅

Validation? Check. ✅

Hire?... 💬

When you need technical help for your next iteration, the way forward isn’t always clear. Some startups have a lot of success using agencies or contractors at first. For example, our clients (and Slack).

But other times, or after you’ve partnered with an agency, a hire makes more sense. How do you know when that’s the case? 👇

Legit indicators you need a full-time engineer

You need daily, long-term support 📅

When you hire a dev shop or contractor, you pay for a piece of their time. Or you pay for all their time for a short period. When you hire in-house and full-time, you’re hiring for all that person’s work time, until they quit or you fire them.

The flip side of this? You need to make sure you can fill 40ish hours of someone’s work week, for at least 3 months, before you hire them.

You need support that’s only focused on you 👀

Most development shops work with multiple clients at the same time, which means that you’re not their only priority. That’s not always a bad thing, but it does mean your project won’t get the kind of attention it would from a dedicated in-house employee.

One area where the downsides of an outsourced team can show up is support. We can’t always drop what we’re doing to handle a support request, because it wouldn’t be fair to our other clients.

👉 I break out more pros and cons of freelancers, dev shops, and DIY approaches (like learning to code) over in this guide.

You’re generating enough revenue to pay two salaries 💰

Senior software developers can cost upwards of $120,000 per year, plus any benefits. Some applicants may accept below market rates at startups, but they won’t accept peanuts. 🥜

Other costs you want to factor in:

If you’re bootstrapping, you need a functioning business model that’s generating enough revenue to consistently pay two salaries (yours + developer’s).

Note: You can pay yourself less than the rest of your team, and you probably should in the early days. But it’s generally not a good idea to pay yourself nothing. You will be distracted if you’re having to worry about bills and buying your next meal.

You can articulate a clear vision, market, and sales strategy 🎯

From an employee’s perspective, signing onto a startup as the first hire is exciting but also scary. Applicants know that most startups are volatile and a lot of them fail. A clear vision and roadmap will give your first hire purpose and autonomy--things they’ll need to weather ups and downs and stick around.

You can handle the massive timesuck ⏰

It’s easy to think, “oh I’ll just hire someone,” but the process for doing that is pretty damn involved. Hiring your first technical employee can include:

That’s a TON of time and (if you truly need to hire) you’re already short on that. If you need to bring someone on, it’s worth stretching yourself for a month or two. But make sure you need a full-time team member before embarking on the process.

All too common, non-legit indicators 💩

There are a few reasons founders hire that are pure bullshit. The first reason is because, “hiring seemed like a cool thing to do.” This is more or less the same thing as, “hiring for the sake of hiring.”

Really, the only worse reason I can think of is, “because I can afford it.”

If any of these are your primary reason for hiring, slow your roll and take building your startup’s culture more seriously.

Some of those legit indicators ring true?

Next week, I’ll share some thoughts on another tricky piece: compensation, equity, and figuring out what to offer your first employees. 💸

Reminder: I’m covering this kind of stuff in even more detail in The Technical Hiring Handbook. 📚

Meanwhile on the blog… 🖥

I don’t always do a great job letting you know what’s happening on the blog. So here’s a roundup of what Krit has published this quarter:

“If you don’t hire very well, you will not be successful—companies are a product of the team the founders build.” -Sam Altman