Tackling this age-old dilemma in the age of SaaS
On several occasions, we’ve had customers ask us why they should use an API instead of trying to build their own solution.
I almost always drop some Yoda on them:
Depends, it is. Balance your budget, you must.
Many companies like to brag that they build everything in-house.
I can slap this together in 2 weeks with a team of 5 engineers!
It’s not as easy as it sounds, and your technical leads are not going to like you very much.
Building things costs money. But worse still, the process can detract your company from focusing on your core competencies, leading to middle management bloat.
This can cost the company significantly, in terms of higher overheads, reduced revenue generation, and most importantly, difficulty in maintaining a laser-focus product strategy.
Worse, building an internal solution that has limited use means that you lose out on potential to fully utilize economies of scale (and enjoy the ensuing lower unit costs).
Cut away the fat, focus on the lean product
In the tech world, engineering is increasingly shifting away from product managers towards technical leads. PMs tend to bulge out the organization, adding a layer of complexity to an already convoluted company. Companies that succeed best, do so by flattening the organization.
Many tech companies also face organizational issues in the friction between PMs and Engineering Leads.
A long time ago, building software solutions in-house made a lot of sense. Much of software back then needed to be installed on computers in the organization. A lot of a company’s data was also stored and managed in-house, summarized beautifully by the role of the sys-admin:
Back then, developing in-house solutions made a lot of sense — licensing fees were much higher and oftentimes your data management needs were significantly unique.
These days, a lot of the software we use is run on the cloud. Much of the tech stack today can be deployed online, and not on individual machines. Much of the software today is generic as well, running on open source code, robust and flexible. Updates are also pushed automatically. The days when companies had to spend months just updating their software systems are almost gone too. This has dramatically reduced the cost of contracting your solution requirements to external vendors, versus developing in-house.
Take Semantics3, for example. We’re a highly specialized data company. Yet, we don’t have a server farm to host our data — it’s all managed on Amazon Web Services
Which brings us to our point: sometimes it makes sense to whittle down your product development to a few core components and buy/contract out the other incidental components.
Buy, or build?
This brings up the next question — should your company buy or build a solution?
Ultimately, the basic rule of thumb is this: if there is an existing solution already out there that can be plugged into your product, you can save engineering resources by not reinventing the wheel.
We recently published a Build vs Buy calculator to help people decide:
Here’s why buying works better:
- It’s cheaper: Buying, rather than building, non-core functionalities saves you engineering manpower and the associated overheads.
- It forces you to focus on core competencies: Trying to simultaneously build all the pieces for your product can be harmful to team productivity, especially if you’re a start-up. You won’t be forced to hire for different skill sets, giving you the freedom to focus on your hiring on core competencies.
- It makes your team happier: Teams like working on one core competency that they’re really good at. Being forced to build a bunch of stuff that’s only incidental to the company’s secret sauce saps morale.
- You don’t have to reinvent the wheel — and more than that — be forced to build a product which apes an externally available product.
- You can scale quickly: By using off-the-shelf products, you can work with the external vendor to scale up your product usage as you grow.
- External vendors can work with you to find a solution you need. At Semantics3, we don’t only sell standard SaaS packages, but we offer a comprehensive suite of tech support and Enterprise level customization to your needs.
Additionally, an oft-missed point about is that the build question often leads to very flawed answers:
You should go in with the assumption that your vendors are intelligent, and if it took them several years to build something, it will take you the same amount of time too (by which time your vendors would’ve gotten ahead).
So when your team comes to you and says that something can be built in 2 months, be cautious. There’s an interesting rule of thumb here → if someone quotes X value and Y unit (e.g. 2 months), assume that worst case scenarios is X+1 value and Y+1 unit (i.e. 3 years).
Many of our customers (some of whom are top internet retailers as well) also rely on us for the crucial data feeds — if they can rely on us, you can too!