Our Internal Tools, and Why We Built Them
Building your own internal tools is almost always a bad decision. Almost. 😉
As a startup, your time and resources are very limited, so you should focus 100% of your attention on your own product. You should work on what makes your solution valuable to your customers, and not spend time rebuilding any software that you can buy off the shelf.
In principle, this strategy makes perfect sense. In practice, as it often happens, the strategy is: it depends. 😊
Over the years, we’ve built several internal tools at Balsamiq. Today I’ll show you some of them, and tell you why we built them.
Acetaia, our project management solution
At the end of 2016, with Balsamiq now 8 years old and 25-people strong, it became obvious that we needed a tool to keep track of all of the projects we were working on.
As this is a common problem to have, I was confident I could find a solution online. I looked into Asana, Notion, Basecamp, and others. I even trialed some of them for a while.
As I was trying them out, it became apparent to me that none of them was designed for a company like ours: remote-first, geographically distributed, flat, in which projects just appeared organically, and project teams were assembled from the bottom up.
What we needed most was a tool that showed us what each person was working on, without adding bureaucracy around it.
We also wanted a tool that could grow with us: not a tool that forced us to work in a certain way, but one that we could evolve to accommodate the way we work.
I prototyped something in a few days, and Acetaia was born.
An Acetaia, in Italian, is a balsamic vinegar cellar, it’s where balsamic is made. 😊
It has helped us coordinate work on around 2,000 projects in the last 3 years, and costs less than $10/month to run. Maintenance is minimal, and we’ve improved it to follow our ever-evolving way to work with little effort.
Again, nothing quite like Acetaia existed on the market, but the main reason we built it was because we wanted full control over its features and roadmap.
CloudAuth, RTC, LBC — born out of costly mistakes
On 3 other occasions, we originally DID find something suitable in the marketplace, and decided to buy instead of building.
The first example was PubNub — a real-time collaboration solution to enable co-editing in our apps. We subscribed all the way back in 2013 , and it cost around $200/month to run. As our customer base grew, it grew to a still manageable $400/month. That all changed at the end of 2017. PubNub decided to change their pricing, and we were told our subscription was going to start costing around $4,000 a month! A 10x increase overnight. WHA??? Obviously, we immediately got on a call with them, and at the same time started looking for a replacement. We worked out a deal that made the offramp acceptable for us, and now run our own RTC cluster (based on socket.io), for about $400/month.
A similar story happened with Auth0 — we used it for Balsamiq Cloud to manage authentication, and at first it didn’t cost us anything, we were under their ‘freemium’ threshold for a while. Only 5 months after shipping, we passed that threshold, and we were slapped with an $850/month bill! Again, WHA???? 😊 We immediately started working on our own solution, which is now part of the app: we have full control over it, and it costs us very little to run.
Another similar story happened with Logmatic — a log-collecting solution we used for a few years. In this case the problem was not that they raised their price on us, but, sadly, they got acquired by Okta, which immediately forced us to migrate to their own, more complicated and expensive solution. Instead, we migrated to an in-house ELK Stack, which we now run for about $500/month.
The main reason for building all these tools was simple: managing costs.
Schedulinator
Lately, a new reason to build internal tools has emerged, and that is data privacy.
The GDPR legislation and the data breach scandals of the last few years have opened the world’s eyes to how much our personal data is shared and traded by businesses without us end-users even knowing about it.
How much the general population actually cares about it is still up for debate, but we decided to take it very seriously, and think it will even become a competitive factor for B2B companies in the future.
So lately we took a good look at our list of 3rd party vendors that process our customers' Personal Identifiable Information, and have actively started working on shrinking it.
One example is scheduling software. For years we used YouCanBook.me to schedule meetings with partners or customers. Recently one of our employees started evaluating Calendly because it offered a better booking UX for people. We started debating internally what to do: use both vendors (and thus have both listed in our Privacy Policy), or try to standardize on just one, knowing that we weren’t entirely happy with either of them, or…what else?
So I did a little internal user research on what features we actually needed, did some technical research on how hard this would be to build and run, did some wireframes, and voilà, Schedulinator 3000! was born. I’m good at naming, huh? 😉
It doesn’t do everything those professional tools do, but it does everything we need, it’s super-easy to use, it costs pennies to run, and it only took about 2 weeks of work to build.
Most importantly, it doesn’t send your data to any third party vendor (other than AWS, which cannot be avoided these days), so now we have an even shorter Privacy Policy! Everyone* wins!
*Well, everyone except for our friends at YouCanBook.me and Calendly. 😞 I actually have a theory brewing that the push towards more data privacy could spell big trouble for smaller software vendors… 😬 let me know if you’d like me to discuss this in a future article!
Other reasons for building internal tools
Building internal tools offers more than just full control over features, costs, and data privacy.
It’s a great way to experiment with new technologies (Schedulinator is fully serverless, for instance), it provides a wonderfully safe training ground for new hires, and it’s a great distraction for someone who wants to work on something different for a while — CEO included! 😉
If you open-source some of your internal tools, they can even become an interesting source of marketing.
When NOT to build
As I said at the beginning, your default strategy should be NOT to build. You must resist the sweet song of the NIH mermaids at all costs. 😊
This article might make it look like we build all sorts of tools, but our $20,000/month AWS bill alone will prove otherwise.
If what you find on the market is acceptable, customizable enough to suit your needs, backed by a company with a good reputation, and not too expensive, by all means buy it!
If you expect a high maintenance cost, or if it’s a technology that would be too hard or costly for you to replicate, enter your credit card info and hit that “subscribe” button! 😊
Just be careful who you buy from…switching later is very expensive.
In conclusion
We build internal tools in order to have full control over their features, cost, and privacy. We do it because it’s educational and fun, and sometimes we do it because we’re forced to by freemium plan thresholds or acquisitions.
If you build B2B tools, keep this in mind: you’re not just competing with other businesses, but also with your customers' internal tools. 😅
So, what’s your stance on internal tools? What have you built, and why? Leave a comment below, we'd love to incorporate your feedback into this article.
Peldi for the Balsamiq Team
