How To Work With an Outsourced Tech Firm To Get Your Product Built

Five ways to mitigate the risk of unpleasant surprises

Image for post
Image for post
image by pch.vector

Having an experienced technical resource on your side to help you turn your vision into reality is an amazing feeling. Until it isn’t.

That’s the number one problem I hear from companies who work with an outsourced firm to build out their tech:

“I don’t know that things are going poorly until it’s too late.”

One of the stops on my startup journey was the several years I spent running a technical and product consulting firm. Smaller companies and startups would hire us to outsource their technical build, huge corporations and government organizations would hire us to be a technical bullshit detector on their outsourced development.

Here’s the cold fact. Technical development is full of risk and unknowns.

There are two ways to react to that reality. One is to shrug and hope for the best, the other is to mitigate the risk of unpleasant surprises from the moment you engage a technical firm.

I’ll distill my experience on the other side to talk about how to save your company some headache and maybe even a ton of money.

How to find and engage the right firm for you

The key to finding the technical development firm that’s going to work for you is to reduce the degrees of separation between you and that firm. And that takes more work than a search engine is going to do for you. Now to be clear, when I say reduce the degrees of separation, I’m not talking about physical distance, I’m talking about trust. You want to find someone you trust who trusts a firm that did actual work for them, and recently.

Start with who you know. Just as if you were replacing your HVAC unit or finding an honest plumber, and expand outward.

Be clear with what information you’re looking for, because the devil is always in the details. People will gush about how awesome a tech firm is until they actually hire that firm. Don’t ask if your network “knows” a good firm, ask if they’ve “worked with” a good firm.

On a side note: I actually never give recommendations on tech firms, as much as I know about tech firms, because while I know them, and most of them are awesome people, I’ve never hired one.

Once you’ve exhausted your network, go to competitive analysis. Look at companies similar to yours whose tech you admire, and call them up and ask them how they got it done.

How to negotiate results instead of the price

Don’t let this happen.

The vast majority of tech firms aren’t looking at you as they’re meal ticket. A firm worth hiring is going to want to do an awesome job for you. They’re going to want to call you a success story so that when other potential customers try to reduce degrees of separation and reach out to you for a recommendation, you’ll gush.

That said, they need to make a profit on the work, and since technical development is risky and full of unknowns, what they’ll often do is mitigate their profit risk by talking about payment by hour or week or sprint or whatever, instead of payment by result.

One concern I heard recently:

“We work with an outsourced company and develop under two-week sprint timelines. Although they deliver code at the end of each sprint, they often slip the overall feature timeline. Predictably, their work costs more than we anticipated, even though the quality is high.”

Bear in mind that a sprint isn’t a result, it’s just a label for a 2-week chunk of effort.

This is where you negotiate. Not in terms of rate per unit of effort spent, but in terms of rate per unit delivered.

And this is where you have to know your shit. Not necessarily the low level tech, but what you want to make it do.

How to create specs without a computer science degree

This is where the big mistakes are made, when people who need tech built spend too much time trying to decide if they need AWS or Azure, React.js or React Native, Postgres or NoSQL. You shouldn’t be making those decisions in a vacuum.

Focus on defining what the tech should do. Don’t try to determine how, just what, all the way from beginning to end, with all of the caveats and quirks. Then, for each action the software takes, have a defined reason why, and be able to communicate it.

Then you’ll be able to negotiate not by the hour, not by the sprint, but by connecting payment to progress. The firm’s job is to provide functionality that works, by feature. This will not only help you avoid surprises, it will make them invested in your success.

It’s also a good gut check. If the firm doesn’t want to work this way and insists on charging for effort instead of progress, it’s either because you don’t know what you want, you’re not properly communicating what you want, or they aren’t invested in your success.

Never go into negotiations with a tech firm without that documentation. There should never be an open discussion on what you need, only open discussions on how to get what you need done.

One more thing. Include all of your documentation as an exhibit of the contract, even if it’s photographs of sketches on napkins.

How to manage progress and minimize surprises

Don’t agree to two-week sprints. This is just a way to get to hourly billing without calling it hourly billing. Instead, agree to functional sprints and put two-week check-ins in place. If they want to go all agile and do their thing, give them that freedom. Don’t make it contractual, because honestly, you don’t care what they do every two weeks. You care that they deliver features on time.

Now, here’s where you want to give them leeway. Time.

First of all, if you’re paying for progress, it benefits them to get the most amount of progress done in the least amount of time. Second, understand the fact that sometimes it takes an hour or a day of creative thinking, which results in no progress, to shave hours or days or even weeks off the overall build.

A lot of tech isn’t done by experience alone, but by applying existing experience in new ways. Code is a mix of science and art. Give them leeway to be artists.

That said, never let them get away with missing a requirement, a review, or gaps in functionality. They agreed to the spec, they need to build to the spec. They need to be able to gauge their own abilities. If they can’t, that’s on them, not you.

Remember all that documentation you created and they agreed to, with all the whats and whys?

If everything goes wrong

You don’t want to have to get into a confrontation, but you want to be able to if you have to.

So make everything go right

Hey! If you found this post actionable or insightful, please consider signing up for my newsletter at so you don’t miss any new posts. It’s short and to the point.

Written by

I’m a multi-exit, multi-failure entrepreneur. Building Precision Fermentation & Teaching Startup. Sold Automated Insights & ExitEvent. More at

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store