Reducing Engineering Cost using Contract Developers

Outsourced engineering teams are gaining in popularity and many investors have started to treat them as a requirement. This is partly due to a confluence of factors that are driving the cost of software development. AI, geographic migration and SaaS company re-valuations are just the beginning. Now, it shouldn’t be news that the tech industry goes through regular expansion and contraction cycles but the deflationary pressures in this down cycle are strong. Utilizing contract developers for non-core intellectual property is not only viable, it’s becoming a necessity. So let’s get into how to avoid some pitfalls.

 

What Does a Seed-Stage CTO/VP of Eng do?

Before I go further, I want to make sure we want the same things. Prior to product-market-fit (PMF), I believe my job as CTO or VP of Engineering at Speedscale to be limited to the following goals:

1. Minimize time between product experimentation and customer feedback.
2. Drop the cost of producing each experiment as close to zero as possible – Don’t write code if you can draw a design. Don’t have a conversation if you can do it over email. Don’t write an email if ChatGPT can do an equivalent job. Think creatively.

Now, I could focus on other things like building for global scale, winning investor pitch competitions, finally learning to dance or eliminating technical debt. However, if doing those things makes sense to you at a <10 person startup, then polishing your resume is probably a better use of time.

 

Is Code Actually Your Core Intellectual Property?

It’s never been cheaper and easier to bring a SaaS business app to market and you may not want to pay full-price local engineers for some kinds of work. “Web forms on top of databases” is a well worn path and that type of engineering will be most impacted by these kinds of trends. That doesn’t mean that you aren’t building a super valuable business app. It just means the type of engineering skills needed are not as rare as they used to be. I would almost call them a commodity.

I personally have mostly worked at “deep” tech companies where the technical implementation is a substantial part of the valuation of the company. If that’s you, I recommend having a high cost site for serious intellectual property (IP) development and a lower cost site for less differentiated work. Why do you want your IP developed nearby?

1. The founders should represent the voice of the customer and your engineers need to hear that voice as frequently as possible. Language barriers, time zone overlap, Zoom miscommunication – all these factors slow you down in a million small ways that add up to a huge impact.
2. Intellectual property protections are weaker the farther you get from your home country (or your potential acquirer). I’ve worked on many M&A teams and we cared a lot about where IP was developed and by whom. If your principal engineer lives in Antarctica on an hourly contract that is going to affect the company’s value, especially if your company is small.

But what if your core IP is actually your business process, approach, product design, etc? Many of my peer companies have had success going fully offshore. To say it in management-speak, “it’s not a core competency, so pay as little as possible for it.” Or said in product terms, if your competitive advantage is your design or business understanding, you may want to go all in on outsourced engineering. Another good exercise to clarify your thinking is to draw your ideal technical architecture on a whiteboard using boxes and lines. If over half of the boxes can be off the shelf AWS/GCP services, you may want to consider contracting.

 

Defined Scope Project vs Hourly Rate

Once you change your title to some sort of engineering leadership role you can expect to be hounded day and night by contract engineering partners. It really helps with the loneliness of being a founder but it’s hard to figure out who can actually help you accelerate. The first decision to make in choosing a partner is their business model:

• Defined Scope Project – Asking partners to bid a fixed price deliverable can be helpful if you need to quickly build a prototype at a certain cost. This model has fallen out of favor in my circles because the outsourcer is incentivized to 1) bid the initial price as low as possible to edge out other partners, 2) increase the price over time with “change orders”, 3) treat their engineers badly because attrition is expected and 4) complete the work as quickly as possible, no matter what. Think a bit about point #4. I once did a project with a partner who was able to develop my e-commerce app at an astonishingly fast pace. I looked at their reference list and noticed a lot of other e-commerce apps. I also noticed they didn’t make continuous commits to my repo but seemed to dump code all at once near the delivery date. Now I am not always the spiciest hot sauce on the shelf but even I could figure out there might be some unauthroized “re-use” taking place.
• Long Term Hourly-Rate – This has become more popular in my corner of the world because it incentivizes engineers to stick around longer and develop knowledge of the code base. It’s more like hiring an engineer directly without the paperwork. The cautions with this model are 1) you need to pick a partner that is very good at hiring and retaining talent, 2) individual engineers sometimes do “high availability consulting” whereby they stack multiple contracts and only give each of them partial focus despite billing full time and 3) the outsourcer is incentivized to give you one stupendous engineer so they can load you up with three less capable engineers. You’ll think twice about firing them because of that great engineer. From their perspective they are “load balancing” talent across customers for fun and profit. Except I’m the customer, and I hate that kinda fun and profit.

Talk to ten engineering leaders and you’ll get ten different perspectives. My perspective is that I’ve occasionally had good results with project-based work but my success rate has been far, far higher paying by the hour and treating the outsourced engineers more like equal full time employees.

 

How to Pick the Best Partner?

You’ll notice that I use the word “partner” instead of “vendor” and this is intentional. A good outsourcing partner can give you access to top shelf talent in a part of the world you could never reasonably access yourself and at a reasonable cost. The best partner can really accelerate your ability to reach your goals. Having said that, much of my work revolves around finding the right things to measure so I’ve developed a rubric:

• Location and Time zone – Every partner has a location speciality because their primary function is recruiting and HR. Pick location wisely. Being able to jump on a quick videoconference does wonders for productivity. How much working time overlap will you have with your engineers? Also regarding location, you’ll find as you gain experience that certain locales tend to have more specialists in different technical skill sets.
• Buyout Process – Let’s say the big gorilla in your space wants to buy you and they don’t want want to deal with outsourced engineers. What is the process and what will it cost to buy out your engineers to make them full time employees? Don’t wait until you need it, negotiate this upfront.
• Termination Clause – Remember how I said some outsourcers will give you one great engineer and three bad ones? You don’t need to be combative but it never hurts to keep everyone honest by probing the termination clause for engineers that aren’t a fit during master service agreement (MSA) negotiations.
• References – Lots of partners can talk about how they did work for Google or Microsoft. Those companies aren’t doing what you’re doing so ignore the big names and pattern match on companies like yours. At what stage of the company’s journey did the partner work with them? Be detailed and specific on stage. Always call references if you’re serious.
• Skills Availability – Full stack engineers are everywhere but golang engineers that know the inner workings of Kubernetes are more rare than finding Bigfoot on Mars. If you start to scale, will there be enough engineers with your required skills to build momentum in a chosen locale? Bigger companies like “development sites” more than randomly placed engineers so it can pay to be colocated, even with an outsourced site. One way to determine this is by measuring the lead time between when you say you want to hire engineers and when you receive quality CVs and interviews from the partner. If they’ve got lots of experience with a skillset the turnaround will be fast.
• Spoken Language Proficiency – Decide whether this is important to you. Is it critical that the person doing bug fixes on your unit tests speaks your native language perfectly? Maybe not. However, what if they have to explain an architectural decision for a major new feature? Different answer.
• Hourly Rate – This is my least important criteria because saving $5 an hour is far less important than finding a 10x engineer. I’ve learned this lesson through horrible pain… lots and lots of agonizing pain.

 

How do I know if it’s working out?

For project-based work it’s important to remember that you can give up the management of the people but never give up your management of the project. Here are a few tips to keep things on track:

• Secure Senior Technical Review – Maybe you have a hotshot CTO that can do regular code reviews. Maybe you personally won the “most likely to beat ChatGPT at writing Java code” contest at your last company. For everyone else, get an advisor or someone you trust to review the work on an ongoing basis.
• Strictly Define Outcomes – The better you can define your outcomes beforehand, the more likely you are to be successful with a project-based approach.

For full time engineers, assess your contract engineers the same way you assess full time employees. You might want to bias based on the rate you’re paying but remember what I said at the beginning of this article. Your investors, including yourself, will measure you on output so you should measure the outsourcer in the same way.

To make things easier I typically set up the following guard rails:

• Bi-weekly 1:1s with every engineer – You can learn a lot by just asking questions.
• Quarterly business reviews with the outsourced partner – They get headlights into what you might need, you get an idea on how they look at you as a client.
• 30-day reviews on all new hires – This can be tough because the outsourcer doesn’t want you rejecting engineers. They put a lot of effort into hiring the engineer so can you blame them? Be compassionate but do this anyway because it forces you to summarize your impressions.
• Excessive Code Reviews in the beginning – I say excessive because code reviews are not usually the focus early on. Make it a priority for the first few engineers so you have a clear idea what you’re getting.

Contracting allows you to adapt to uncertainty more quickly than you would with full time employees. To a degree, this is expected but that doesn’t mean you should abuse that flexibility. Try and remember that you’re dealing with human beings with their own career and financial concerns. Hold both the outsourcing partner and the engineers accountable, but don’t lose your humanity.

 

Conclusion

Managing engineering at a seed or series A startup is one of the most creative and rewarding jobs you can have. The product is mostly a clean sheet so everything you build is new and exciting. But even in this environment you can’t ignore macro trends and lose sight of efficiency. Also: startups are hard and we need to help each other out. I hope this post was helpful in shaping your thinking around your own outsourced teams.

Special thanks to Mark Addleman (Pyze) and Leonid Igolnik (Clari) for some good ideas.