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.
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.
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
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.
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!
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.
I have several gmail accounts. Superhuman onboarding created a split inbox for me with a calendar ICS and I forgot how to do it. Can anyone provide the steps to do this, please?
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?
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...