Build vs buy: a guide for command palette service

👋 We’re Magny. We help companies build command palettes to deliver better search functionality in their apps to help them increase user retention, understand the best features and optimize the user experience.

Deciding whether to build a service in-house or use third-party APIs and SDKs is a decision that engineering and product teams face on a regular basis. Command palette and search systems are no different.

The goal of this post is to give teams a framework for evaluating whether to build their command palette or buy a solution from a third-party vendor.

At the end of this post you’ll understand:

• Challenges faced by teams evaluating whether to build or buy a command palette
• What command palette services look like
• How to use a framework to assess any build vs buy decision
• How to apply that framework against the build decision for a command palette

Command palettes start simple, but ramp in complexity fast

Command palettes start simple. When you connect your service to an open source command palette, you would think it is easy enough. However, the complexity starts when:

• You try to maintain the current list of commands with the help of the DevOps team.
• You add routes to your application (e.g a command should be able to trigger an action on another page).
• You want to start indexing your help docs and want to search in them, which may not be available in an open source project.
• You need consultancy on how command palette will improve the user experience.

Here are a few of the challenges we see customers face as they add commands to their command bar:

• Total cost of ownership. As a product evolves it adds new features, and with those features come new commands and categories. As organizations add new features such as 3rd party integrations, work on a staging and production server and try to add features that are not available in an open source project, they see the total cost of ownership of their command palette ramp as they have to manage several features.
• Building command palette expertise. With each new command, the product manager uses a new world of documentation, SDKs, and platform-specific experience to learn. When there’s core product to build, the last thing teams want to spend time on is to try to learn a different open source library and try to match it with their existing stack.
• Maintain visibility across the rest of the team. As organizations grow, they find a larger group of stakeholders need visibility into the command palette, whether that’s product managers looking to update the command palette template copy, or support team members looking to understand why a command palette entry doesn't work. Without a dashboard, analytics and debug logs to manage this process, engineers are left servicing these stakeholders instead of spending time on the core product.
• Compliance. Maintaining audit logs of all updates made to the command palette as well as historical records of all messages sent for compliance purposes. Open source command palette services need to be connected to 3rd parties hence the additional work.

The companies that built these internal tools for managing command palettes dedicated engineering teams for both the initial build and ongoing maintenance of these command palettes.

In the past, if you were an organization that didn’t have the headcount to build and manage a command palette system in-house, you were left cutting corners and shipping a low visibility system that was hard to scale.

The good news is today you have an option you can use that provides all of the functionality of a command palette (drag-drop interface, analytics, notifications, out-of-the-box feature set), without needing to design, test, build, and scale the entire system in-house.

A framework for build-vs-buy decision of command palettes

When we’re evaluating any build vs. buy decision internally at Magny, we evaluate it using the factors below.

• Differentiation. Do we gain a unique differentiator for our product by investing time in learning how to build a best-in-class version of a command palette service?
• Correctness and flexibility. How well does this service represent the requirements we need to solve for? How well does it represent the requirements we’ll need to solve for in the future?
• Development time. How much development time do we save by using a third-party to run this service? How much faster can we achieve our roadmap goals by building vs. buying a command palette service?
• Maintainability. How easy is it to maintain this service? Is this easier or harder if we use a 3rd-party vendor?

In the past, we have used this framework and it’s helped us to understand when we want to build in-house and when we’re comfortable using a third-party vendor.

Differentiation

Unless you're building a SaaS product where a very basic command palette (e.g non-dynamic recommendations, accessing menus or providing static training for your users, you’re probably not gaining a unique differentiator for your business when you’re building a command palette system in-house.

Another way to think about this: will your team gain leverage on the time they spend learning how to build a complete recommendation service, provide user training, help users understand and absorb the best features and integrate with help docs?

In most cases we see at Magny, the answer to this question is no, which makes command palette systems a good candidate for outsourcing via a third-party solution.

Development time

At a high-level, the development time analysis is straightforward. If you’re building a command palette system in-house, it’s going to take longer than if you’d decided to use a third-party solution.

What’s harder to understand at the outset of a command palette system project is just how long it can take to build the different parts of that system and what unplanned work will pop up along the way.

Here’s an overview of the inputs that go into a command palette platform build.

• You would want to use a command palette library for this purpose, e.g cmdk, Kbar or Kmenu. Some of the best libraries are headless, i.e you have to apply CSS and build a skin around. When your app's theme changes, those modifications may need to be applied to the library as well.
• A command palette service requires analytics where you need to know search terms and deadends (command searched but not found), number of times the command palette is initialized. This requires an analytics dashboard, needs to be checked by the product manager.
• A proper audit and debug log service needs to be in place during and after the development.

Additionally, a dashboard for entering and update commands as the software evolves, debugging them, and evaluating their effectiveness is required. Without this, you’ll be left with a black box powering your user engagement that takes time from engineers when command palette updates are required.

Each team moves at a different pace and works with a varied set of requirements when building an in-house command palette service, but from our personal experience and based on what we’ve seen from customers, a dedicated team of 3 engineers can spend at least 5 months on a basic command palette service.

This estimate can float up towards 6-7 months as you start to factor in unexpected and evolving scope and additional tooling for the internal team.

Magny: A command palette for SaaS products

Magny is a navigation, universal search and helper for apps in order to help users understand and onboard easier, faster and in a convenient manner. This way it helps users to learn your apps faster and in an effective manner.

Magny is in production use today in small and medium SaaS businesses around the world.

We provide a set of features that developers and product managers use to:

✅ Make your dashboard super easy to navigate

✅ Enable users search your dashboard in a universal manner

✅ Help users understand and absorb the best features

✅ Make recommendations and optimize the user experience

✅ Teach users how to get the best out of your app

Making the decision

If you decide to build your command palette service in-house, we’d love to hear from you at hello@magny.io on what we can do to make our product a better option for other teams evaluating this decision in the future.

If you’re interested in trying out Magny command palette, you can get started on the Magny Starter plan for free, forever.