When to build, when to buy, and when to staff

There’s no right or wrong way to develop an app. No two apps are the same and neither are the people who develop them. While it’s always great to have a team of developers who can wear a lot of hats, the easiest way to keep your development team lean and agile is to staff for the core features that make your app stand out. 

But whether you’re making a CRM or a CMS, a logistics management software or an inventory tracker, there’s no doubt you’ll encounter a situation where your users are demanding functionality that is outside of your team’s core capabilities. Adding new quality of life features is a great way to increase your product stickiness and delight your customers at the same time. But when deciding to do this, you’ll have to make a tough decision: do you build using the team you have, staff to fill the gaps, or buy a third party solution? So what is the right choice for your team?

1. Build using your current team

At first glance, doing the work in house with your existing team makes the most sense. The approach, affectionately known as “dogfooding” by many developers, is often brought up as the low cost approach to adding new functionality to your software. On paper this is true: you’re already paying your team, they already know your platform and how to iterate upon it.

But in reality that can be far from the truth. For one thing, take into account that your team was purposely built to develop on your app’s core functionality. While they’re no doubt the best, they are still only the best at what you hired them to specialize in, and any functionality outside of that wheelhouse could provide an unnecessary challenge. To put it another way: if you’ve hired a group of champion sprinters, don’t be surprised if they start stumbling when you ask them to jump over hurdles.

What this means for you is that you’ll have to allow your team the time and space to get themselves acquainted with unfamiliar processes, codebases, or techniques. That means diverting them away from iterating upon and supporting your core features. You may be saving additional overhead, but you’ll have to think about how you’re investing your team’s time. Remember: the goal of adding these features is to delight your customers, but that can’t come at the expense of key features. If your organization can’t accommodate the delays involved in building something outside your core functionality, it’s probably best to start exploring other options.

2. Staff for the new functionality

The next best option is to expand your team, either permanently or temporarily, to include people who specialize in the features you plan to add. One immediate benefit is that it allows the team you’ve already built to keep focusing on what they do best. It also means you have the opportunity to find the perfect person or people to build the new features on time and on schedule. Of course: you have to find them first.

Staffing is hard. No matter your organization’s size and reputation, it takes time and energy to find and vet the right candidate before you hire them. If the position is temporary, this can become even more difficult, as you will have to find someone who is willing and able to take on work on a project basis, which can be even harder to come by in periods of economic instability. 

There’s also another issue to consider: in-demand features usually mean in-demand candidates. Odds are that if you’re looking to add a set of features, your competitors are too. In order to get the best people, you’ll have to be willing to make the best offer. But even with the increased overhead there are other important factors: new team members means onboarding, ramp-up time, and potentially shake-ups to your company’s culture, all of which can create significant delays.

3. Buy the functionality you need

In my experience working in tech, making the suggestion to license or subscribe to third party functionality is usually met with a number of complaints. First and foremost is cost: why pay for something we could build ourselves? As I’ve outlined above, this is a logical fallacy: whether you divert your existing resources or you add more resources, new functionality will always come at the cost of both time and money. There’s no way around this.

But what many people don’t realize is that today most in-app APIs are priced in such a way that they’re cheaper than an in-house solution, to say nothing of the time saved on building, testing, and deploying the functionality. When buying a feature, you’re essentially buying the collective experience, expertise, and support of the team who built it, all at a fraction of the cost of hiring those developers yourself.

Buying functionality through an API provider allows you to implement the features your customers are demanding while letting your team focus on the features and functionality that made your app great in the first place. Even at enterprise prices, in-app APIs can provide a low cost, low time investment alternative to building in-house.

At the end of the day, your two goals are to keep your customers engaged and your team happy. This is a delicate balance and things like product roadmap delays or new hires can upset the balance, especially in lean organizations. In-app APIs such as chat api, files api, feeds api or others can help you achieve the goal of delighting customers quickly and easily by integrating a mature feature set into your application. In the end this can also be the easiest way of achieving the other goal because it lets your team focus on doing what they do best: developing the features that made your app great in the first place