Should You Outsource Your Core App or Software?

I talk and chat to a lot with customers, prospects, or just entrepreneurs and business owners in various online and offline groups.

There is one question that keeps being asked over and over; I often reply on-the-spot and I always think “damn, I have to write a thorough blog post about it once and for all”.

The question has slightly different variations, but they all boil down to this basic dilemma:

Should we build our core app ourselves, or should we outsource it to external developers (overseas or local) and be done with it?

For non-technical startup entrepreneurs, the same question would be: Should I add a CTO / software developer as a partner, or should I do an MVP with an outsource company using my savings without giving out precious equity?

So let me give you my answer straight up, in case you don’t have time to read this post further:

The reason is that an outsourcing software company (a “digital agency” or “software shop” as it’s often called) will almost never care about your product and your software as you are, and you will enter into a world of agony, legal battles and a half-baked product (at best).

Now, I wrote both product and software. Aren’t they two of the same?

Not quite.

On the product side, the software is supposed to deliver business value (either a SaaS/startup, or a more “traditional” business that approaches outsourcing companies to build its core systems). And it needs to be user-friendly and convert well.

On the software side, you want your application to be secure, performant and extendable, and you want the codebase to be maintainable so you can upgrade and fix bugs in the future.

That’s the thing:

You will never It is very unlikely that you’ll get all of these when you outsource your core product. And if you will, there’s a very high chance that it will be way off budget and/or off schedule, and will give you quite a few facial wrinkles on the way there.

Now, for the sake of my argument, let’s assume you’re dealing with decent people. So even if you say “I know these guys” or “a friend recommended them to me, no worries mate”, remember that what I’m writing here is still applicable, in exactly the same way. Because it’s not necessarily about them; it’s about the way this engagement is based on.

For a start, the software shop you engage with is a contractor. You pay them a predefined amount of money and their business interest (with or without consciously doing it) is to spend the least amount of time and money on delivering your product. Which means some key components will probably not get done or will be insufficient. Especially those which can’t be measured as deliverables by non-technical people.

In order to really work with an external software shop, you’ll need a highly skilled person on your behalf, to even know what to ask, let alone how to validate that the outcome is on par with your product specifications, industry standards and technical requirements.

Having that sort of technical person would often mean having this person your CTO or business partner. If you want to go that path, that’s great! It will still be a risk to outsource your core development but that risk is going to be significantly lower.

These are some examples of technical aspects you might overlook and not get from an external software shop:

• Security – there is no shortage of stories where a company’s database has been breached and someone downloaded all of its users’ data, causing that company a huge PR headache and very tangible losses. Most often, it doesn’t involve any hardcore hacking but rather scanning the Internet and finding the data in the open, due to the consulting company failing to secure the access to the data files, or by just changing some simple number in the browser’s address bar.
  
  You might argue that it only happens to amateur developers but that’s not the case; plus, a company is as secure as its weakest person. Take Precedent for example. Their homepage used to say:

  “Celebrating 26 glorious years in digital.
  From strategy, web and mobile to brand, UX and hosting, we believe in meaningful ideas, intelligently delivered.”
  

  Sounds convincing, right?
  Wait, why did I write “used to”?

  That respectful company built a website for The Australian Red Cross Blood Service, which collects data from potential donors including some super-sensitive personal information. They had the database sitting in some dude’s desktop probably, unprotected, and people just found it and grabbed it. I wrote an extensive post about it.

  At the end of the day, that company shut down its business. That breach knocked them down and cut their income stream. Clients stopped coming.

  Data breaches are everywhere, take a look at this partial list to see how common it is. And it can definitely happen with your in-house development as well, but when you outsource it, the risk increases by an order of magnitude, because the software shop is not incentivized to apply man-hours for this kind of supervision, auditing and penetration testing.

• Performance – It’s one thing to make a site work for a handful of users and a totally different story to make it work at scale. And I’m not talking about millions of users. You might find that even when it comes to 10 concurrent users, your app would halt.

  It’s just not easy to create an app that allows for multiple users to work on it at any given time. It requires experience and it requires extensive testing. These things cost. And as I said earlier, the software shop’s incentive is to deliver in the minimal cost possible so if it’s not something “you see” then it won’t be done.

  The software shop will demo the site to you, and indeed it will seem to work fast. You will hand them the last check, just to discover a month down the track that the app is sluggish and gets stuck often.

  A canonical example of this is the HealthCare.gov (“Obamacare”). When it launched, it was a failure on a colossal scale. The site went down on its knees, no one could use it. The problems were so severe, that one couldn’t just patch it. The whole architecture was bad. Then several software experts stepped in and rewrote it almost in full.

• Maintainability – Soon enough, you’d want to add features. And fix bugs. The quality of the codebase you are going to get would hugely differ between software shops and even between different developers in the same software shop. You can write unmaintainable spaghetti code very quickly. Writing good, maintainable, extensible code requires skill and requires planning. These mean money and efforts spent by the software shop, and there is simply no way you could evaluate the code quality without a technical person on your behalf. Both come back to my earlier points about incentive and about having a technical person on your behalf.

These are some examples of product aspects you might overlook and not get from an external software shop:

• Mobile friendliness – These days it seems trivial that your web site should look great on mobile phones and tablets. Usually, that’s the case when the software shop uses a ready-made, modern site template. But when they’re not, then it’s up to them to successfully design a site that accommodates for every possible screen resolution. You, as a non-technical customer, won’t necessarily have the tools and knowledge to confirm that it indeed looks good on every resolution. Plus, if the software shop really wants to cut costs, and you didn’t define full site responsiveness as part of the requirements, then it simply won’t be done.
• Ajax – This is a simplified / shorthand word for the various techniques that change your user’s experience in your site from regular to great. “Old school” development means every click refreshes the page. “Ajax” (et al.) means updates happen in-place, quickly, without losing your user’s focus.
  It could be an in-place form update, search results suggestion (as you see when you start typing a few letters on Google, for example) and more.
  I continue seeing, until this very day, sites that are developed without this. Those sites work, and I guess they were designed according to the given spec, but that’s it. They provide more than 10-years-old user experience. Which means you will lose customers, as they will leave your site in frustration, or won’t add as many items to their shopping cart.
• Accessibility – Various laws in various countries require that consumer sites are developed with special markup that allows people with disabilities to browse them. Things such as color contrast, font sizes, text that can be audibly heard whenever visualization elements exist and more. If you don’t require this in the spec, more chances are that the site developed will not adhere to these standards. Again, it all comes from a cost savings point of view. Lack of site accessibility might also mean administrative fines imposed on you in some cases.
• GDPR – That’s the hot acronym in the last two years. This overarching directive imposes serious requirements on site owners: how do you maintain your users’ privacy, what sets of data do you keep about your users, how to handle users’ requests and much more. GDPR compliance makes it very hard to have your site developed externally, as it requires an intimate knowledge of the requirements involved, what can and can’t be done, who is responsible for what aspects of the data, what to do when a breach is discovered and more.

Now you might ask: Well, I’m a startup that only wants an MVP. Someone taught me that addressing performance too early is premature optimization. I don’t want to burn money before proving product/market fit.

You’re absolutely right. You don’t need to address performance straight away but you need it to be reasonable, in case you hit Hacker News front page and you want your code and architecture to support performance improvements, rather than hearing “oh we need to rewrite this, it’s not really meant to withstand 100 concurrent users”, when it’s too late. And your platform does need to encrypt users’ passwords from day one, because what you don’t want to happen is that someone would download your database and the negative PR will eliminate any chance of future success of your venture.

But beyond that, I’ve seen it many times: a product created by an outsourcing company will never have the quality and love that an in-house developed product will.

Furthermore, there’s the budget aspect which I briefly touched on in the beginning:

The budget tension between you and the outsourcing company

A software shop will always strive to minimize its man-hours. Given requirements from a client, they’d strive to deliver on them and no further. If you didn’t specify that your site needs to be accessible, it won’t. If you didn’t mention Single Page Application, it will be an old-school application where almost every click reloads the page completely. If you didn’t provide page size constraints, images and scripts won’t get compressed or cached, thus pages will load slower and incur more costs for you, as you probably pay for bandwidth. If you didn’t define that working with GIT is required and that you shall receive all the GIT history, you won’t. That’s something that will make it difficult for you to support the code and might bind you to that company in the future.

Time and time again, I see projects that fail due to friction between the customer and the software shop. She didn’t mention the site needs to be accessible, he didn’t tell us that the site will have many users at the same time. This happens with projects both in the private sector as well as government / public sectors.

And it’s not just about high-level features. You might argue that when you go do a decent software shop with lots of reputation and past projects, you are guaranteed to get top-standard delivery. So first, as a fact, it’s not true in most cases. What you see are projects which were well-managed by technically skilled clients who knew what to ask and what to validate. And, it can be a product of unplanned increased budgets to get there. But also, it could be the details that make up to a polished product or not:

Does the app have a long-running operation? If so – does it happen “in-line” while users wait or in the background? Do users see a progress bar or are they left in the dark not knowing when the operation is going to end? A quick & easy way to develop the feature is to just do it in-line. And when you see a demo, you won’t even notice a problem since the data is small and you’re the only user.

Does the app fully support HTTPS? Including all images and scripts it uses? If not, the browser might show a warning to the user, and rank your site lower, which will hurt your bottom line.

When errors occur, do your users see a friendly “we’re sorry for the inconvenience” message or do they see a technical error that exposes your site to risks of being hacked into? Are these errors automatically reported in some way that you and the developers are aware of them and can fix them, or does the site rely on the patience and good will of users to report them?

There are just so many things that distinguish a well-built site/app from a not-so-much, and you’re unlikely going to get a good quality site, on time and on budget, from a company that does it as a contract job.

And I didn’t even start talking about design and user experience, which is something of an art, and doing it right requires thought, patience and experiments. In the vast majority of outsourcing projects, it’s just not in the scope.

This sounds quite pessimistic. Is there anything that you can outsource, then?

Yes, absolutely.

By all means, there are things that can, and economically should be, outsourced. Just not your core product.

If all you want is an initial mockup of a product, or a proof-of-concept, in which the development is a matter of a few weeks time – then, by all means, outsource it. Don’t hire a technical team when you’re just demoing a product, or in general – when you know you’re going to throw it away. As long as this demo / proof-of-concept is not going to be extended into a real product, do it. Find the cheapest company that will deliver according to your screenshots or sketches. That mockup won’t have a database and real users, so there’s no privacy, security or performance issue. It doesn’t need to be maintained. It likely doesn’t have to support all device resolutions.

Do it quickly, and cheaply, prove that your product/site is viable – then throw it away, get a technical co-founder or a technical team and develop the real thing in-house.

Other types of things you could outsource are small and isolated units of code / mini-projects.

These could be satellite modules or collaterals (not to be confused with microservices, which are mainly part of your core product). These modules usually belong to the back-end; they have a clear start and end, are well defined, and do not disrupt your main product by lack of delivery, security, performance or quality.

The outcome of such a module should be clearly measurable without prior knowledge of the existing codebase, and – you still need a technical person on your behalf to supervise the delivery of the module, though.

The greater the project, the greater the expertise your technical person would need and the supervision they will have to apply on the outsourcing company.

Summary

Too many things can go south when you outsource your core app/site. The same is true for non-core functionality, by the way, as long as it’s “big enough” of a task (more than a few weeks).

Hire developers, or get a co-founder. Don’t just assume that outsourcing would make things cheaper, or quicker, or save you from giving away precious equity.

If you do choose to outsource, you should still get a highly-skilled technical person on your side, who knows what to require and how to tightly supervise the outsourcing company and validate their outcomes.

I have a lot to say about outsourcing and supervising outsource development, especially offshore, which I’ll save for the next post. It’s really something that should be done with care and with full control over the process. Subscribe to my newsletter to get an update when that post will be published.