When Buying is Better Than Building:
Navigating a complex decision

Asking a developer if she wants to write code is like asking a surgeon if she wants to cut. When facing a build or buy decision for software, it’s best to strategically use developers for technical evaluation but not let them be the final arbiters. The build versus buy decision has only become more complicated over time and requires skill and thoughtfulness to prevent the process from becoming a Lernaean Hydra.

Before a team even approaches a build or buy decision, it’s important to agree upon the required functionality. Instead of cobbling together a spreadsheet of features with checkmarks next to the mandatory ones, a better approach borrows a page from product management. User Story Mapping is a pattern that breaks down a system into its constituent pieces and visualizes it as a physical map of cascading stories. As the User Story Mapping creator, Jeff Patton, explains, it differs from traditional “flat” user stories and backlogs in this way:

We spend lots of time working with our customers. We work hard to understand their goals, their users, and the major parts of the system we could build. Then we finally get down to the details — the pieces of functionality we’d like to build. In my head a see a tree where the trunk is built from the goals or desired benefits that drive the system; big branches are users; the small branches and twigs are the capabilities they need; then finally the leaves are the user stories small enough to place into development iterations.

After all that work, after establishing all that shared understanding I feel like we pull all the leaves off the tree and load them into a leaf bag — then cut down the tree.

That’s what a flat backlog is to me. A bag of context-free mulch.

After establishing what is needed, a team can start determining how to produce this functionality with a rubric like this:

1. Jim Collins’ Good to GreatHedgehog Concept (image above): Find the intersection between the core competencies of the team, the work’s cost-efficiency, and work’s fit into the company’s strategic roadmap. That small intersection in the Venn diagram is the stuff of in-house development; anything that falls outside isn’t necessarily a “buy,” but it demands scrutiny before building.
2. Opportunity Cost: If developers are working on this functionality, what work are they prevented from undertaking? If this solution is the highest priority, developers should focus on it. Otherwise, the decision isn’t so clear-cut.
3. Actual Cost: Sometimes the User Story Mapping yields a business-specific functionality set that suggests a bespoke solution. In cases like this, it’s less expensive to develop in-house from scratch instead of trying to retrofit an off-the-shelf product.*

*It warrants investigation if buying an off-the-shelf solution is impractical because of your company’s unique business needs. One of the benefits of buying a solution instead of building it in-house is standardization.If, for example, you can’t incorporate a payment system like Stripe because your payment requirements are unique, it’s time to question the wisdom of your process. Users’ experience will probably improve by changing your business practice to follow the same payment process that everyone else uses.

If the door is open to buying software, it’s best to assemble a small discovery team, representing the business and technical concerns and using this team to identify the options. This team typically takes the User Story Mapping and aligns it with multiple third-party offerings.

The “Buy” Options

Even in the simpler times of the 20th century, there were many flavors of build vs. buy. In today’s 21st century landscape, the options are even more plentiful and nuanced. Instead of a straightforward callout to a third-party tool, here are some of the “buy” options:

1. API Integration: This is the most common use case for purchased software. “Buying” is a euphemism for incorporating third-party software via an API. The in-house development team writes the code and builds the user interface. The technical people on the discovery team will evaluate the API for ease of use, functionality, flexibility, maturity, documentation, and support.
2. Outsourced API integration: The result is much the same as #1, but a third-party contractor, possibly the creators of the new functionality, builds the integration and/or the user interface.
3. Acquisition: Okay, the desired functionality isn’t in a company’s wheelhouse, but it’s strategically important. The fastest way for a well-heeled company to go to market is to acquire talent and products rather than train an in-house team.
4. White Label Integration: Under the covers, it’s a call out to a third-party product and navigation to a third-party user interface. The styling makes it appear to be part of a single piece of branded software.
5. Co-branded Solution: This is a callout directly to a vendor’s functionality and user interface. Although this one may be the least aesthetically palatable, it’s also the fastest way to market.

Congratulations on making a decision. It can be tricky to determine the best course – making the decision one way or the other is an important first step.

Choosing a Vendor

If you’re choosing to buy, the next challenge is finding vendors whose products are the right fit. It’s easy enough to assess vendors and determine the few that best match your needs.

Schedule meetings with the top contenders. Bring your discovery team representing product and engineering to the meeting so that most questions can be asked and, hopefully, answered on the spot.

Here are some things to watch for from vendors in these meetings:

1. Who do they bring? A full-court press from just a salesperson without technical representation may signify a couple of things: The salesperson may be a technically accomplished switch-hitter who can answer both business and technical questions. If not, by neglecting to provide technical representation, the company may be too large to care sufficiently about your potential business.
2. What do they offer? Third-party integrations are never a Cinderella fit. That’s a fairy tale. Some vendors may be willing to build the customizations you require. If so, question carefully: Will you build this as a one-off for us, or will addressing our needs also move you forward strategically? Ideally, it’s the latter. The dangers of a vendor building a one-off solution are future support and maintenance challenges.
3. Are they transparent? Unless the vendor is a competitor, they should be willing to expose their product roadmap and explain where your needs fall on their schedule. Similarly, there’s little risk of sharing your own roadmap with these vendors; in general, companies are too paranoid about competitors stealing ideas. Talk and ideas are cheap — it’s the execution that matters.
4. Are they willing to let you take an unsupervised test drive? Most of us have experienced overbearing car salespeople who insist on accompanying us on test drives. In today’s cloud hosting milieu, providing an unsupervised test account costs vendors almost nothing. View a refusal of a test account with suspicion.
5. Is it a cultural fit? It can be difficult to assess culture and fit during an initial meeting. Pay attention to the respect the people on the other side of the table show one another. It’s a red flag if a salesperson agrees to customizations and provides a level of effort estimate without first consulting the development team.

Kicking the Tires — Taking a Test Drive

At this point, the Product Management side of the discovery team has identified a third-party product that’s a reasonably good functionality fit. Now, it’s up to the technical team to dig in and kick the tires. This test drive is mostly an API evaluation to determine the ease of integration. A company may choose to outsource this API evaluation to a knowledgeable consultant or take the time to do it themselves.

Here are a handful of tips for API evaluation:

1. Completeness. All application functionality should have API buildout. Sometimes, when an API is built as an afterthought, there are pieces of UI functionality in the core product that remain unrepresented in the API.
2. Documentation. It’s not good enough to throw Swagger at an API and declare victory. Clear and comprehensive documentation is essential because this is how your development team will interact with the product. The documentation should include useful examples, “try it now” functionality, well-defined error handling, explanation of limitations, and sensible versioning.
3. Ease of Integration. Ideally, the API has code wrappers in your language (Ruby, JavaScript, etc.) that provide code snippet examples that you can use for the integration.
4. Test Environment. The vendor must provide a test environment so that you’re not hitting against production while you develop. This is the only way to ensure that you will run fully automated integration tests as part of your deployment pipeline.
5. Support. There may be times when a developer requires some clarification, especially if there are deficiencies in the documentation. Are developer requests quickly answered by knowledgeable people or are calls triaged through a help desk that doesn’t understand the API?

It takes discipline to stick with strategic goals and resist the seductive murmurs of developers itching to write code.