The Series A Startup Guide to Outstaffing Software Developers by@oleg_guryanov

The Series A Startup Guide to Outstaffing Software Developers


An introduction to outstaffing for founders and execs of Series A startups.

While it may seem a little off for a startup to outsource software development, the talent market (and the COVID-19 pandemic) definitely suggest that it is a great opportunity to gain a competitive advantage by adding remote tech folks to your team.

Over the past few years, we’ve heard many stories about the failed attempts of founders to build the right outstaffing and outsourcing capabilities for their startups. And this is true. Navigating the area may be a complex and time-consuming process, so it’s better when such things are planned ahead, thoroughly reviewed, and the decision is made using accurate data.

The overall market is hot right now, and prices are higher than usual due to qualified talent shortages worldwide. So I wanted to share a quick guide on navigating the process of selecting development teams for startups at the Series A stage. However, the same practice of dev team selection may be applied at other stages too, as well as at Seed, to outsource the initial product development or MVP. But Series A startups are considered to be those that already have a software development process in-house and need to boost the engineering organization by adding remote engineers. Consider this to be a quick reference specifically tailored for Series A startups.


Series A startups tend to operate at a fast-moving pace, and everything that’s happening inside the company looks a little messy, and that’s okay. If you can control things — you’re moving too slow, right? So, sometimes it’s tempting to speed up the selection of a software development team, but in reality, this requires a thorough process. Let’s review how to get things in order in a comparatively fast way.

The first step to get this started is to reach out to your network. You need a solid reference here that comes from your network. Reach out to your VC, partner, or angel to see if they might have a reference for you. VCs and angels usually have a portfolio of companies with different stories, and there is a chance that one of those may have built a successful software outsourcing capability and could make an introduction. Don’t give up (I know you never do) if your partners don’t have a reference. Startup founders network a lot, so reach out to your peers to see if they outsource or outstaff engineers and can make an intro or know someone to refer you to.

Once you get the referral, don’t rush to sign a contract with the referred company. You may want to get more information, as well as some other prospective partners from the market. Reviewing such sites as Clutch or Goodfirms can give you a few more great leads.

Generally, having more than one potential partner gives you perspective and ensures you’re getting the right fit and the best deal. Pay attention to reviews and projects that those sites are offering.

Once you have a shortlist and knowledge about your options, it’s time to get the process going.


A good way to start the process is to craft an RFP. Including things like an introduction, company info, project overview, proposal details, and next steps would definitely be helpful for the potential partner to respond in the best way possible.

While company info, project details, and next steps are company-specific, let’s look closely at the proposal details — as this is what you want to know about potential partners. Good RFPs I’ve seen include a partner’s company overview (a.k.a. sales deck), client testimonials, case studies, previous work, developer profiles, pricing structure, and any additional information they might consider to be helpful.

Engineer profiles are a great reference, but more than likely, those engineers are not available, or if they are, they won’t be available by the end of the RFP process, unless you sign a contract right away — which I know you won’t.

The RFP response highly depends on your project, especially the pricing structures, and technically this is a topic for a separate article. At this stage, prospective partners share their rates per hour (unless you’ve shared the full PRD or SRS), as if you’re looking into an outstaffing type of contract — not a project-based one. In most cases (based on what I’ve heard from founders of Series A startups), an outstaffing type of contract is preferred over a project-based.

The explanation for this is simple — it is much easier to work with the remote team using a monthly burn rate and an internal team that assigns tasks and things to work on. The project-based approach takes more time to process, and the remote team will have a PM who intermediates between your team and the partner’s outsourced team. You want to build an engineering organization with higher velocity.

When you have all the responses, it’s time to review them and interview those who stand out.

Tip: Don’t brush off a company that hasn’t done anything specifically in your industry or domain. Many software development and outstaffing companies are industry-agnostic, and they might have a successful blueprint that can be widely adopted across industries.

The second stage of the RFP is the interviews. While things like warming up and “about the company” conversations are a good way to start, the things that truly matter come later during the interview. Your goal is to read non-verbal signals and understand the cultural fit and company culture.

But an interview with a great sales team is not a one-way street. They also assess the same things you do. If the sales team asks you the right questions, educating you and making you think differently — this is a strong signal you’ll want to account for in your assessment.

If you’re looking to outstaff engineers, try to dig deeper into how the company treats their engineers, what their assessments look like (when onboarding new engineers), and how they support or develop engineering communities. For project-based — what matters is their approach and processes for the product deliverables.

If you are considering offshore engineers, remember that the company location matters too. Ask where the company offices are located and where the engineers are based. Companies with a U.S. presence would definitely be at the top of my list. Although they offer slightly higher rates, you’ll be able to sleep better at night.

Tip: It’s nice to have engineers online during your normal work hours, but it’s not really that important. Work has shifted toward a result-oriented mode; the delivery was completed — period. The rest doesn’t matter much.

Try asking a few tricky questions, like what if we don’t like the engineer, what if we don’t see their commits pushed to the branch — most of the time, an enterprise-grade partner has processes in place to prevent the wrong things from happening, but just look at their responses for now.

Lastly, don’t forget to discuss the project timelines, or in the case of outstaffing, ask potential partners what their timelines are for allocating engineers. Also, ask for client references. A U.S. based-client could shed light on things that were left out of the conversation.

After completing the interview process, you’ll have a good data set you can use to make a well-informed decision. Compare responses against your requirements and try not to be emotional here; you need numbers to make your final choice.


Again, we’re looking into professional software development services, and a good contract can help navigate the relationship. What you’ll need here is your lawyer — because every company has a unique situation, and the lawyer can help you craft a contract that is the right fit for your company. A good contract includes things like payment terms, confidential information, restrictions on use and disclosures, trade secrets protection, non-solicitation of employees (both parties), work and assignments, IP license, representations and warranties, and termination and governing law, to name a few.

If you’re looking into building a unique product, you may also want to include that the partner should have your permission to engage with a competitive company or build a similar product for other companies. This may also include unique components of your product — for example, a chat feature in a healthtech mobile app.

Don’t overestimate your own lawyer skills. Get a good one, instead, to help you with the contract. You can also ask a partner for their contract draft and send it over to your lawyer for review.

The PRD and the estimate can be part of the contract for project-based assignments, detailing all deliverables and timelines.


Congratulations, now you’re on the way to accessing global talent and gaining a competitive advantage, along with other benefits like diversity and inclusion. After you sign the contract and get the software engineers that are right for your company, a few other things that may need some attention too are the payments and deliverables.

Depending on the payment terms, there could be a 50% down payment and a 50% balance payment once all-time tracks are submitted. At the end of every period (usually the beginning of the next month), you’ll receive a report detailing the work completed and the invoice. Make sure you also discuss the format of the reports — each report should include a task name, link to project tracking software, and time spent on the task for each engineer working on the project. This shouldn’t be complicated, as most project management software provides an option to generate time-tracking reports with just a few clicks.

Some partners may have a flat rate per month for each engineer, rather than an hourly-based assignment. This is also seen as a good practice that simplifies reports when an engineer is on your project for a full month.

Also, you can negotiate with the partner a post-payment structure, as well as NETs 15, 30, or 45, but there should always be a balance between the time of work the partner has completed and the funds that land their bank account. Find a win-win with your partner here.

If you adopt good practices for remote team management, or if your in-house team is remote, you may find it pretty easy managing the outstaffed team as well. For different projects, the deliverables are tracked in unique ways, but a good practice for monitoring outstaffing engagement is to look at the daily push commits initiated by each team member. If this is not happening, make sure you or your partner are equipped with the necessary tools.

For example, a partner may have an internal tool that tracks the commits of engineers. If the bot doesn’t see a commit for two days in a row, it notifies the engineer to push their code immediately and CCs the account manager to check in with the engineer.

Also, a great partner will be open to sharing the best practices of remote team management that you can implement across your organization.

The process of software development with outstaffed remote engineers is pretty straightforward. Your team manages the progress and keeps things under control. But you need to ensure that the outstaffed team possesses a specific skill set, is professional, communicates clearly, and is self-sustained. These things provide timely deliverables of your product.

Happy outstaffing!

Connect with me on LinkedIn.


Signup or Login to Join the Discussion


Related Stories