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

81–90 of 227 posts

Re: Buy Don't Build

#81

Post by taylodl »

taylodl wrote: post #76

Systems of Differentiation should employ a build-first strategy. These are the systems that differentiate you from your competitors, they are your competitive edge. As such you typically need tight control over these systems and don't want to rely on 3rd parties - either vendors or contractors. Systems of Engagement & Systems of Record should employ a buy-first strategy. These are typically more operations-focused sy…

I should have pointed out this is the strategy that should be employed by an established company. If your company is just starting out then buy everything if possible - your competitive edge is the fact you're small and nimble. You can respond to market changes faster than the established companies can. Over time you'll recognize what are to become your Systems of Differentiation and then and only then should you consider building that yourself. When you're starting out you typically don't have the time or capital to wait and build the software you may need. For such companies doing business and generating revenue now is more important than having a perfect application portfolio. And yes, this is why systems are never as perfect and pristine as developers would hope.

Re: Buy Don't Build

#82

Post by CapitalistCartr »

Building anything is step 5 of a good process, not step one. Whether you buy or build is far secondary.

First, check the motivations. Emotional or logical. If the driving motive(s) is ego, that's already a big, red flag. Consider running like a bull in reverse.

Second,intel. Gather information about the situation; educate yourself. Find the apples on the road.

Third, formulate a vision, an image of the final result that all the stakeholders (those whom you cannot ignore, no matter how hard you try) agree on. This is where beautiful diagrams are created. Which don't matter. All that matters is each stakeholder signs & dates it.

Fourth, plan. Use your knowlege gained in step two to formulate a plan for getting from the current situation to the "vision".

Fifth, execute said plan. Find more road apples.

Sixth, debrief. Analyze the outcome. Get a drink with the ones who did the work.

This can all boil down to just you spending 2-3 days running around doing it yoursels, or multiple teams spending most of a year herding cats. The important part is knowing the steps, and mentally looking for them. And for those who push to skip.

Re: Buy Don't Build

#83

Post by burnte »

Meh. In 2007 I wrote a webapp for a friend to help him manage his business. It's in PHP and other than a few fixes here and there, it's running just fine in 2020.

Re: Buy Don't Build

#84

Post by bird_monster »

I work at a small startup. My boss comes from only enterprise level companies. My boss believes literally everything we touch has to be custom, and we have to make it. It's an incredibly exhausting process of getting in front of and/or retroactively nullifying any planning the company does based on his suggestions, because most of the time they're quite harmful to our startup's tech. I've gone to our CEO about it and he agreed that we have to curtail this behavior whenever we see it. It's just an extra layer of "stuff" I have to think about.

No, we don't need k8s, Kafka, a home rolled CDN, custom authentication, etc.

Re: Buy Don't Build

#85

Post by aeternum »

victor9000 wrote: post #21
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.

While I agree with this comment, if someone buys and ends up in the position you describe then they did a poor job at buying.

Nowadays you're often buying SaaS so not only do you need to ensure the product is a fit currently but you must predict the fit going into the future.

It's not an easy thing to do. I've found that open source libraries are often more stable, require less ongoing maintenance due to API changes and have better support lifetimes compared to the SaaS equivalent.

Re: Buy Don't Build

#86

Post by satyrnein »

fuzzy2 wrote: post #35

I'm a little confused. When I have to build software (for a client), it's usually to support some business process or make it automated or whatever. What am I supposed to buy, except some PDF/Excel/whatever library every now and then? But maybe I'm just not the target audience for this article.

Yeah, doing work to automate some idiosyncratic process, either for clients or internal users, may be different. You do have to be careful you're not slowly implementing a CMS, CRM, email marketing tool, etc, feature by feature, though.

Re: Buy Don't Build

#87

Post by Raidion »

thinkharderdev wrote: post #25

These sorts of discussion always seem somewhat confused to me because "buying" vs "building" is not a binary choice. It is more often a choice between: 1. Buy some platform/framework which you will then need to hire a small army of costly consultants to integrate and customize for your particular business need. Or 2. "Build" your own solution by orchestrating a bunch of open source technologies to solve your problem.…

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 get the same value (unless you have HUGE scale) building it, and should just buy it.

Most organizations aren't comfortable saying "this is all we'll ever need" and are worried about both building, buying, and then migrating, which can be significantly more expensive than either of those options in a vacuum.

Re: Buy Don't Build

#89

Post by zapataband1 »

There are some good points in there, but it's worth noting build/deploying is becoming easier than ever. For a simple static site you could pay 300$ a website-builder-thing or you can build an app inside a docker container and your host will reboot it for you if it crashes. I use a docker-compose.yml file and I was able to quickly download an open source service that automatically renews my SSL cert. But yeah it depends on the scope, and the project, and what skills you have freely available or wouldn't mind learning.

Re: Buy Don't Build

#90

Post by temporallobe »

This is not a universal truth. I’ve worked with COTS products that required a ton of work to customize and get working properly - sometimes costing as much in time and manpower as it would have been to build the same thing from scratch. Often this happens with managed server all-in-one “business solutions” systems that let non-developers build UIs and reports (and charts/visualizations, etc.). Nearly 100% of the time this is inadequate and often completely fails, requiring management to bring in actual software engineers to “fix” things and eventually just rebuild an entire dashboard from scratch using real development tools and techniques. Many of these kinds of shops underestimate the importance of strong software engineering practices and fail to understand the complexity of their own requirements, much less the complexity of their data.
Post reply on HN