Question

Build vs. Buy: How do you decide which tools to build in-house versus when to buy pre-made software?

Does your team have a process to decide when to build or buy internal tools?

Or do you split the middle and try to build things with low-code tools and automations to get the best of both worlds?

Would be awesome to hear examples of tools your team needed and how you decided to build or buy—and what tool you ended up using in the end.

Share
aspec00's avatar
a year ago

My process is simple: is what you're building a core competency of your business? If the answer is yes - build it yourself. If the answer is no, buy premade software or even outsource the work (with a lot of oversight by your team).
There are so many fantastic point solution tools out today. Spend a day trying them all out. That day of research is well worth it compared to the weeks of headaches of trying to recreate the wheel.

4 points
AnujAdhiya's avatar
@AnujAdhiya (replying to @aspec00 )
a year ago

Cannot agree more with this. Don't build when someone's already solved the problem. Spend your resources on your own product.

1 point
adamtait's avatar
a year ago

I really like Basecamp's ShapeUp process (https://basecamp.com/shapeup) for making decisions related to engineering effort. They would say that you & your team should consider the problem/need for a tool and the appetite for fixing the problem or filling the need. Appetite means "how badly do we want this?" and try to quantify the desire with "how much engineering time are we willing to devote to this right now?". Your team's appetite should help point towards one of the proposed solutions; if you need a tool quickly but the team doesn't have the appetite to devote the time needed to build it then you look at alternatives. Maybe you can build something simpler that covers 80% of problem/needs or maybe you can find a 3rd-party tool that solves the problem.
Other commenters have mentioned the long-term maintenance/management cost of building your own software. I think it's difficult to estimate the long term maintenance cost of software and easy to under-estimate the cost of using 3rd-party software. When someone else owns your software tools, you must go through them to get changes/updates and precludes you from optimizing the tool for you particular use. Of course, that pain may only matter if you're really big (this is why big tech builds nearly everything in house) so smaller companies with fewer available developer hours have a different calculus that favors quick pre-packaged solutions.
There may be other factors/costs/pains to be considered with your team before choosing a solution. For example, maybe using a 3rd-party tool would require sharing sensitive data outside your corporate ownership.
As you've discovered, the process for making the decision is important. It's also unique to every company, every team and every problem/need looking for a solution. I like Basecamp's ShapeUp process which looks like:
+ describe the problem/need in as much detail as you have
+ consider the appetite to find a solution
+ consider solutions to all or part of the problem/need given the appetite
+ propose the solution to all stakeholders together

4 points
maguay's avatar
@maguay (replying to @adamtait )
a year ago

Thanks for sharing; the Basecamp team has published an incredible number of resources that are always deeply thoughtful. Loved their examples of how they roughly sketch ideas for Basecamp then iterate through shipping.

Integrations and such can mitigate the pain of waiting on 3rd party vendors for updates, though only to a degree.

Sounds like your team typically would prefer to build in-house tools once you've decided on what the best ideal tool would look like?

1 point
adamtait's avatar
@adamtait (replying to @maguay )
a year ago

We are a small team with limited time to work on new tools (low appetite) so often the calculus works in favor of third party tools that we can integrate and maintain with our limited appetite. That said, our appetite (just partly based on the size of our team) is only one factor in the choice, and every choice is different.
My best advice is to thoughtfully consider the choice, review all factors and discounted timeframes, then get buy-in for the decision with plans to review again when the trade-off change.

3 points
MikeRaia's avatar
a year ago

Disclosure: I market a low-code app platform. However, I'm not pitching our software, just some agnostic concepts here.

We wrote a post about this a while back since we kept running into this question with customers. Often we're competing not against a competitor but against the idea of building something internally. If you have talented developers who are willing to support the application and a very specific app need it might make sense to build it from scratch. But there are a lot of caveats. Here's the post if you're interested: https://www.integrify.com/blog/posts/the-temptation-and-the-trap-of-homegrown-systems/

If you're going to build something though, I wouldn't do it from scratch. Low-code tools make the most sense at this point for stressed DevOps and IT teams. Most things you'd want to build can be built much more quickly using workflow, database, report gen, etc. tools and can be adapted across the company for other use cases. Plus most are designed to integrate easily with existing systems, saving a lot of time.

Lastly, if you have technically-proficient business users, they may be able to build their own solutions (I still like the term "Citizen Developers") and support them.

2 points
maguay's avatar
@maguay (replying to @MikeRaia )
a year ago

Great point. It feels like there are several tiers now, essentially to map out the MVP process for internal needs:

  • Use off-the-shelf stuff, especially if free
  • Customize it as much as possible
  • Use integrations/automation tools with other apps to add features you need
  • Pay more for a more expensive/professional version of the tool you started with if needed at this point,
  • or build said tool in-house.

The off-the-shelf plus customize-with-automation-tools covers a ton of potential business needs today.

1 point
JaimeTeran's avatar
a year ago

At my company, we usually are in the develop-first approach the tools for our clients/us. The only reason behind that is to keep us unlocked about what can we do about our products and avoid the system-lock-in. Personally, I think that today are many tools available that would for sure make our work easier.

Chances are your problem/needs are common, so probably is someone else doing something to fix it. The problem is finding the perfect tool, and on finding that, you may loss lot of time!

2 points
maguay's avatar
@maguay (replying to @JaimeTeran )
a year ago

Finding the perfect tool is tough—frankly that's one of the problems we're hoping to solve through Capiche.

Does your team have general guidelines for when stuff is worth building in-house—and are you building full software from scratch, or does in-house for your team typically mean customizing low-code tools and integrating them?

1 point
nyseans's avatar
a year ago

Nearly 15 years, I was running Product Management in my startup and had no budget for tools. Spreadsheets were no longer viable to keep track of customer requests so I used our own workflow product for enhancement tracking. It was designed to track compliance and risk events but worked well enough for this purpose and, importantly, was free (mostly). Eventually, after 5+ years, my COO got tired of funding the infra used to support this as it was on-prem and needed maintenance and backup. So I got a budget to buy purpose-built tech for managing the product lifecycle, requests, and requirements. Not a lot of good options then so we went with IBM CLM.

3 years ago, for the same problem at a different startup, I used Trello. Not purpose-built but good enough. Plus you can accept some limitations and get initial value for free. I also built a content management system using Google Docs, Google Site, and some simple scripting. Free is key in these startup environments. I just needed something to work until I showed the value and we started to scale beyond what these hacks could do for us.

Fast forward to today, I have solved similar needs internally with quick wins on tools like Airtable, MSFT Forms w/ Automation, and Google Forms + Zapier. There is always less friction to start using the tools and show value then to argue for budget up-front (unless you are the sole budget owner). Understanding the downsides of such hacked together solutions.

I have checked out some of the no-code tools recently but have yet to have a pressing need. I am sure one will come along soon enough.

1 point
maguay's avatar
@maguay (replying to @nyseans )
a year ago

Very interesting to hear the progression in how you built solutions for your team over the years. Automation tools like Zapier plus off-the-shelf apps do provide much of the customizability you'd get from custom software (and that off-the-shelf stuff often lacks on its own), though said solutions can be more fragile. It's all tradeoffs!

1 point
nyseans's avatar
@nyseans (replying to @maguay )
a year ago

This pattern of cobbling together custom tools is a by-product of not having initial budget. Most of the time, in these cases, I am willing to use tools that are not built-for-purpose and that have significant draw-backs --- as long as it was better than what I was doing before. Overtime, as use of these tools grows along with the clear value to the organization it is easier to allocate budget. Keep in mind too, that some of these predate easy to acquire SaaS tools. So even the most simple application for the team required hardware with its requisite admin & maintenance overhead that was big obstacle to getting initial value from anything.

2 points
What are your favorite tools to build an MVP?

I've used Airtable extensively to build simple internal apps as minimal viable products, but would love to build something bigger without coding. What are your favorite tools to build MVPs?

What's your knowledge processing pipeline, and how do you fill it?

My Knowledge Processing Pipeline looks like this: Instapaper → Readwise → Roam Research. Recently I struggled with discovering quality content to pipe through the line. What’s your way to fill yo...

The community for power users.