Remote Staff: Building your Dev team on a Budget

🤝 Building a remote staff by necessity…

Two years ago, Travis and I met on the Internet. We were complete strangers who met by chance on Craigslist through a gig posting.

We had an idea, the skills to execute and we quickly rolled up our sleeves and got to work.

Fast forward to today, and our partnership looks very different. While I’m still coding and Travis is still answering support tickets, we now have a remote team that helps us scale our business – one that we’ve grown to almost $20k MRR across two products in the Amazon space, with a third product launching very soon.

Did I mention, Travis and I both work day jobs still?  Not really because we have to, but because we can.

We built an entire business that earns almost $100,000 annually for each of us and we didn’t even have to quit our jobs to do it. That’s the power of a remote staff that can help you scale yourself and focus on serving your customers. We’ve learned some tips and tricks over the years that we wanted to share with you, so that you don’t make some of the same 5-figure mistakes that we made while going through the process:

 

1) Hire a few developers 🤓 on short-term contracts📑 to evaluate them.

I used to hire on Upwork by doing the standard process. I would post a job, wait for a bunch of inbound messages, and then interview 10 of them and choose one at the end.

The problem is, my interview questions were pretty arbitrary. They would tell me about their projects and show me some of their working knowledge, but it really wasn’t enough to gauge whether they would be a great long-term freelancer to work with.

remote staff

So, instead of doing lots of interviewing and hedging my bets on one freelancer, I learned that a much better process is to hire the top 3 or 4 for a month, giving each one different tasks. You can evaluate the overall experience at the end, and then choose the ones you would like to continue working with

We generally phrase it as a 20hr/week short term contract that has the potential to expand into a 40hr/week long-term opportunity depending on performance.
It really helps weed out the people that are just in it for a quick buck and are going to disappear quickly. The turnaround time on building a good team is so much faster this way, I will never go back to my old way of hiring.

 

2) Eastern Europe and Japan tend to have good developers.

From my personal experience, I have had good experiences with freelancers from Russia, Romania, Turkey, Japan and the UK. A likely reason is that their education system is very focused around mathematics and science in these countries, so software engineering is a skill that resonates well with them.

At the same time, stable tech opportunities are rare in these countries, so getting a consistent $30/hr contract is a good deal for many of these people.

Sign up today for our email list and get inside stories we don’t tell anyone else PLUS actionable tips you can use TODAY to scale your SaaS business.

 

3) More expensive is not always better, especially in development

A big misconception if you’re hiring through Upwork or other general-purpose freelance site, is that hiring a $80/hr developer will get you 4x the output as a $20/hr developer.

While this is true in SOME cases, the reality is, most dev problems in SaaS products have been
solved a million times before. Think login/registration system, Stripe integration, data visualization, syncing with standard APIs.

For these problems, the $80/hr developer won’t know much more than the $20/hr developer because the “right” way has already been standardized and published for everyone to use.

So, what you want is someone who is willing to read a lot of documentation and figure out the “standard” way of solving that problem. If you’re building a regular web app, there are enough resources online to get a great developer for $25-$30/hr, who has taken the time to learn that standard solution.

 

4) Find specialists in your niche for 📞 customer support

For our Amazon products, we used FreeeUp to source Amazon specialist VA’s who are already pre-trained with some Amazon knowledge for $8-15/hr. This was a game-changer for us in a way that I didn’t even anticipate.

Not only did our support specialist help alleviate us from responding to standard tickets that we had a playbook for, but she also helped figure out our responses to new problems as they were coming in.

remote staff

Her responses weren’t perfect, but they were good enough that our customers felt they were properly engaged.

his allowed us to only focus on the fires that would have brand impact, while our remote team handled the regular day-to-day support questions.

You can do this too – there are oftentimes people that work for minimum wage doing odd jobs that power the domain you’re in, who randomly have a LOT of experience and knowledge that you can leverage if you’re building a product. Hire them to be your support and you will find that you can offer them a great deal for their experiences.

 

5) Use freelancers to scale yourself, not remove yourself.

Your initial reaction after hiring your first remote team will probably be something along the lines of, “Cool, now that I have my team, I can be less engaged with support and interacting with my customers.

This is a big no-no, especially if you’re a newer SaaS trying to win the brand away from established companies.

The problem is, over time as you remove yourself your customers hear from you less and less. You become less aware of the problems in your own product, and the feeling of being a small business that cares about your customers starts to fade.

You will lose the advantage of being small and nimble, which may be your best angle competing with the other companies that have gotten big and fat already.

remote staff

Here’s a good way to avoid that problem. Any way you have a customer support issue that hasn’t been solved before, answer it yourself. Then, copy the solution and make a manual article out of it using Manula.

Train your freelancer on that specific question, and have them send out that article. Over time, you can remove yourself from that day-to-day operation, while still being keenly aware of your own product and the feedback.

Travis and I are still on our Facebook group answering support requests everyday. The difference is, now, we’re able to focus our heads on responding to the big ticket items that will impact brand (someone yelling at us in our Facebook group looks really bad, for example), and letting our remote team handle the smaller support issues.

This ROI on our time is so worth it and enables us to find the middle-ground between self-serve and horrible customer support, and being too involved and never having any time because we’re always answering support.

Sign up today for our email list and get inside stories we don’t tell anyone else PLUS actionable tips you can use TODAY to scale your SaaS business.