When and how to build a team (contractors vs employees vs cofounders)

If your business does well, there will come a point when you'll need to decide whether to grow your team. And if you decide to do that, you'll also have to weigh the benefits of contractors vs employees vs cofounders.

These are not easy decisions to make. So how do you know which way to go?

Here's what I've found via experience, research, and other indie hackers. 👇

The arguments for and against expanding

First off, why might you want to bring someone else on?

• It allows for growth when you're maxed out on time.
• It reduces burnout.
• It creates an influx of fresh expertise.
• It reduces loneliness.
• It increases your network size.

And as for why you might not want to expand:

• It increases your costs and burn rate.
• It means more time spent managing others instead of building.
• It means trusting others with your baby.

So it's good to ask yourself a few questions:

• Do you have the cashflow to bring someone on?
• Do you have the time to onboard them?
• Did you bring it as far as you could? You should, at a minimum, have a validated MVP before bringing people on board.
• How can this push the needle for you? How will the business grow as a result of bringing someone on?

Expanding your team

So let’s say you choose to expand your team. Let’s dive into your three options.

Contractors

Contractors are an indie hacker’s friend IMO, provided you've got cashflow.

• They are lower risk.
• They are easy to find.
• They are easy to scale up and down.
• They are cheaper than hiring employees (and cofounders long-term)... but still expensive for most bootstrapped founders.
• They provide founders with existing infrastructure (tools, systems, etc.).
• They allow founders to access hyper-specialized talent.
• They allow for short-term work (as opposed to long-term hires).
• They put the task into the hands of an expert instead of a founder who is wearing too many hats. That means less errors and higher efficiency.

So that's great, but they should not take on integral roles — they should not touch things that affect the DNA of your company. If you’ve got a software product, for example, it’s not a good idea to have contractors building your software. There’s one exception to this, which I’ll get into later.

As for the downsides:

• They can be unreliable.
• They are less committed.
• There's often a slower turnaround.
• There's less accountability.

Contractor tips

If you go this route, there are a ton of places to find contractors. I wrote a long list of freelance marketplaces here if you're not sure where to look.

When hiring a contractor keep these things in mind:

• Consider looking within your own timezone (or within a few hours). Other time zones are manageable, but I personally find that it wastes a lot of time when you have to wait until the following day for responses.
• When looking for a developer, do a code audit before moving forward. Otherwise, review their portfolios, etc.
• Check references.
• Pricing is a big deal, especially for bootstrapped founders. But the more important the task is, the more important it is to hire for experience over price.
• Start with a trial project — something small and relatively unimportant.
• Document objectives and requirements meticulously. This is huge. Then ask them to walk through the requirements with you so you know they understand fully — this is particularly important for tech feature sets, but it applies to just about all outsourcing.
• Review their work regularly and keep an open line of communication around how they're doing. The occasional code audit is helpful with technical resources — ask a friend or hire another freelancer to do it.
• Ask them for hard (and realistic) deadlines on everything and hold them accountable for hitting them.
• Set a regular meeting to regroup.
• Build real relationships with the person (and their manager if applicable).
• Once you know and trust the person, retainers are a good way to go for tasks, as they will ensure availability. For project contracts, get a fixed bid. Even better, try for "time & materials" with a cap.
• And avoid agencies! They cost way more and they're no better IMO.

Cofounders

I’m a big fan of bringing on a cofounder because it means you'll be working with someone who has as much of a reason to care about the product as you do. They’re pretty much the opposite of contractors. And they’re perfect for integral roles.

• They are fully invested in the success of the business.
• They are the cheapest up front, which is when you need to spend the least.
• You'll feel less alone when you've got someone going through the same trials and tribulations as you.
• They can have a huge (positive) impact on your business — much more so than contractors and employees.

As for the downsides:

• They reduce your ownership and authority.
• They increase the risk of conflict.
• They can have a huge (negative) impact on your business — much more so than contractors and employees.
• The partnership requires a lot of paperwork and negotiations.

Cofounder tips

I posted about where to find cofounders here.

When bringing on cofounders keep these things in mind:

• There is no situation where it is advisable to bring on a cofounder before you’ve got an MVP. Build something first. Use no-code, spreadsheets, whatever it takes.
• Bring them on to fill in the skills that you don’t have. Don't double up.
• Never bring one on to fill short-term requirements — make sure they’ve got ongoing work for the lifetime of the product.
• Never bring one on for a non-integral role.
• Vet them heavily. Check out their LinkedIn and socials. Have they worked for notable tech companies? Take a look at their previous projects. Do the products function well? Are they user-friendly? How are the designs? How impressive are the technologies?
• Make sure they're someone you want to spend a significant amount of time with.

And here's an unpopular opinion: If you're a developer, bring on a marketer. If you're a marketer, bring on a developer. This depends a bit on your niche, but generally speaking, those are the two roles that I personally feel are important enough in the early stages to justify bringing on a cofounder.

Now, bringing on a cofounder is much more complicated than bringing on a contractor. I wrote about that here so I won't do a deep dive here. But in short, settle on terms, update your operating agreement, update your articles of organization, update your entity type if necessary (single-member LLC to multi-member, for example), decide on how to split equity (I lean toward equal(ish) splits), consider a vesting schedule, figure out how you'll pay out the profits, and draw up a founder's agreement.

Employees

For 99.9% of us, employees are never going to be the answer. In my opinion, they're only a good option in one situation: If the role is integral but it doesn’t make sense to bring on a cofounder (i.e. not enough work long-term). That said, here are some benefits:

• They are more long-term than contractors (but less so than cofounders).
• They are more dedicated than contractors (but less so than cofounders).
• They are cheaper than contractors and cofounders in the long run (sometimes).
• You maintain more control.

As for the downsides:

• There are lots of laws and regulations.
• You have to deal with payroll taxes.
• They are harder to scale up and down

Employee tips

You can find employees by posting a job listing in niche communities or with the usual culprits like hired.com, monster.com, indeed.com, etc.

When bringing on an employee, keep these things in mind:

• Hire for culture fit.
• Get to know the person.
• Trial them as a contractor first if they're open to that.
• Consider looking within your own timezone (or within a few hours).
• When looking for a developer, do a code audit before moving forward. Otherwise, review their portfolios, etc.
• Check references.
• Review their work regularly and keep an open line of communication around how they're doing.
• Ask them for hard (and realistic) deadlines on everything and hold them accountable for hitting them.
• Set a regular meeting to regroup.

You'll also need to register with your state's unemployment insurance office, verify their eligibility to work, get workers' compensation insurance, report them to your state's registry, set up payroll and tax withholding, get a W-4 from them, and comply with OSHA. You can learn more here.

The best option for indie hackers

Here's the long and short of it. Don't grow your team until it's the only way to hit your goals, and certainly never before you have a validated MVP. Also, keep in mind that if your goal is to be comfortable but not necessarily a gazillionaire, you probably don't need to expand.

But if you do expand, here's an over-generalized rubric to go by:

• Hire contractors for non-integral roles.
• Bring on a co-founder for integral roles that are long-term.
• And hire employees for integral roles that don’t lend themselves to partnering up (e.g. not enough work long-term, etc.)… and only when you're late-stage.

When in doubt, opt for a contractor as it's lower risk and can easily expand into a cofounder or employee role.

Find like-minded people on IH

I already mentioned where to find these new team members, but I'll add one thing here: The people who really understand what you're doing are going to be other indie hackers. Folks on this site are scrappy. They get it. And many are looking for either cofounders or cashflow to extend their runways. Consider working with them. Check out IH's partnering up group

And a quick note about onboarding

I've been onboarded as a contractor, employee, and cofounder a number of times each. And I can say that onboarding is so, so incredibly important. Siloing new contractors, employees, or cofounders does not set them, or you, up for success. Share as much as you can with them, even if it seems irrelevant to their roles.

What did I miss?

Subscriber for more tips, how-tos, and case studies

The Boot's Trap 🪤

Learn from indie hackers who are in the thick of it

Subscribe