Share
Explore
Introduction
The decision to buy or build software is complex, with factors such as opportunity costs, prioritization, and consensus building. Coda often discusses this with potential customers, evaluating their unique needs to determine if their flexible platform is the right fit. Six critical questions guide this process: identifying needs, assessing time to launch, considering upfront and ongoing costs, evaluating team commitment, maintaining honesty about capabilities, and deciding on the best course of action. Coda themselves often choose to buy tools like Figma despite having capable engineers, recognizing their limits. They encourage customers to use these questions to guide their decisions, offering Coda as a powerful hybrid solution for both buying and building needs.
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 doesn’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:
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?
One important financial consideration for companies choosing to build their own tools is the . Many governments offer tax incentives for businesses investing in research and development, including software and tool creation.
If your project qualifies, you may be able to recover a significant portion of development costs, making in-house development a more viable option. Factoring in these potential tax benefits can shift the cost-benefit analysis in favor of building rather than buying.
“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.
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.
Want to print your doc?
This is not the way.
This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
CtrlP
) instead.