🥊 Competing against internally developed tools

This article was originally published on Medium.

For many products, their main competitor isn’t another company but an internally-developed tool. This is particularly true of developer tools, and I have a theory that this will only get more challenging as AI reduces the time and effort required to build viable solutions internally.

Looking back to my time as an engineer, I helped develop and maintain many tools in-house including:

At the time, most of these weren’t yet available off the shelf, let alone something people were paying money for. Seeing what’s available today, I often think “wow, I wish this had existed when I was an engineer, that would have saved me so much time!”. But getting developers to pay for things they used to build can still be a challenge.

Internal development is a huge source of innovation and can lead to new products or even new markets in their own right. In fact, many of the startups boldstart works with came about when founders built, maintained, or desired tools that weren’t available on the market, or didn’t operate at the scale that was needed to adapt to modern development practices. The “buy” option wasn’t available, so they built.

Etsy’s internally developed Deployinator was built in 2010 almost 5 years before one-click deploy tools like Netlify were a thing. The origins of Slack were as a tool called Tiny Speck, built within a games company back in 2011 to help them collaborate internally. And in 2020, Spotify’s engineering team open sourced a tool they built in a hack week called Backstage, creating a new market in developer portals which products like Roadie have been building upon to extend its capabilities.

Even when solutions and funding are available, in-house development of tools is still big, with Meta building their own SCM called Sapling, their own build tool called Buck, and of course their own JavaScript framework, React.

The key to selling a product to teams that have already got an equivalent tool in-house is to understand the team, that tool, and the processes around it.

In my days as a product manager, if I knew we were competing against an internal tool, I’d ask the teams we were talking to for a demo. More often than not they were happy to do this. I asked them what they liked most about it and what they liked least. I’d find out who the maintainers were and talk to them to understand whether this was a project they felt invested in, or if it was starting to feel more like a burden.

When comparing our solution to theirs, I tried to be honest about the gaps because I knew that in a lot of cases, their tool might have features they don’t really care about carrying over.

In-house solutions are a source of inspiration for new features, so in some cases, I’d learn about features that felt like a great fit for our product and were aligned with its direction. I’d let the team know that we’d consider building these in — but we’d do this only if we believed it would benefit other existing and potential customers.

Being curious not only helps make your product better, but it also helps strengthen a relationship with a potential customer. Those relationships are important. Even if you’re not able to make a sale, you can nurture a design partnership to get strong signals on your product’s direction. Just make sure you’ve got enough of those signals so you’re building a well-rounded product with use cases that aren’t specific to a single company.

To help build the best case for your product, it’s important to understand a company’s resistance to purchasing the tool over developing or continuing to maintain a solution in-house.

Let’s take the example of a feature flag product and imagine we’re trying to introduce a team to that. We’ll identify some reasons teams will justify building this in-house, and then attempt to counter those arguments.

One of the challenges with selling to developers is that some solutions appear so simple that engineers take it as a challenge to build the same thing in-house. A feature flag product is a good example of this — to an outside observer, it’s essentially a boolean that runs more code if a condition is true.

Now let’s fast-forward to when the company and codebase has scaled. The home-grown solution might have worked well for some basic features, but the product team wants to do more feature experimentation and is starting to get frustrated by its limitations. Enabling a feature flag requires a manual deployment, and there are now so many feature flags it’s getting hard to manage. Every team uses a different naming convention, and it’s hard to know which are safe to enable for certain customers and which aren’t.

So while a solution can appear simple, dig a little deeper and there are all sorts of technological and human challenges that haven’t yet been considered. A compelling argument to make is that the engineers of the in-house tool will be thinking about this problem between tasks, whereas the team building the feature flag product will be living and breathing this problem, and will have a much greater understanding of how to solve it. So while the solution may appear simple to start with, it’s not until the engineers are knee-deep in building it that the real complexity is revealed.

Building something in-house is often an economical decision — it’s free, right? And sometimes, it can take longer to get the budget approved for an additional line item in Engineering’s budget than it would take to actually build the thing!

In his post “Making the wrong choice on build vs buy”, Isaac Seymour makes the point that “Building an internal system is very rarely going to be anywhere near as valuable as delivering the product your company is actually selling” after trying to build a better version of the expenses software his company was using. What started as a fun side project became something that sapped away his time, and diverted his energy away from solving more important problems.

This makes a useful line of argument — an engineering team’s measure of success is likely be around speed and quality of delivery, and specifically, delivery of things that directly relate to the product they’re building. Engineering managers will want their teams to be focussing on things that relate to the success of the business — which is unlikely to cover building and maintaining tooling that already exists and isn’t related to the bottom line.

So while building in-house might keep a company’s expenses lean, that will come at the cost of future productivity and efficiency. As part of their sales pitch, many companies will help potential customers do the maths to calculate how much their in-house tool “costs” them to build and maintain in engineering time, and compare this to the (usually much lower) product’s subscription fee.

One of the benefits of building a tool in-house is that the team will have complete control over how it works. They’ll be able to fit it into their weird and wonderful workflows and processes rather than have to adapt to new ones.

Security and compliance tools have an easier job of selling here — flexibility can be a downside when an industry-regulated process has to be followed. This is why engineers these days are rarely tasked with building their own authentication or payment gateways.

For everything else, flexibility can actually become a burden. In-house tools often lack proper documentation or onboarding. They’re often maintained by a small number of individuals, or even just a single person — so if that person leaves, it becomes even harder to keep running. Adding new capabilities and integrations with other tools can require shifting someone off a project.

Also consider that in-house tooling can be an attack vector, and often lack features that would be useful in the event of a breach, such as monitoring and audit logs. Asking what the plan is for this is a good way to prompt the potential customer on whether this is something the team have thought through.

All of this isn’t to argue that teams should never build in house. There’s a lot of value in going for something simple until it’s painful. You’d hope that teams will be ready to migrate when that pain really starts to bite, but for many reasons, they might just not be ready yet.

The pain just might not be big enough to justify switching over, or the alternative product’s pricing too high for the scale the company is at. Or if they’re early in their journey, they might just need to go through the process of sticking beans up their noses first. See these as future opportunities, and be there and ready for them when they are.

There are risks in shifting people off their tooling before they’re ready — in fact, there’s a whole other conversation to be had around ensuring successful migration, but that deserves its own post.