Buy or build your next tool? A quick guide.

6 key questions that will help you decide.

Coda team

Buy or build your next tool? A quick guide.

By Coda team

Share this article

Share on TwitterShare on LinkedInShare on Facebook
Tool consolidation · 6 min read
Questions we'll cover
  • What are your needs?
  • When does it need to go live?
  • What are the upfront costs?
  • What are the ongoing maintenance costs if you build?
  • What are the incentives in your organization?
  • Are you being (brutally) honest with yourself?
Few scenarios in software force thoughtfulness like a hard decision about whether to buy a tool or build it in-house. Infinite time / money and perfect internal alignment would make things easy, but reality is opportunity costs, prioritization and consensus building. This does’t mean you have to sacrifice quality, but it does mean you need to clarify what you want your company to be really good at. At Coda this question will sometimes come up with potential customers, “Couldn’t we build something similar that fits our needs specifically?” It’s an investigation we welcome because it allows us to broach a topic we think is vital to every new tool consideration—though we like to think Coda is much more than “just” a tool. We also appreciate the prompt because it helps us evaluate customer’s needs. While Coda is extremely flexible, maybe there is a scenario where building is better. We genuinely want Makers to succeed, so if something isn’t a fit, we’ll let you know. As a consequence of all the conversations we’ve been a part of that center on the buy vs build “debate” (we think of it as less of a debate than matching goals and capabilities), we decided to compile six critical questions we think people should consider when they’re going through their process.

Frame your decision.

 Once you answer the following set of questions you will hopefully have a much clearer picture of your best course of action.

What are your needs?

 The critical first step and where we think every organization should start. Firmly establishing your company’s unique pain points and goals can act as a home base where you can return for guidance as you go through the rest of the process. If you’re considering Coda for example, you might be interested in faster execution through automation of certain tasks, building a single source of truth or creating more efficient team processes that reduce duplication work. The key is making sure you clearly identify your needs so you can see which option best meets them.

When does it need to go live?

 Is this something required within days, week, months, or even years? If considering a third party, what’s their dedication to getting you up and running to meet that timeframe? Things to consider for building:
  • Incorrect estimations: This can be an issue especially in cases where you’re building in unfamiliar territory.
  • Outside events you can’t control: You can do your best to plan, but if something like a reorg hits, it can blow up your team’s entire process.
  • Internal churn: Whereas third parties will have redundancies, internal builds are sometimes run by a small subset of people (or even a single person) who contain a lot of institutional knowledge. If they leave, it can throw off development, or if already launched, make the product difficult or even impossible to use. Scenarios we’ve had relayed to us more than a few times by customers.

What are the upfront costs?

 If you’re purchasing a new tool, financial cost is going to be one of the primary considerations, but resource costs should also be taken into account. Do you have the team members to build the tool or might you need to shuffle teams, or even hire new ones? What’s the consequence of pulling someone off a major project to do this? This can play into the timeframe question above.
“What started out as a very simple buildout, ended up becoming a very complex thing to maintain and engineers were not happy. They did not want to work on it, they did not want to continue to iterate and maintain this...we also went through a huge rebranding exercise which required months and months of updates to our assets when it could have been weeks if we had bought the email software.”

What are the ongoing maintenance costs if you build?

 You’ll need to sustain the resourcing costs if you choose to build your tool in-house. It’s easy to think, “Great! We built it; we’re all good.” But that’s never the case with any product. Heck, even a toaster needs cleaning every now and again. And what could that time / money have been spent on if that maintenance weren’t required? This is the most literal trade-off consideration, as both are finite—even for the richest companies—so it’s a necessary factor to take into account. Within the broader question lies another regarding focus. Does your team want to build and maintain this tool? Will they keep focus such that any necessary new features / support will get internal support? This example from Sushma Nallapeta about her time at Apartment List provides good insight into those types of scenarios. This plays into a question about incentives.

What are the incentives in your organization?

 At Coda, we’re strongly incentivized as a company to help our customers succeed, because when they do, so do we. Which means team members are rewarded internally for working towards that goal. At some companies, the goal should be to help customers, but employees only benefit when their boss looks good, regardless of the customer outcome. You’ll have to determine your company’s incentive structure because it will most likely dictate behavior. If you’re buying, is this a decision that will really address your needs or just make you look like you’re trying to fix problems? And in the build case, if team members aren’t rewarded in some fashion for maintaining it, it may mean the quality of work drops off. The shiny object syndrome may counter act this for a while, but eventually, incentives rule. Which is why find it necessarily to have a healthy amount of self-reflection.

Are you being (brutally) honest with yourself?

 We could do X, but will we? On the buy side it’s making sure you’re committed to the transition. Incorporating a new tool without buy-in ends up being a loss for everyone. And with the build option, there can be commitments of years of effort and millions of dollars spent, so it’s vital to ask if the team is setup to follow through. Or in the reverse scenario, if they’ll be able to kill a project if it becomes too complicated or costly. The latter can be a difficult situation because you’ve already set the course, but then realized, uh-oh, this isn’t what we expected. On a purely human level, this is where things can spiral as people become tied to their choices. Once you stated it’s going to happen, now it can feel like you “have” to deliver. Which could mean you end up spending time extremely frustrated by something that should’ve (and could’ve, if they’d used Coda) been a click of a button, but is now an overly complex task—a customer scenario recently communicated to us. Of course it’s impossible to tell the future, so we like to try and keep an aspirational pragmatist mindset here.

You have answers, now what?

 Teams within Coda have used a version of this set of questions dozens of times. In fact, it’s often why we end up buying. We have amazing engineers and designers, yet we use a tool like Figma because it’s light years away from anything we could build internally. In other words, we’re builders, and we’re really good ones, but we also know our limits and what we’re best at. There have been times when something is small and “cheap” both in dollars and people-hours that we decided to build. However, it’s almost always “built” in Coda and we’ve seen customers follow a similar hybrid approach, where they buy and build in Coda. Because it really is that powerful. As mentioned, we walk potential, and even current, customers through this mental exercise often, so if you’re wondering whether Coda is something that might help with your specific needs, we’re always here to dig in with you. Even outside of that, we just hope the questions above allow you to at least start the process, no matter what you’re looking to buy or build. But if you are using it to evaluate our solutions, we’ll be here!
Contact us

Related posts

Explore more stories about the tools you use.
Simplify your SaaS stack

Enterprise admins have control over their workspace.

4 unexpected ways to use Coda

Discover how Coda can help consolidate your tech stack.

Jira and Coda together

Teams connect Jira and Coda to better manage their work.