Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Buy Don't Build

jrott.com

Post reply on HN
Print view View original

221–227 of 227 posts

Re: Buy Don't Build

#221

Post by lumberjack24 »

mauriziocalo wrote: post #107
cortesoft wrote: post #4

All of this is true, but sometimes people forget that buying a solution doesn't mean there will be no work. Sometimes, the integration and maintenance of that integration ends up being more than building and maintaining your own solution, especially if you have to do any large changes to how your systems work in order to integrate.

+1. And I'd add to that that sometimes there's significant work in the pre-buy phase as well: - Researching what your options are / what's already out there. - Comparing different alternatives. - "Hopping on a call" with a sales rep to get a product demo (there's this super annoying trend where many SaaS companies' landing pages don't explain what they do and the only option they give is to "schedule a demo"). For CR…

For CRUD internal tools, I'd still consider taking a look at other software vendors in the space. Everyone is moving so fast really.

- https://www.forestadmin.com // Fastest way to build self-hosted admin panels on top of SQL (Postgres, MySQL...) and Mongo databases

- https://www.appsmith.com // Open source alternative to retool

- https://www.internal.io // A no-code alternative to all the above

- https://www.basedash.com // Very spreadsheet like XP, YC20 startup

Re: Buy Don't Build

#222

Post by cutemonster »

rendall wrote: post #213
nobodyandproud wrote: post #200

Earlier quoted context omitted.

That’s the problem, isn’t it: Sales is a short-term metric (quarterly?), whereas client retention is long-term (multi-year, depending on contract length). I had the pleasure of carpooling with some random owner of a small tech firm, and he flat out said it was difficult to keep on top of salespersons. Meaning they were pretty shifty by nature and hard to trust.

One of the worst times I had as a developer was when my direct supervisor was a salesperson, who put me on a project that she had sold, and she was also the PM on the project. I thought I was going to die.

You had to work lots of overtime to deliver impossible promises already made to sell the thing?

Re: Buy Don't Build

#223

Post by dosethree »

yagi_baba wrote: post #170
simonw wrote: post #116

One thing to pay close attention to when making a build v.s. buy decision is the impact that billing models will have on your usage of a tool. Take logging for example. If you buy a log aggregation platform like Splunk Cloud or Loggly the pricing is likely based on the quantity of data you ingest per day. This can set up a weird incentive. If you are already close to the limit of your plan, you'll find that engineers…

I've lived that life with Datadog. I was the dev who was the most into logging so I got voluntold to be in charge of the Datadog rollout. Told everyone it was not a good idea and presented cost estimates to why, we're better off just keeping our own logs and using one of many open source projects that let you pull in logs and analyze them. But all the cool kids were on Datadog, so onto it we went. What killed us was…

Whats the point of even having it in data dog? Typically we pay a ton for services like Newrelic for monitoring, the APM, and insights. Like you, we have tons of logs, so I wouldn't want to pay Newrelic or Newrelic-similar prices for a service you can just use ELK for yourself much cheaper. So basically I don't really see why you signed on to data dog at all

Re: Buy Don't Build

#224

Post by thinkharderdev »

fuzzythinker wrote: post #144
Raidion wrote: post #87

Earlier quoted context omitted.

I think it's a matter of unknown future needs that's the problem. If you want to do feature flags, you can basically build a service that stores key value pairs segemented however you please, throw it behind redis cache, and call it a day. This is faster and probably cheaper than buying a SaaS! However, if you want a bunch of neat features, custom rollouts, and all that stuff, you're simply not going to be able to ge…

Agree with @Aeolun's comment. Feature Flagging is one exception in buy vs. build where there just isn't any good SaaS out there that makes it "just buy it" worth it. More so if you need customizations beyond what is offered.

Yeah, hosting feature flags in some service is pretty easy (just use ParameterStore!). The hard part is actually using the flags in your application code, which I don't think is something that is easily solved in general

Re: Buy Don't Build

#225

Post by Mandatum »

Renevith wrote: post #209
Mandatum wrote: post #184

Earlier quoted context omitted.

Seems like your interests align to some SRE and DevOps roles, but you'd definitely need to shop around and it'd only work at large companies.

I agree that you need to shop around; some places value this far more than others. But I don't think the company needs to be huge. We have small but dedicated teams for this on each platform (backend, iOS, Android, web) and we only have ~100 total engineers.

Sorry, your company is huge by my standards. Only 100 engineers? Most companies I consider large that I work with are lucky to have 20.

Re: Buy Don't Build

#226

Post by giovannibonetti »

simonw wrote: post #116

One thing to pay close attention to when making a build v.s. buy decision is the impact that billing models will have on your usage of a tool. Take logging for example. If you buy a log aggregation platform like Splunk Cloud or Loggly the pricing is likely based on the quantity of data you ingest per day. This can set up a weird incentive. If you are already close to the limit of your plan, you'll find that engineers…

> This can have a subtle effect on your culture. Engineers who don't want to get into a budgeting conversation will end up avoiding using key tools, and this can cost you a lot of money in terms of invisible lost productivity.

For exactly this reason I wanted to build a developer screening tool from scratch [1]. In all the companies I worked for, I never got the budget to pay for one of the available tools in the market (most have "contact us pricing"). The result is that most teams I've met spend a lot of time manually evaluating coding challenges. This is a waste of time both for the company and the candidate. A custom screening tool allows the company to calibrate it according to the perceived average candidate level, and avoid those algorithm questions that are useless for most small to medium companies.

In my previous company it was used in a few hiring processes and it worked fine - both for back-end and front-end development. It is not open source yet because your need some basic Docker and Rails skills to use it - even though the screening test can be in any language(s) you want (that runs on Docker). If it matches your experience and you want to try it out, please contact me.

[1] https://github.com/skilltest/skilltest

Re: Buy Don't Build

#227

Post by codebolt »

Completely disagree with this sentiment. I personally built a small program that scans our production environment for logs with errors and sends the team an email if something's up. Spent two days writing the initial version, have only made a handful of small extensions since then. Been using it for years now, with no complaints from anyone. But countless problematic situations that were resolved before they could cause major havoc.

Would have probably spent a lot more time wrestling with a more general solution to make it fit our particular environment.

Post reply on HN