The Same Old, Brand-New Argument: All-In-One or Best-Of-Breed?

Introduction

For at least the past twenty years, IT folks have been faced with the same basic problem when choosing whether and which products to adopt. The term “Best of Breed” is commonly used to talk about products that offer high quality in a narrow set of features. “All in One” products, on the other hand, combine features that may cross business process or technical boundaries.

Different vendors have very different views on whether customers need a bunch of features integrated in a single product, or whether they would rather manage a set for more focused products that they (or someone else) can stitch together.

What’s the right way to go? The answer is, of course, “it depends” — and while this may be accurate, it’s not very helpful without some practical criteria to apply.

The Trade-Offs

Learn To Let Go

First things first — as a customer, buying someone else’s product means buying into their approach, their decisions, and their limitations. You’re almost certainly not going to get *exactly* what you want. Then again, you won’t be building and maintaining your own code, spending money on adding features, and your development staff can be off chasing your *real* business goals.

Look at the Big Picture

Another big trade-off involves the *rest* of your business technology. How does your current need fit in with the rest of your business systems? If you can cover more business requirements with one product, it means fewer integration points. If your requirements are very complex or specific, it might be worth the extra dependency to go after a best-of-breed tool in a given area.

Watch the Uptime

Lastly, consider outages and support. It’s inevitable that you’ll depend on your vendor(s) to come through for you when something goes wrong. Make sure you have a well-defined level of service with each vendor.

Outages can and will occur, and they affect your business continuity. Having a set of smaller, independent services from different vendors might seem like a good hedge against downtime, but in reality more moving parts *always* means a higher chance of failure. If four out of five systems are up, it doesn’t mean you have 80% functionality — interdependency usually drives that number down pretty quickly as you add components.

What’s Right for You?

With those trade-offs in mind, let’s go through a few questions that you can apply to your own situation, to help identify where you might find the most value:

1. How Big (Small) Is Your Scope?

If your needs are pretty narrow (e.g., file storage, web analytics, payment processing), then it’s likely to be well-covered by a best-in-breed solution. If you need lots of features, or a lot of complexity within them (think workflow, document management, billing or accounting), then an integrated option will offer less difficulty to get up and running, even if it has some limitations you don’t love.

2. How Much DIY Can You Handle?

This one is pretty simple — the more pieces you add to your quilt, the more stitching you’ll need to do. For example, you’ll need to keep your list of customers updated between CRM and project management, or maybe get build status in your work chat.

Nowadays, it’s very typical for applications to offer an API right out of the box. It’s also pretty common to have some integrations baked into tools — fill in a field or two, check the “Enabled” box and it’s connected. But the ease of initial adoption can misrepresent the ongoing costs to keep things the way you want them. Here are some examples:

  • Documented APIs are typically stable and reliable, but your custom integration with an API can become fragile over time, as your needs become more complex.
  • Built-in integrations provided between vendors (especially “web hook” type integrations) are always vulnerable to compatibility issues between the vendors, as they add (and retire) features over time.
  • Troubleshooting problems between multiple vendors is not for the faint-of-heart — you will often find yourself stuck in the middle, trying to prove that you have a problem they can solve.

If you’re a completely bootstrapped startup, where you have more time than money, it might make sense to invest that time into getting the tools you want tied together. As your organization grows, however, the balance between time and money often changes, and you’ll need to re-evaluate some of those early decisions.

3. Who Are You Getting Involved With?

Regardless of which way you go, you’ll want to know some things about your vendor(s) before you sign on. Here are a few starters:

  • First and foremost, are they going to disappear one random evening, with all your data?
  • How long have they been around?
  • How do they deal with customers during the sales cycle? The support cycle?
  • Do they solicit/accept/ignore requests from their customer base? Are they responsive to requests?
  • What levels of support (free or paid) are available? Do they promise a specific level of service?
  • Do you know anyone else who is a customer? What do they think?

Depending on your size and level of formality, these questions may become much more important. Newer, smaller, bootstrapped companies may care a lot more about what they can get now, and less about who’s answering the phone at 3AM. Organizations that have to answer to customers, boards of directors, investors or regulatory authorities might have an entirely different view. Uptime becomes much more important once you have paying customers, and people relying on your services.

4. What Will You Need Next Year? In Three Years?

If you’re a new company, patronizing another new company can seem like a great idea. Finding a focused vendor to partner and grow with can be a great fringe benefit — unless they go out of business or pivot away from what you need. Regardless of how good a relationship is at the beginning, it’s important to keep in mind how you’ll get out if and when it’s time to move on.

Some services are easier to change than others, like payment processing or CDN — you can even use two vendors concurrently and make a soft switchover. For other tools, like bug tracking, CRM, or internal tooling (e.g., database, message queue, web platform), changing vendors can take time, attention and planning away from your more strategic goals. All of those distractions cost opportunities, sales, and revenue.

But that’s not even the worst-case scenario. Instead, many teams will continue using tools that don’t support them strategically, struggling along with more and more string and duct tape around a core that is no longer suited to them. This is a quiet, passive killer of your team’s momentum and ability to innovate — especially if certain tools or systems become off-limits for discussions about improvement.

In general, I try to buy software and services the way that parents buy clothes for their kids. Sure, they’re a little too big at first, but if you choose wisely, you’ll find something you can grow into. Maybe even something you never outgrow.

If you’re looking for a task/code/team collaboration tool that you’ll never outgrow, come check out GForge Next: https://next.gforge.com