It’s a time-tested question, raised in the halls of companies of all sizes: when faced with a problem, should we build a solution to address it, or should we buy one? In today’s fast-paced technology environment, it’s important to carefully weigh the pros and cons of each approach against your organizational strategy.

To help you understand which option is right for your brand, let’s take a look at some of the considerations, tradeoffs, and tough questions you should evaluate when making this decision.

When is it right to build?

There are a few good reasons an organization might want to build a custom solution.

Exactly what you need–no more, no less. Sometimes, tools that are designed to meet the needs of most aren’t quite a perfect fit for what your company needs. For highly-custom or exceedingly complex needs, a purpose-built solution can be just the ticket.

Complete control over its future. You built it, so you and your team control its destiny. Want a new feature added? Just ante up the developer time and it’s as good as yours.

What costs are incurred with a custom solution?

There is no free lunch – building a custom solution will have some costs, which you should definitely consider as you make this decision.

Direct costs

1. Engineering time. Your engineering team, or a subcontractor, will have to write some code.
2. QA. You’ve got to make sure everything works properly, and that’ll take some time–both yours and your engineers’.

Indirect costs

1. Technology Debt. Your team is responsible for maintaining the custom solution, meaning that if it needs change or the outside environment evolves, it will cost several development cycles to get back to normal. And that can only mean more of your team’s time and more of your company’s dollars.
2. Engineering opportunity cost. It’s the classic cost-benefit analysis. If your engineering team is building a custom tool, that likely means they’re not working on other projects that could be driving your business forward.
3. Time to utility. Software development takes time. And the more complex the tool you’re building, the more time it will take. A custom solution might not be ready when you need it.

How can we put some criteria around the decision?

A framework for assessing build vs. buy

The tradeoffs become a business decision, one which should align with your organizational strategy. Pro tip: Whenever you make these assessments, consider avoiding feature checklists: any vendor can check a capability box, but it’s how they do so that’s most important.

1. List your strategic business goals. What problems are you trying to solve, as a business?
2. Design some tactics to help you get there. Taking a tactical approach next lets you define criteria to evaluate potential vendor solutions, or requirements for your internal build.
3. Evaluate market capabilities. Your strategic goals and the tactics you use to accomplish them should serve as a clear set of use cases against you can use to evaluate tools in the market.

Let’s say you’ve decided to invest. What questions should you ask potential vendors to future-proof that investment? As you’re evaluating technology solutions to your challenge, keep them accountable for these questions:

1. Will the solution let us make substantial progress towards solving the challenge?
   It may not be exactly what you’re looking for, but if it will get you most of the way there, it’s often still the right choice.
2. Is the solution flexible enough to meet present and future needs?
   The world is diverse and constantly evolving. As your needs change, is the solution designed for flexibility, increasing the odds it will stay relevant? Does the solution’s release history reflect a focus on maintaining market-leading support?
3. How easily does the solution accomplish your use cases?
   All the flexibility in the world means nothing if you and your team have to move mountains to take advantage of it. Make your vendors show you, rather than tell you, that their tools can accomplish your use cases.
4. How well does the solution fit into your technology stack?
   Look for things like publicly-available API documentation. Ask how many platform functions are exposed via the API, and what data is accessible. Your data should belong to you, regardless of platform choice.

At Appboy, we believe your valuable engineering time is best spent improving your product. We’ve built a platform worthy of your investment: it’s polished, capable, and easy-to-use, reducing your marketers’ dependence on engineering time. And, since engineering and marketing work better together, we stocked it with powerful capabilities like Webhooks and Connected Content to amplify and contribute to your technology stack.