How Developers Can Ruin Your Startup Pt 2: Avoiding Technical Ransom

So here’s the reality: it’s hard to find a technical co-founder. When they can’t find one, they do what they think is the next-best thing:

Most less-technical founders hire a development shop and outsource technical leadership to them.

Now don’t get me wrong, this seems like an intuitively obvious thing to do. And it is. After all, basic capitalist theory says that you should be able to substitute money for labor. Heck, even companies with a technical co-founder hire development shops (I do it all the time). So what’s the problem?

Ask the leadership of any development shop (not the sales guys) why they want to work with startups, often at a discounted rate, which almost by definition don’t have much money. Sure, they get excited by new ideas and love the energy, maybe they love the founder in a deep personal way. But in the end, ideas and energy don’t pay the bills, and all those developers cost real money. So unless the shop is funded by a mysterious billionaire who pays coders for fun, those aren’t good enough reasons.

Here’s why they do it: if you succeed, they intend to make more money than they would have otherwise. They’re investing in you, sure, but all investors want a return – and at some point the bills come due. Their job is to minimize the investment and maximize the return. So as long as you’re moving rapidly towards being cash-rich, you’re usually okay. But when that seems less likely, or when someone else looks like a better bet than you, you’re in trouble.

I’ve seen this happen time and time again. One client spent a year and upward of $100K wrestling with a dev shop over a relatively simple coding job. By the time I arrived a simple request to change an htaccess file (a two minute job) took upward of two weeks. A request to build a one-page report was met with a $5,000 “change order.” His business was in danger of going under, solely because the shop he relied on had better things to do.

The Risks of Outsourcing Technical Leadership to A Dev Shop

Now I’m not saying this to demonize dev shops. They’re full of talented specialists and good business people. They’re not out to shaft you – their approach is a perfectly normal business decision. But it can have profoundly bad effects on a young company.

Here’s what I mean:

  • The shop is not going to be creative. It’s the unlikely dev shop that chooses to learn everything you’re learning about your business as you learn it so they can give you informed advice about what to do and in what order: their job is to do what you tell them. Come to them with a business problem and ask them for a solution, and many will wonder what you mean. On the rare occasion when you do find someone who can be innovative in solving problems, rest assured you’ll pay for it.
  • The shop wants to lock you in. Most shops will write you a nice fixed-cost “maintenance contract” that looks great in your financials and tempts you to run everything through them. Small HTML changes, marketing, social media, mailbox creation, bugfixes – why not let them do it all? You’re paying for it. Here’s the problem: when push comes to shove, a higher-paying client will take priority over you. I’ve seen simple requests take days or weeks because the right staff were “unavailable,” which means working for someone else. You wouldn’t tolerate an employee refusing a task you because “their other boss” said they’d pay them more. But if the shop is your only option you don’t have much choice.
  • The shop will not be flexible. Ask any project manager what they hate most and they’ll tell you: clients who change their minds. Sure, small changes on fixed rate contracts are to be expected, but after a point they lose money every time you need something. The weapon shops use to dissuade you from changing your mind is called a “change order,” which forces you to pay for any unplanned issues. Unplanned issues? You’re starting a company and things change daily – everything is an unplanned issue. You see the problem.
  • The shop will not share your sense of urgency. Here’s what happens with a typical development shop if a deadline is missed: nothing. Oh sure, if things go too far past deadline you unwind the relationship, and sometimes contracts have delivery delay penalties or service-level agreements (although any decent business development person will fight tooth and nail to avoid such things). The bottom line is this: delays can mean life or death for a startup, and the compensation of a few dollars is usually irrelevant. When confronted with a recalcitrant dev shop, your options are limited.
  • The shop will not necessarily recommend the optimal business solution. In technology there are many answers to any business problem. A good technologist will often find ways to solve problems that don’t require engineering at all. But when confronted with multiple options, the dev shop is biased towards the one that will generate more fees for them. It’s a rare businessperson who will leave money on the table out of the goodness of his heart . End result: you can never be sure if the direction they’re taking you is best for you or for them.

Technical Ransom

The problem comes down to misaligned incentives. No matter what your dev shop promises you up front, or how good your relationship is at the outset, the shop has its own business interests to pursue. When those don’t align with yours, rest assured which they will choose.

In the end, while tempting, placing technical leadership in the hands of an external organization carries an inherent and serious risk to your startup. When you’re $20,000 in to a development contract and you’ve made the decision to have no other technical staff on board, you either do (and pay) what they say or you have to switch direction – which is at best a costly delay and at worst catastrophic. Lord help you if your bill goes past due and they decide to hold your domain (or code or database) hostage as part of the “negotiation.”

By contrast, a technologist on your payroll works for you and shares your priorities: finding optimal business solutions, prioritizing properly, being flexible, managing creatively without excess cost, etc. Even if that technologist doesn’t do all the work themselves, their ability to oversee the external development shop gives you a much better chance of getting good technical results.

Michael Sattler

With a career spent in founding and technical leadership roles with new and enterprise-level organizations, Michael Sattler is a veteran in technology strategy, operations, and product management. He’s spent decades in B2B and B2C SaaS product development, software and application design, engineering operations, new venture creation, and innovation practices.

He has scaled and managed technical teams from 2-50+ across three continents, led large-scale cross-functional program management, and founded or co-founded six companies.