TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Ask HN: What's a build vs. buy decision that you got wrong?

326 pointsby kiernanmcgowanover 2 years ago
What are services&#x2F;products that you built and wished you had bought?<p>Have you bought something that you had to scrap and build yourself anyways?

79 comments

nodoodlesover 2 years ago
&gt; Have you bought something that you had to scrap and build yourself anyways?<p>Yes, but that hasn&#x27;t meant it was a mistake -- &#x27;buy-then-build&#x27; can be a great strategy. Often the &#x27;then-build&#x27; never happens, but going into a decision with the mindset readiness for &#x27;then-build&#x27;, you can learn from existing products, hit their limits and understand what is the custom version of it you&#x27;ll need in your context. Recent examples are on smaller scale, though - using a library that speeds work up early, hitting its limits, and replacing or extending with DIY that does less things but goes deeper for my use case.<p>&gt; What are services&#x2F;products that you built and wished you had bought?<p>The most annoying recurring version of this has been being just a little too early - building something, then discovering a few months or years later a public product that does the same, but better. At that stage, rebuilding to use has low ROI, and one ends up maintaining a legacy monster. There was a period when public offering of supporting backend infra was maturing, ie things like secrets&#x2F;configuration management, logging, observability, monitoring, a&#x2F;b tests, a bit earlier even basic web frameworks (ie building anything on PHP before Laravel came out meant you built your framework first; iirc worse than the frontend framework landscape in 2022).
评论 #34164084 未加载
ctvoover 2 years ago
Workflow engines. Every company develops one base off of queues or some form of async messaging. Works great when prototyping and your initial customer base. Works less great as you grow, add more complicated features, and realize you didn&#x27;t have the distributed systems expertise to write this thing to begin with. It doesn&#x27;t handle any of the common edge cases, and is increasingly painful to operate, needing constant babysitting.<p>Use Temporal, StepFunctions, <i>something</i> and try to avoid this urge.
评论 #34164107 未加载
评论 #34164219 未加载
评论 #34164779 未加载
评论 #34163965 未加载
评论 #34165504 未加载
评论 #34165659 未加载
评论 #34169835 未加载
samwillisover 2 years ago
I built an entire custom e-commerce platform - product catalog, cart, checkout, CRM, order tracking, fulfilment management and back office. The site is a print on demand store, using contract printers. In hindsight I wish I had gone with either an off the shelf package or taken the punt on Shopify (this was 2012).<p>My assumptions around how much integration our custom product customiser&#x2F;editor needed with the rest of the e-commerce platform ware wrong. I thought I need a user system and &quot;saved designs&quot; for the customers, but that&#x27;s somewhat rarely used, and could have been bolted onto a standard system.<p>Maintaining and updating it is extra work over what the core business is, there is now a lot of custom code to fix old assumptions and implement features that we didn&#x27;t previously expect. All of which come as standard with Shopify.<p>We also believe that customers are increasingly used to seeing the Shopify checkout, it is a reassuringly familiar experience. I suspect it has a measurable effect on dropouts.<p>If I was to start again now I would 100% just use Shopify, no question. We are considering a large project to move to it. It would be quite satisfying to delete all that code. But it would probably bring new problems, and thing we are used to being able to customise that we will be unable to.<p>Do I regret doing it? No not really, hindsight is 20:20. A lot of lessons were learnt, but that enabled us to build a successful business.
评论 #34167163 未加载
评论 #34164108 未加载
评论 #34164624 未加载
doctor_evalover 2 years ago
ORMs. I didn’t “buy” Hibernate but we adopted it and the whole JavaEE thing wholesale. What a disaster. Learned a lot of lessons from that, #1 being, don’t use an abstraction layer (ORM) to abstract away another abstraction layer (SQL).<p>The performance of Hibernate relative to plain SQL was abominable, and this directly caused us to lose at least one contract. It turns out - on reflection, of course - that it’s not even <i>theoretically</i> possible to get into the same performance <i>ballpark</i>.<p>After years of doing battle with the tools, I eventually kicked them all out, decided to work hand-in-glove with the database, and suddenly things became both straightforward and performant. I now think that ORMs are a code smell.
评论 #34169754 未加载
评论 #34166622 未加载
评论 #34168137 未加载
评论 #34166799 未加载
wccrawfordover 2 years ago
I didn&#x27;t get it wrong, but the company I worked for did. I spent 2.5 years creating a sales tool that they dropped the same day I released it. The company went with Salesforce instead.<p>It was really disheartening to have 2.5 years of hard work dropped like that, but it was absolutely the right choice. They had designed it themselves and it was barely functional. They had a lot of upgrades planned to make it do what they really wanted.
评论 #34166034 未加载
评论 #34165343 未加载
评论 #34164917 未加载
评论 #34176625 未加载
评论 #34164492 未加载
gbro3nover 2 years ago
Not a decision I&#x27;ve got wrong, but I&#x27;d suggest authentication services are a common regret. Yes authentication is important to get right, but it&#x27;s not _that_ complex. SaaS tools for auth are incredibly expensive for the feature set they offer, and are difficult to replace once embedded in your services. SSO in large scale business is a case where buy is the right option but I&#x27;d anticipate that for many simpler use cases teams have to work hard to unentangle themselves from Okta etc.
评论 #34164226 未加载
评论 #34164821 未加载
评论 #34165096 未加载
评论 #34164314 未加载
评论 #34164058 未加载
评论 #34261260 未加载
评论 #34166025 未加载
评论 #34167368 未加载
评论 #34166367 未加载
评论 #34164050 未加载
评论 #34164459 未加载
评论 #34165548 未加载
评论 #34165034 未加载
tschellenbachover 2 years ago
Most common mistakes I see people make:<p>- They ignore overhead. If an engineer makes $100k they calculate with those number. The reality is a 2X to 10X overhead depending on the company. - Required return. You can&#x27;t spend $100 to make $100, no investor will fund that. So you need to do activities that generate an adequate return. - Opportunity costs. So say that you have an engineer that costs 100k, the overhead takes that to $400k and they need to generate at least $600k a year. That still doesn&#x27;t mean that you should do the project if you have something else that&#x27;s even better. - Maintenance. People always underestimate the cost of maintenance. I&#x27;m skeptical of any estimate where maintenance is &lt; build costs<p>One thing I regret building is an analytics pipeline. We should have relied on Segment for that. I&#x27;ve also once built an analytics platform from scratch which was bad.<p>On the flip side, one time we bought an ETL tool and it was terrible compared to in-house solutions
评论 #34166128 未加载
评论 #34165369 未加载
评论 #34165324 未加载
johnklosover 2 years ago
In the past I&#x27;ve built servers by carefully selecting parts, calculating maximum power usage versus airflow, calculating full time electrical load, building, testing with fans disabled in rooms with high ambient temperatures, looking for failure modes, researching failure rates of specific power supplies and drives, et cetera.<p>I&#x27;d build one or two, test them for several months while making adjustments and fixing various weaknesses, then I&#x27;d build ten, twenty, however many were needed.<p>One particular client decided they wanted to skip all that and just spend the money on Dell. They didn&#x27;t have many servers, certainly not enough to justify a separate server room. Their offices weren&#x27;t air conditioned at night, and they had an entire summer where one server or another would become unresponsive over the course of a weekend, and sometimes at night between weekdays. Accessing iDRAC was beyond what they wanted to do, so of course I had to do that.<p>They had Dell support, but Dell had no &quot;fix&quot; for unstable machines other than to tell them to build a server room. Mind you - the ambient temperatures were always below 100º - any reasonable person would say that while that&#x27;s not ideal for servers, &quot;premium&quot; servers should still be able to handle warm rooms, particularly when they&#x27;re idle, and not crash or lock up.<p>After that fiasco, they gradually replaced the Dells, one at a time, with machines I built. I wish they had tried harder to return the Dells, but they just wrote them off.<p>I&#x27;ve learned that any savings in time and money (mostly - the Dells cost more than the machines I build, even accounting for extra billable time) aren&#x27;t worth the loss in time, productivity and reliability in the long run. Of course, the opposite would be true if I just wanted more billable work, but I can&#x27;t do that, unlike many others in the field.<p>BTW - when I build a new generation of servers, I do months of testing, but the same general platform can last a good five years, like Ryzen 1000 through 5000 systems with ECC have lasted since 2017.
评论 #34164802 未加载
评论 #34167624 未加载
rsyncover 2 years ago
Sometime around 2019 I went <i>all in</i> on the Ubiquiti ecosystem, specifically the UDM-PRO &quot;Dream Machine&quot; and all of the integration with cameras and wifi APs that could be done with that.<p>I made this decision vs. building out a new gateway&#x2F;router&#x2F;switching&#x2F;monitoring&#x2F;SSIDRoaming infrastructure from scratch.<p>This was a bad decision.<p>Even now, nearly 2023, the UDM-PRO is a beta product and I am a beta tester. Further, we have all learned that Ubiquiti is a dysfunctional organization not focused on anything at all resembling technical&#x2F;engineering goals.<p>Ubiquiti wifi APs are still, probably, some of the best available so I will probably keep <i>those</i> ... but everything else - including PoE switches is getting ripped out and replaced.
评论 #34167604 未加载
评论 #34166188 未加载
moonchromeover 2 years ago
I&#x27;ve seen a project outsource a core component &quot;to speed up development&quot;. Turns out integrating with a 3rd party service added similar level of completely, all the design decisions had to be made around 3rd party system which constrained the project pointlessly. Project eventually got scrapped - part of the reason was that their core component wasn&#x27;t even their own and they would have to renegotiate the license to pivot.
评论 #34164277 未加载
评论 #34166314 未加载
评论 #34164698 未加载
wheybagsover 2 years ago
A commercial Nas (qnap, this time), vs just a simple Linux box with hard drives. Simple Linux box was the better option. We even wrote a blog post about it: <a href="https:&#x2F;&#x2F;www.factorio.com&#x2F;blog&#x2F;post&#x2F;fff-330" rel="nofollow">https:&#x2F;&#x2F;www.factorio.com&#x2F;blog&#x2F;post&#x2F;fff-330</a> (scroll down, it&#x27;s topic #3. Also, I don&#x27;t work there anymore)
评论 #34167351 未加载
gwbrooksover 2 years ago
Virtually everything in my self-hosted tech stack: Web, mail, specialty apps for CRM and project management... all of it.<p>I like the control and I like tinkering. But as I&#x27;ve become busier, I realize how much revenue-producing&#x2F;move-the-ball-forward time I&#x27;ve lost and am still losing by doing all of this myself.
评论 #34163956 未加载
评论 #34164042 未加载
c_o_n_v_e_xover 2 years ago
- A former CTO made the decision to fork thread mesh protocol for an IoT project. Thread (and our development) was totally inadequate tech for industrial usage. Months of development went by and no progress was made. We wound up licensing some proprietary mesh protocol.<p>- Same CTO somehow convinced investors there was no x86 machine available on the market with the right specs for what was needed… so they put together a team of hardware people to design and build a motherboard.<p>- Personal… bought a late 70’s &#x2F; early 80’s Sol cat catamaran sail boat for 500 bucks while in college. Unbeknownst to me, the hulls were notorious for delaminating and I didn’t know what to look for at the time when I purchased it. Long story short - I spent months of effort fixing and painting it, a lot of money, and sailed it once before giving up on it (of course it partially sunk during the maiden voyage). It wound up blowing away in a hurricane.
评论 #34165483 未加载
评论 #34166272 未加载
version_fiveover 2 years ago
My opinion is most companies that have built in-house &quot;AI&quot; or machine learning teams, or hired consultants to custom build AI &quot;use cases&quot; for them have made the wrong decision and are coming around to it. This is an area where buying a product is going to win, because most companies don&#x27;t have the capability of successfully managing in-house ML teams (I&#x27;ve seen line departments trying to hire a PhD ML scientist) and because a company with a product has done the work to figure out a proper value proposition, as opposed to just trying to ham fist AI somewhere into operations.
评论 #34165590 未加载
starik36over 2 years ago
About a decade ago or more, I spent a ridiculous amount of time trying to build a rig to mine bitcoin.<p>Should have bought a $1000 worth and then just post this from my Caribbean island.
评论 #34167207 未加载
评论 #34165889 未加载
steveBK123over 2 years ago
Most buy vs build decisions that go wrong with buying is because there was insufficient due diligence on the vendors, comparison to other vendors, and general ignorance of the thing being bought-or-built.<p>The worst outcomes I&#x27;ve seen are when it&#x27;s SOWs that are buy-to-build. That is - paying a vendor to build something that doesn&#x27;t exist yet. It&#x27;s like the blind leading the blind. You have to agree to these detailed specs and project plans and contract, and then at the end of the day hope they deliver because there&#x27;s so much nuance in software it&#x27;s not going to hold up in court or be with your time. If you did write specs and acceptance criteria detailed enough to be bullet proof, you&#x27;d probably have been better off just writing the software instead.<p>My company did two of these recently, one ended up overrunning by 100% with 50% of requirements not met, never going to production and half the people on vendor side quit&#x2F;fired. The other one went to production and then the vendor went bankrupt, lol.
dpkirchnerover 2 years ago
This is sort of related but I&#x27;ve often wished that I hired someone to work on my house, instead of DIYing. I&#x27;m never going to be good at most house-related repair and upgrade tasks that I will do one or two times in my life. And I&#x27;ve been unhappy with the results of most of my work.<p>The main reason I don&#x27;t immediately jump to hiring is it takes weeks to get people out for estimates, then half of them ghost you, and if you do manage to convince someone to take your money they are booked months out (and they also ghost you).
评论 #34167203 未加载
评论 #34166882 未加载
takedaover 2 years ago
&gt; Have you bought something that you had to scrap and build yourself anyways?<p>I&#x27;m very close to with another product.<p>HashiCorp is way overhyped. Yes, their open source products aren&#x27;t bad if you don&#x27;t pay for them, but then you get an enterprise license and realize how bad their support is. Seems like the company thinks that &quot;enterprise&quot; means just a product with additional features, but you&#x27;re still on your own with any help.<p>Consul, especially when running on k8s is very complex, it feels like support barely knows more than you. They won&#x27;t answer any questions explaining how given feature works, referring to solutions architects, which takes months to get access to them. Unlike Open Source, since you don&#x27;t have the source, you can&#x27;t just modify code yourself to add missing functionality, and if you ask your rep about it, they might tell you it could take a year (if it even happens) to implement it. WTF?
评论 #34169539 未加载
throwawaaarrghover 2 years ago
Have never regretted a buy. Sometimes you need to pivot if price gets too high, but there&#x27;s always been mitigations and alternatives.<p>Anything I&#x27;ve seen built that was not contributing business value ended up being a distraction.
Aprecheover 2 years ago
At my previous job the company heavily relied on an industry standard application. This app basically had a monopoly on that particular industry. However, they were pushing the app beyond the limits of most other companies. It was also just generally an old and busted Windows 2000 era kind of deal.<p>When I first arrived, and knew nothing, they told me we were going to build a replacement. That sounded great to me at the time. Obviously the right thing to do is replace something old and busted.<p>Well, I and the company learned over time that actually that was not really the best business strategy. It may have been possible, but not with the resources we had available. I ended up doing a whole lot of work that went unused, through no fault of my own.
评论 #34164600 未加载
haolezover 2 years ago
The software that ran the &quot;core business&quot; of the company. The CEO and I decided to not hire an off-the-shelf solution, which would do everything that we wanted to do, but would put our data into the vendor&#x27;s hands and we thought that it was not worth the risk. After all, we are gonna be huge and our data is our oil!<p>A few years later, our internal version of this software was crappy and our data was still not something that we could monetize. In the future, I&#x27;d refrain from being too cautious at the beginning when you are facing bigger risks that may not be sexy, but are very dangerous.
评论 #34261421 未加载
rustdeveloperover 2 years ago
I initially built a system for web scraping but was constantly running into issues of getting blocked, even when using good quality residential proxies. I had to constantly investigate why I&#x27;m getting blocked and update tools. Sometimes the effort was significant when I had to switch to a different framework which was giving me a better success rate.<p>Then, I switched to web scraping API (I&#x27;m using <a href="https:&#x2F;&#x2F;scrapingfish.com" rel="nofollow">https:&#x2F;&#x2F;scrapingfish.com</a> as they have convenient pricing for my use case, but there are other alternatives). Now I only have to maintain parsing logic in scrapers. It also actually reduced my costs of scraping since I no longer pay for proxies which are more expensive for my scale than a web scraping API.
int0x2eover 2 years ago
At a past company, we (incorrectly) assumed we&#x27;d always have to support an on-prem deployment capability, so we decided to build our own virtual appliance (assuming we&#x27;ll do actual hardware one day). That appliance cluster had to do a bunch of heavy lifting to provide a bunch of services, and we had to do it all ourselves. We even had a Cassandra-like DB cluster, which we stupidly tried to do using Scylla-DB (Scylla is amazing now, but it was just getting started at the time, and while it was super fast even then, it was not stable or reliable enough at the time). To add insult to injury, we only did a single on-prem deployment ever, and that customer never actually converted to a paying one...<p>If I could do it all again, I would have gone cloud-native (or at least leveraged K8s), and I&#x27;d use as many managed cloud services as humanly possible. At a later gig - we did just that, and we very very rarely had even 1% of the infra struggles we had with the solution I described above.<p>Nowadays, my basic advice is to always buy the best possible service when you start out, and only start to think about replacing it with DIY services when you have enough scale to pay talented engineers a salary to build AND support replacing it - and even then, the potential loss of focus and velocity might still make this a bad idea. There&#x27;s a reason Netflix is still on AWS.
评论 #34166473 未加载
评论 #34261469 未加载
Scubabear68over 2 years ago
This reminds me of situations where people “buy then customize”. Such as buying a payments gateway, then using its internal RDBMS tables directly for reports and integrations. Or buying Great Plains and then massively building on it.<p>Then one day these products eventually go EOL and the company is often stuck maintaining a zombie product. Or the products undergo a major refactor that breaks their customizations and integrations, and they end up stranded forever on version X.<p>I hear ERP systems often go like this too.<p>The only thing worse to me is entire huge products built in stored procedures. I know one product that was written in about 2 million lines of PL&#x2F;SQL. It did some amazing things, but we were locked into PL&#x2F;SQL for all time, and the Oracle scaling bills and HW were astronomical…
评论 #34164519 未加载
评论 #34165391 未加载
chinabotover 2 years ago
While fun and enlightening, my Toyota SR5 EV conversion was twice the cost of the used Nissan leaf I had before it, and apart from the stunning good looks (IMHO) has crappy range and all the other drawbacks of a 1990 car. My BMW 528 conversion I started in 2019 will probably never get 100% finished as I always seem to need another fix to get something to work properly, last year the wife got tired of my efforts and bought a Model 3. (Sigh!)
评论 #34164891 未加载
ok_dadover 2 years ago
I spent $800 bucks on a gaming PC, via parts, and then couldn&#x27;t get it to boot anything at all. It sat in my home from early 2020 until last week when I put it on the street with a FREE COMPUTER sign, never to see it again. I bought a Playstation and have been using it for years, with no problems, so maybe I just need to get a good prebuilt PC someday and not mess with it too much.<p>I don&#x27;t feel particularly bad, though, because in the past I&#x27;ve done more impressive things that were harder (building a 3D printer from scratch, putting a V8 into a Datsun Z, etc.), but for some reason could <i>not</i> figure out how to build this computer from parts.
评论 #34167423 未加载
e-dantover 2 years ago
I recently had a conversation with a colleague who mentioned:<p>“We can only be great at one thing. The rest we can only be good at.”<p>This doesn’t quite answer the question, but I think it’s related.
评论 #34261503 未加载
joelrunyonover 2 years ago
Company I consulted for had 12 engineers, spent millions and 18 months to build some niche custom e-commerce solution.<p>They were burning money and about to go belly up.<p>We spend 3k on shopify plus some outsourced shopify engineers to get 95% of their solution in ~4 weeks with zero engineers.<p>Turned the company around and ended up doing a M&#x2F;A 2 years later.
master_crabover 2 years ago
The biggest issue tends to be when people double down on continuing down the wrong path when a better alternative is obvious. The thing you bought or built is often the wrong decision three-to-five years down the road.<p>When you do hit the fork in the road on build&#x2F;buy I don&#x27;t have a hard and fast rule but generally I take the view that if it isn&#x27;t directly related to revenue generation for the company than it shouldn&#x27;t be built.
评论 #34165781 未加载
fxtentacleover 2 years ago
I&#x27;ve been bitten multiple times by relying on external products, only for the vendor to either go bankrupt, or pivot, or get acquired and then prices exploded.<p>As a practical example, Heroku has been pretty unbearable support- and stability-wise since Salesforce bought them. But moving off their platform now that we integrated it into everything for 6 years is surprisingly difficult...<p>Similarly, all of our Allegoritic automatons became worthless when Adobe bought them and replaced $100 once perpetual indie licenses with $250 monthly rental. I&#x27;ve abandoned custom 3ds max and vray plugins for the same reason.<p>And ask anyone running a dropshipping store how renting their platform worked for them. Platform prices go up until you (the merchant) have practically no margin left.
codegeekover 2 years ago
Yes. We had a nice home grown B2B helpdesk&#x2F;ticket system that worked really well for our customers but we decided to ditch it for HelpScout and it has been a big mistake. It just doesn&#x27;t work for b2b and charges like $20&#x2F;Agent when our home grown solution could be hosted on a $10 VPS with hundreds of customers on it and unlimited team members. It wasn&#x27;t perfect but far better than us switching to Helpscout.<p>I am almost reconsidering going back to the home grown solution even though it will require a bit of work since we haven&#x27;t touched that code for 2+ years and almost retired that tool.
bertr4ndover 2 years ago
Shortly after joining the PyTorch compiler team, I was part of a team that decided that we should build our own tensor-expression compiler for PyTorch (called NNC, although it wasn’t well-publicized) instead of using an existing one like Halide or TVM.<p>We ended up sinking two years into it, and never ended up with a particularly good compiler (although we did absolutely crush a couple toy benchmarks).<p>Arguably both sides of that tradeoff were wrong, though, as the eventually successful PyTorch 2.0 compiler (TorchInductor) was based on Triton (plus some custom higher-level scheduling logic).
lopkeny12koover 2 years ago
My company is currently paying through the roof for Datadog. While I&#x27;m not certain that it&#x27;s cheaper to staff a full-time observability platform team, there are a lot of open source off-the-shelf TSDB solutions like M3, Timescale, Influx, etc. that should make maintaining an in-house platform less arduous.
评论 #34164416 未加载
评论 #34164751 未加载
评论 #34164081 未加载
评论 #34166000 未加载
评论 #34167412 未加载
评论 #34163840 未加载
shp0ngleover 2 years ago
More SaaS vs self-host. But. We used self-hosted Mattermost to “save money” on Slack.<p>The loss in productivity was so big that it was definitely not worth the money saved. And the promised “it’s open source, if it misses a feature, we will implement it” never materialised either, as the whole thing is really complex.<p>I don’t know why is Mattermost so slow and buggy. But it was. And nobody had time to research and profile that.
dakomover 2 years ago
Years ago, a camera gimbal. One of those DIY kits at less than a quarter of the price of name brands.<p>Spent hours messing around with the physical rig and software settings, but the balance was never quite right.<p>I&#x27;d imagine that the kits today are better all-around. At the time it was pretty cutting edge and the idea of being able to do steadicam shots with my DSLR but on a budget I could afford was too good to be true.
评论 #34170778 未加载
janalsncmover 2 years ago
I spent a long time tinkering with my personal blog theme. Turns out, I really hate CSS. I eventually broke down and pulled a polished one off the shelf and adjusted it a bit. I’m a much happier person for it.
samhukover 2 years ago
Not myself, but I used to work for a company where there wasn&#x27;t much of any front-end development experience (almost all were usual CS grad dotnetter&#x2F;ex-java types), and quite unfortunately, and almost unbelievably, they made the wrong decision <i>both</i> ways, in a short space of time - they bought when they should have built <i>and</i> built when they should have bought (or used open-source packages).<p>So, due to the lack of front-end exp (a while before I joined), they chose to buy the license for a moderately well-known UI component library to heavy-lift a big front-end rewrite. Well, due to same inexperience, there was no due diligence done and it turned out said component library had tonnes of bugs, wasn&#x27;t easily extendable, had no real Typescript support, and on and on. The product suffered immensely for years, but dev leadership I think took on a sucken cost&#x2F;hopeless mentality.<p>Years later, just before I joined, they chose to try and do something about it and pivot (I suppose as some political recoil), deciding to have a go at creating their own UI components and gradually strangler-pattern the existing external UI library. However, leadership thought themselves and the other CS grad dotnetter&#x2F;java types could &quot;learn on the job&quot;, so they didn&#x27;t hire ANY devs with real experience, i.e. JS, TS, React&#x2F;Angular&#x2F;whatever, build tools, general front-end best practices, anything!<p>Fast-forward half a year and there is already even more bugs, a growing mountain of tech debt, etc. This is when i roughly joined, as their first developer with (back then) a couple years of f&#x2F;e experience. Took me around a year to start turning around the general careless culture the business took towards it&#x27;s f&#x2F;e dev work, and argued for more learning, adoption of industry norms, craftsmanship, and all that jazz.<p>It&#x27;s all in my rear view mirror now, but wow was that an interesting time.
jackconsidineover 2 years ago
I&#x27;ve been the lead on an insurance &#x2F; vehicle appraisal platform for the past 3-4 years. One of the primary functions is scheduling the claimant to come in for an appraisal; we used a platform called YouCanBookMe for the scheduling, wiring webhooks and API calls into the core product. We mostly used YCBM because the owner&#x27;s previous experience. It was great initially, but I tremendously regret not refactoring YCBM out after the first year. It had a few outages and quirks that caused tremendous issues on our platform, all for a commodity of a function.<p>I actually wrote about this experience and the ultimate refactor. [0]<p>[0] <a href="https:&#x2F;&#x2F;koptional.com&#x2F;article&#x2F;nuanced-strategy-build-vs-buy" rel="nofollow">https:&#x2F;&#x2F;koptional.com&#x2F;article&#x2F;nuanced-strategy-build-vs-buy</a>
评论 #34164537 未加载
评论 #34165199 未加载
maerF0x0over 2 years ago
While not strictly build vs buy (eg: technically you still have to &quot;build&quot; a postgres cluster and in house expertise even when buying AWS Aurora) but I generally like the ideas in the classic <a href="https:&#x2F;&#x2F;mcfunley.com&#x2F;choose-boring-technology" rel="nofollow">https:&#x2F;&#x2F;mcfunley.com&#x2F;choose-boring-technology</a><p>IMO your product is the only thing you build, as much as possible should buy everything else.<p>There is eventually an inflection point where your product is so mature that the opportunity cost of improving it operationally vs marginal next feature you will eventually save money, but that scale has been growing YoY for a while (AWS mostly gets cheaper every generation so far) .
germinalphraseover 2 years ago
Man… just about every woodworking project ever.
评论 #34164687 未加载
matt_sover 2 years ago
What I got wrong is not knowing management’s priorities and accounting rules about where the cost shows up on a balance sheet. This had much more weight in decision making simply because something works better for taxes (services purchased) vs large up front costs with maintenance (buying software) vs building it (labor costs plus a lot more time).<p>When management already says buy instead of build, the actual technology being bought is much farther down the priority list than engineers want to admit.
whalesaladover 2 years ago
BigQuery is not cheap but it’s remarkable at analyzing big data quickly. My datasets are currently 500gb a day and it handles them like a walk in a park.
评论 #34165438 未加载
leecarraherover 2 years ago
I think the exercise of saying let&#x27;s legitimately try to build something vs buy, is a great place to start. It will help determine what you need in an off the shelf solution, while also serving as a useful pricing target. If the buy solution is more than maintenance and development, then it makes sense to build yourself and avoid vendor lock-in and allow for bespoke flexibility. I&#x27;ve experienced both situations, some rules of thumb to go by:<p>1. is this service or product similar to what your company creates, or would you have to create an entirely new business unit to develop and support it<p>2. how complex would it be to integrate the off the shelf solution into your current system. if it&#x27;s the same as building on your own, then why pay for it<p>3. is there competition in the market for the buy solution so pricing and innovation are competitive.<p>4. who is this company selling this product or service, what is their track record, do you service as just their financier and guinea pig testers
Simran-Bover 2 years ago
Using your own company&#x27;s database application that is meant for managing physical objects in the field of cultural heritage and shoehorning it into a CRM and project management software is not a good idea IMO. One of the reasons given by the engineering leads was that this way, the software is tested internally before it ships to customers. It did break multiple times, even corrupting some records. Would not recommend. Do proper QA testing before upgrading your internal tools at least.<p>My manager shared this opinion and said, we can&#x27;t sell our software with the argument that users need specialized software and do the exact opposite ourselves by using software that wasn&#x27;t even remotely designed and fit for project management and the like. Custom solutions do also have certain advantages. But you get like 80% of what you want with common software, usually for a reasonable price and without the headache.
captaincavemanover 2 years ago
Assuming you&#x27;re talking about inside an enterprise, rather than something minor or personal, then yes (although not necessarily my decisions).<p>A trap that sometimes gets laid out is it a binary build or buy decision, there is typically options in between in my opinion. Build isn&#x27;t necessarily as onerous as it once was either, the use of cloud, frameworks, libraries, low code products and SaaS means you can often construct something from these legos.<p>In my experience, there are some in enterprises with procurement and IT management skills who tend not to have a clue about building modern software, and often push for buying stuff (keeps them busy), and sell it as a win, bought a thing, set it up, declared victory and fucked off to the next project leaving the users and technologists to figure out how to unfuck the mess that has accumulated around this clunky COTS product that is now a critical part fo the business.
lkrubnerover 2 years ago
I wrote about this at length in my book, and hopefully this part will fit within the limits of a Hacker News comment. What I got wrong: I thought this work needed to come in-house, but in the end that was not the crucial issue. The crucial issue was building a trusting, long-term relationship with the team, and that team could have been an out-sourced team.<p>Open Verse Media<p>When I first started, in 2016, at Open Verse Media, an ebook publisher, they asked me to look at their content management system (CMS&#x2F;CRM). The staff had to rely on it, but it was very slow. The COO, whom I&#x27;ll call Robin, had overseen the creation of this app. The actual work of creating the software was outsourced to one firm, but after two years Robin felt they were too expensive. She fired that first firm and then hired a firm in Ohio, which I&#x27;ll call MegaStars.<p>The app had been built using a popular software framework called Ruby On Rails. Whenever Robin felt that a new feature was needed, she would ask MegaStars to add the feature. MegaStars billed $500 an hour, and over the course of seven years, a total of $3 million had been spent on the creation of this app.<p>The staff hated the app. When the head of marketing wanted to bring up the top 100 best-selling books, they would click on a link, and it would take a full 60 seconds for the page to come up. The staff had gotten used to the fact that they always needed to be engaged in two tasks, that is, something to keep them busy while they waited for the pages in the CMS to render. An advanced search, with multiple filters, could take up to five minutes to render a report. Many of the lower-level staff would simply go into Slack and engage in gossip with their peers while waiting for each page to slowly appear.<p>So on my first day I logged into our main web server, and right away I could see that the app was generating several thousand errors each hour, all of which were being written to a log file. Since this app was single-threaded, the work of writing the errors to the log file had to happen while each page was rendering. This was one reason why it was so slow.<p>This arms-length relationship needed to be closer.<p>Why did this app have so many problems? Well, when Robin requested a new feature, MegaStars would tell her exactly how much time was needed to get that feature done. If they felt a new feature needed 30 hours to build, they would simply quote $15,000 as the price tag. Sometimes the new work conflicted with old work and generated new problems, but that wasn&#x27;t in the estimate and therefore the new problems needed to be ignored as much as possible. This tactic of ignoring new problems had been going on for many years. Additionally, much of the code base was now out of date and suffered version conflicts whenever some parts of the system needed to use newer libraries of code (which in Ruby On Rails are called “gems”).<p>MegaStars could have said, &quot;Pay us $100,000 and we will clean up all of these problems.&quot; But then Robin might ask, &quot;Why did you allow these problems to exist? What are we paying you for?&quot; It might seem like a scam, if MegaStars asked for more money to fix the problems that they themselves had created.<p>Here was the central dynamic of the situation: Robin felt she held power because she could terminate the relationship at any time. In fact, all of the problems in the relationship were because she could end the relationship at any time and was leaning on that fact as her main way of getting compliance. MegaStars was unwilling to commit to the long-term health of the software while Robin was constantly threatening to fire them.<p>When you work with an outside agency, they typically can&#x27;t or won&#x27;t go back and clean up the code, because the customer is not willing to pay $500 an hour for that work. Some of the better agencies try to include the clean-up work in the overall price, but then those agencies seem expensive — and they get undercut by other agencies that are willing to do the absolute minimum, even if that means writing poor-quality code full of errors.<p>More one-on-one meetings would have helped<p>In many ways, the situation was worse than what I’ve already described. “Robin asked MegaStars to add a new feature” – what does this really mean? As a practical matter, the real process was something like this:<p><pre><code> 1. The staff hated the CMS. 2. Occasionally the frustration was so intense that it bubbled up to Robin. 3. Robin would convene a large meeting, including all team leads and their assistants. 4. Robin would give a speech emphasizing the need to control the budget, plus various warnings she had received from MegaStars – without doing a full re-write, MegaStars felt there was a limited amount they could do. Plus a full re-write would be too expensive. 5. Then Robin opened the floor to suggestions. 6. Everyone threw out some ideas, but without any knowledge of how much a feature might cost, and no real idea of what the budget was, the staff tended to engage in self-censorship. 7. Robin would pick three or four ideas that seemed interesting, then send them in written form to MegaStars. 8. MegaStars would send back a cost estimate. 9. Robin would then approve whatever items she felt were within the budget. 10. A new contract would be signed between Robin and MegaStars, regarding the next batch of work. 11. MegaStars would deliver the work, but without cleaning up some of the long-standing problems. </code></pre> Please note, this is not a rant about out-sourcing. I’ve seen companies have great results while working with an outside agency. The real issue is this: if your company depends on an outside relationship, then that relationship needs to be a close, long-term, trusting relationship.<p>There were several factors that caused things to get so bad at Open Verse:<p><pre><code> 1. The CEO was an industry legend, but rather elderly, so she pushed most of her responsibilities onto her COO. Robin was therefore spread thin with too many responsibilities. 2. The CEO and COO had spent much of their careers in print publishing, and were slow to realize how different ebooks were. (Books that sold well were more topical, less based on the prestige of the writer.) 3. Robin was very slow to realize how much the organization depended on the CMS. She herself didn’t use it, so perhaps she didn’t realize how painful it was for staff to have to wait 60 seconds for a page to render. 4. Robin thought her power, regarding MegaStars, lay in the fact that she could fire them. In fact, this was a source of weakness in the relationship. </code></pre> It does not matter if your company has an internal tech team or works with an external agency, if you are the COO, be prepared to have long one-on-one conversations with whoever is heading up your software development. Obviously the COO is going to push day-to-day management of the tech team to someone else (a CTO or a project manager who can operate at a high level) but then the COO needs to be in frequent contact with that person.<p>Who should accumulate requests for new features in the software? That should be the CTO or project manager, not the COO. It should be a regular, on-going process, not an occasional ad-hoc event. It needs to be someone who has the time to sit with those making the requests, talk to them one-on-one, and translate what they claim to need into what they really need.<p>One way or another, the only path forward for Open Verse Media was to find someone who could manage the software on a day-to-day basis. There were two possibilities:<p><pre><code> 1. Hire a project manager and let her manage the relationship with the outside agency. The project manager could focus on building a close, trusting relationship with that agency. 2. Hire a CTO, plus several software developers, and bring all software development in house. </code></pre> Open Verse Media decided to go with the latter option. They fired MegaStars and instead hired a CTO plus several software developers. This should have given Open Verse Media the ability to move forward with faster and better software, as well as the ability to imagine software projects much more ambitious than anything that had been possible in the awkward and distrustful relationship with MegaStars.<p>As it happened, Open Verse Media hired the wrong person to be CTO. This person was an egomaniac and very controlling. This irritated the software developers, and after eight months there was a mass exodus where the whole tech team quit. If the goal was to get a team that could care about the software over the long-term, choosing the wrong person to be the team leader undermined the intent — a fact that keeps us from drawing any easy or simple conclusions from this story, regarding the benefits of out-sourcing versus in-sourcing. It evidently isn&#x27;t true that bringing the work in-house ensures the project will go smoothly. There remain other factors that can sabotage the situation. However, the fact remains that the relationship between the COO and MegaStars was unable to be productive because of distrust between the parties.<p>excerpt from this book:<p><a href="https:&#x2F;&#x2F;www.amazon.com&#x2F;meetings-underrated-Group-waste-time-ebook&#x2F;dp&#x2F;B09SFRNJKS&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.amazon.com&#x2F;meetings-underrated-Group-waste-time-...</a>
评论 #34166381 未加载
alberthover 2 years ago
Good rules of thumb, never build anything related to:<p>- Time&#x2F;timezones<p>- Taxes<p>- Encryption
评论 #34166605 未加载
Tooover 2 years ago
DIY monitoring solution. Every service had its own way of gathering metrics that were pushed into another home-made service where it could be fetched using a half-assed query-language and rendered using, you guessed right, another home grown Javascript graphing library built with raw D3 calls. The whole thing required one full time guy just to keep it running and to tweak whenever someone needed to make a new dashboard using anything beyond the most basic queries.<p>Just the graphing library alone would have been worth it to buy rather than develop ourselves.<p>The rest, obviously Prometheus and Grafana are way easier to set up, integrates with other third tools and is much more powerful and battle proven than something developed from scratch, at no cost either.
FullyFunctionalover 2 years ago
Kind of in the Bought &amp; Built: I fell for the Kickstarter trap and bought a 3D printer kit. Spent almost a year of tinkering and upgrading but it never worked reliably (always more to fix). Bought a few commercial ones which worked (mostly - 3D printers are frustrating).
password4321over 2 years ago
I see several posts with disclaimers, it makes me wary enough to dig in a little bit before following any advice in this discussion. (I appreciate the honesty.)<p>______ is hard, you should buy it. Btw, I happen to work for a company that sells it!
Yizahiover 2 years ago
Not my decision, but:<p>Company had bought CloudShell test automation system from QualiSystems, after struggling with it for a few years and hitting pretty much every possible road bump along the way it was scrapped along with all artifacts which were accumulated inside it, because of course none of them are transferable. Or rather I wish we scrapped it already, in reality we are in the second year of this process and it will take at least one more year to finish. Replacement is just python code with some sane commonly used tooling where needed.
keerthikoover 2 years ago
Build coupon flows. Every billing platform&#x2F;provider&#x2F;service provides coupons, but they never provide what seems like the obvious types of coupons you want, or the flow you would want, unless you are just starting out and have the most basic of coupon needs. If you try to use built-in coupons from your payment processor, after the 2nd or 3rd promotion you run, you are left tacking on custom functionality, writing custom coupon validation, checkout or activation flows, invoicing, or modifying customer account details.
user_namedover 2 years ago
Everything outside the core product should be bought. Building an email marketing product for internal teams does not lower costs nor does it give you a competitive advantage.
aykutcanover 2 years ago
Some parts of my old project at work:<p>1- WebSocket Server &#x2F; Service (Poorly designed, barely alive)<p>It was fine until it was not. It seems managing a lot of connections are harder than our team thinks it is. I still don&#x27;t get it why we dedicated a couple of people to this for very long time. We should have used one of the existing services like pusher or signalr etc.<p>2 - Mobile Push Notifications Service only for our usage.<p>To be honest this was working fine but they designed it like to be one of competitors. Was not worth the effort.
timthelionover 2 years ago
Not my decision but a previous org invested years in a custom CRM system. Huge waste.<p>On the other hand. For a number of years we were running AWS manaaged redis. Way worse inspectability, worse performance, worse everything than just running it ourselves. And a tad more expensive too. It&#x27;s easy to think &quot;oh I&#x27;lljust buy it&quot;, but any time there is tight integration, things get hairy quickly...
smackeyackyover 2 years ago
F*cking Thingworx from PTC. Utterly useless, old, bloated garbage. My co-founder brought it in to our startup. I had to replace it when he left, although much to my surprise I had already built 90% of the replacement building software around it to fix the various shortcomings it had.<p>I will never get than $10k licensing fee back. Awful company, awful product.
hideoover 2 years ago
On a long enough time scale - all of my decisions to reuse vs reinvent were wrong. At a given point in time though they all seemed fine.
diamondo25over 2 years ago
A C# redis lib. For just the basic set&#x2F;setex&#x2F;del&#x2F;exist and an auth layer and proper retry logic both the StackExchange and the (try-than-buy with command limit!) Other popular lib, I just made my single-file driver instead. I didnt need clustering and async. Much better and something I can trust, as well as much less code, so less error prone.
winridover 2 years ago
Every time a company moves from a paid logging solution to something in-house, like ES&#x2F;kibana, I loathe it.<p>I still miss sumologic, expensive as it may be, I probably prevented many millions of dollars of churn with being able to investigate and fix issues quickly. Businesses aren&#x27;t good at measuring this.
评论 #34170387 未加载
Aeolunover 2 years ago
I have never in my life built something and then wished I had bought it.<p>I&#x27;ve bought something many times only to find it did not sufficiently address <i>my</i> needs.<p>To be fair, I&#x27;ve also never built something in the time I originally estimated, often off by a factor of up to 10, but the end result is always better for me.
评论 #34165617 未加载
评论 #34165619 未加载
dudusover 2 years ago
Hindsight is 20&#x2F;20.<p>If things go well we made the right decision. If things go poorly we should have gone the other way.
simneover 2 years ago
You remembered me anecdote, govt decided to make really good auto in Tolyatti.<p>They have rebuilt all buildings, buy all new equipment and hire all Germans, but still got something awful.<p>So one day, decided: &quot;there cursed place&quot;.<p>That&#x27;s history of my life, I usually buy discounted top products but still supported officially, and usually they working excellent, only issue, quickly outdated software. For example, I use as photocamera old SGS4.<p>Few times I used new products, but from cheapest category (costs ~ same money as discounted top products), and this was terrible exp. For example, once, I have corporate phone, cheapest Sagem, and it was so awful, even unlimited tariff not helps.<p>And yes, I smart enough, to diy cellular phone.
gloglaover 2 years ago
Building our own ETL tool on top of Apache Spark.<p>It did work better than Informatica or whatever, but now we run 20k Spark jobs a day in the cloud, and it is incredibly wasteful to start whole Spark instance to touch ten megabyte csv file or database table.
more_cornover 2 years ago
I built a monitoring system. Datadog seemed way better and more immediately useful. Then we got the bill.<p>What I should have done is added three engineers to the project and made our own homegrown system better and more useful.
iccoover 2 years ago
Hiring Devops contractors to put together any piece of infrastructure. Infrastructure is so core to your business, you always regret and have to rebuild. Tried twice now and regretted it both times.
opinaliover 2 years ago
Maintained an in house Java ORM for years, instead of moving to Hibernate like everyone else. Good for me learning lots of cool techniques, bad for company but it was their idea&#x2F;plan in 1999.
SV_BubbleTimeover 2 years ago
Built a silencer.<p>Terrible idea.<p>There is so little margin in them that it’s definitely better to buy!<p>Even if you own an EDM, and mill, and lathe, and anodizing line, and don’t value your time at all - still buy it unless you are going to make ten.
jpgvmover 2 years ago
So less so decisions I have made but I have made a career out of correcting such mistakes.<p>I&#x27;m a database systems guy fundamentally so in the previous ~3-4 companies I have worked out my main achievement has usually been coming in and ripping out a proprietary, either custom built or poorly selected hosted database and porting it to OSS. Generally to PostgreSQL but also more specialized stores like Apache Druid (replacing a custom TSDB).<p>The issue is that folks seems to get enamored with shiny or think a certain feature of a proprietary database is too hard to replicate on PostgreSQL. Currently that is Google Firestore which has a real-time capability. Replicating such capability on PostgreSQL isn&#x27;t that difficult if you are aware of logical replication and the tools necessary for scaling it if need be (namely a distributed log like Apache Kafka or Pulsar). The end result is a system that is heinously expensive for what it does, poor at the sort of queries it needs to do and thus the system is riddled with workarounds for it&#x27;s shortcomings.<p>In the past it also included RethinkDB, MongoDB, Cloud Bigtable, DynamoDB, etc. Some of which can be good datastores if they perfectly match what you are trying to do but most of which you should never touch with a 30ft pole <i>cough</i> MongoDB <i>cough</i>.<p>Generally speaking if you should almost always use PostgreSQL unless you know you need something else.<p>The other big one for me is porting from runtimes like Lambda and CloudFunctions to k8s (either on EKS or GKE). Both of those runtimes result in terrible architecture and aren&#x27;t worth the ~2-3 days you save with initial setup of k8s.<p>For the more general question of build vs buy I see it this way. If something is core to the flow of your product the selected solution should be maximized for control and ownership. i.e favour build over buy unless there is overwhelming positives to buy or the component is so comoditized it really doesn&#x27;t matter.<p>Everything purely line of business however should be Buy &gt; Build. i.e Slack, GMail&#x2F;GSuite, ERP&#x2F;CRM, etc.<p>Example for buy &gt; build because of superiority is Cloudflare &gt; self-baked CDN. You can&#x27;t match CF network, it has to be bought.<p>Example of buy because comoditized is low level infra components from AWS&#x2F;GCP, e.g VMs, networking, LBs, DNS, k8s controllers, etc.<p>Stuff you should never outsource are authz&#x2F;authn, runtimes (i.e never use Lambda or shit like it), databases (except relatively portable like RDS&#x2F;CloudSQL), etc.<p>Murky stuff where it&#x27;s not clear: CI&#x2F;CD - lots of tradeoffs and spectrum here, hosted controller + self-hosted runners seems good sweet spot, email - generally need multiple upstreams configured with different sending domains to handle being occasionally randomly blacklisted, observability - it&#x27;s a bitch to run yourself but hosted options are heinously expensive, generally come with restrictions that reduce fidelity directly or indirectly through cost minimization. Feature flagging - hosted services usually result in CORS requests which are slow and the SDKs often block application startup, better handled yourself but maybe getting started with something hosted is OK.
评论 #34165532 未加载
aunchover 2 years ago
I think the biggest one I got wrong was in a previous job, I spent a lot of time writing abstractions and helper functions to reduce the amount of boilerplate I had to write in the name of saving time overall. In hindsight, I should&#x27;ve just bought Copilot or some other AI autocomplete tool to both save me time as desired and make the code easier to follow.<p>Disclaimer: motivated by this, I&#x27;m now building Codeium (<a href="https:&#x2F;&#x2F;www.codeium.com" rel="nofollow">https:&#x2F;&#x2F;www.codeium.com</a>), which is a free alternative to Copilot so that no one needs to consider cost as a reason for not using this tech.
jeremydwover 2 years ago
Interested in hearing any tales of build vs. buy for CMS. Anyone have anything to report? Medium&#x2F;large size company usage would be interesting to me.
评论 #34164460 未加载
yodsanklaiover 2 years ago
(If we&#x27;re talking about physical things) trying to build&#x2F;fix anything has always been a failure, a waste of time&#x2F;or money.
deterministicover 2 years ago
I have never regretted a build decision. I have often regretted a buy decision.<p>Software that I (or the team) built just works. And is a perfect fit for our needs. External software usually isn’t a perfect fit. And bug fixes can take anything from months to infinity to get resolved.<p>An example was a commercial game engine we used for a PC&#x2F;Console game. It was buggy and slow. We sent the developers code fixes and speed improvements. They ignored it. We ended up ripping out their engine and replacing it with our own.
throwaway14356over 2 years ago
I always cover this with post purchase rationalization. You just cant go wrong with that!
评论 #34165728 未加载
abalashovover 2 years ago
My own Node+Express REST API backend, model declaration format and RBAC. :-)
amccloudover 2 years ago
Most things but more recently self-serve promoted listings
Zaskodaover 2 years ago
Oh I have such a good answer for this one: a camper van.<p>TLDR: I wanted to travel the US and explore national parks in a camper van. I&#x27;m handy as a builder and knew that I could, technically, build everything. Turns out that the challenge wasn&#x27;t in the technical aspect but rather the sheer volume of work involved.<p>A little more detail: Having grown up around 4x4 vehicles, I wanted something four wheel drive. No full-sized American made vans come from the factory as four wheel drive. Even if you find a new 4x4 van on the lot, it will be an after market conversion. This means that they&#x27;re harder to find and, thus, cost a bit more than your typical 4x4 truck. But I was determined. I found a 1987 Ford Econoline in rough shape for around a grand. I bought it, named it &quot;Polar Bear,&quot; and set to work on it.<p>One of the biggest setbacks for the project was the ongoing expense and hassle of repairing an old van with a custom conversion. I learned more about automotive mechanics with this vehicle than anything else I&#x27;ve owned. Still, a lot of repairs were well beyond my scope and I ended up spending tens of thousands of dollars rebuilding various components. Repairs were a near constant problem and this drastically slowed my build process.<p>Another hitch in my plan was fuel economy. Polarbear would take me a mere 9.5 miles on a gallon of gas. With a 3-speed transmission, the engine was always running at a high RPM. The alternative factory transmission with an overdrive wasn&#x27;t as strong as the 3-speed and the gas mileage was only nominally better. After extensive research, I learned that a manual 5-speed swap could be done and would increase my MPG to over 20. However, with all of the expense and hassle of installing a clutch, I never took on this endeavor. Ultimately, I never did that national parks tour. I did, however, go a whole heckuvalotta cool places.<p>The camper conversion, which was supposed to be the focus, took me a solid ten years to finally complete. There are a lot of rather sloppy looking camper vans in the world and I really wanted mine to look good. This meant taking time on the details. And oh my, where there details. Unlike a box truck, a cargo van&#x27;s walls are all continuously curved. Cutting wood to smoothly fit the curves of the walls is tricky and takes time to figure out. I also learned a ton about automotive and RV electrical systems in the process. When I began, I imagined a very complex system. I quickly learned that the more simple the design, the better the design. Everything has the potential to break and the more complex it is, the more likely it is to break. In the end, I decided to entirely skip water pumps and simply went with a gravity based system. And despite having a propane tank mounted to the van, I opted to use a portable camping stove instead of running more propane lines. In my opinion, these were good decisions.<p>Over the course of ten years, I spent enough money to have bought a nice completed rig right from the start. At the very least, I could have purchased a completed 2wd camper and had it converted to 4x4 for far less money. This would have also given me a more modern 4x4 drive train and suspension.<p>Still, I have no regrets. What I learned was priceless and the adventures I had along the way are some of my best memories in life. I finally sold the van last year for almost 10x what I paid for it - but far far less than I had invested in it. The following link is the build thread I posted to the Sportsmobile Forums for anyone who may be interested in seeing what she looked like:<p><a href="https:&#x2F;&#x2F;www.sportsmobileforum.com&#x2F;forums&#x2F;f24&#x2F;polar-bear-1-a-3751.html" rel="nofollow">https:&#x2F;&#x2F;www.sportsmobileforum.com&#x2F;forums&#x2F;f24&#x2F;polar-bear-1-a-...</a> (the last page has the final pictures)
评论 #34175364 未加载
评论 #34164591 未加载
评论 #34166073 未加载
jdlshoreover 2 years ago
A lot of stories about building and wishing you had bought. I&#x27;m going to go the other direction. I have a story of buying something that was later scrapped and brought in-house.<p>I started blogging in earnest in 2005. At the time, I thought building my own blogging tool would be too much work, so I looked around for options that would allow me to store my content locally in source control. I settled on Blosxom, a Perl-based tool. Static site generators weren&#x27;t really a thing in 2005, or I probably would have gone with that.<p>Blosxom served me well for 15 years, but it had problems. It ran on Apache, and every time I upgraded MacOS, I had to fiddle with Apache config to get it working again. It was customized with various plugins, and over the years I accumulated a lot of plugins and tweaks, to the point where I was afraid of making changes for fear of inadvertently breaking something. And it was very slow. I have a huge amount of content—I just checked, and it&#x27;s currently at 6.9MB <i>of text</i>—and Blosxom couldn&#x27;t handle the volume.<p>These problems meant that I eventually got to the point where I couldn&#x27;t realistically make changes to the website any more. Blosxom had to be replaced.<p>Let&#x27;s set that story aside for a moment. Back in 2012, I started a subscription-based screencast called &quot;Let&#x27;s Code JavaScript.&quot; To learn more about Node.js, I decided to build the website for the screencast myself, rather than using something like WordPress.<p>This code was a pleasure to work with. I had written with tests, so it was easy to change and evolve. Starting around 2018, I decided to start evolving to support more than one site, with the goal of eventually migrating my blog off of Blosxom. I did this gradually, in my spare time, as kind of a fun side project. Mostly it involved cleaning reversing questionable design decisions involving globals, and cleaning up bad tests so I could do so.<p>By 2020, the codebase had evolved into a general-purpose content management engine. I migrated my content from Blosxom. In 2022, I migrated a PHP website a third party built for another business I was involved with. Now the system handles three websites, all on a single server: letscodejavascript.com, jamesshore.com, and agilefluency.org.<p>The result is so much better than using Blosxom, and I think it&#x27;s better <i>for my needs</i> than anything I could buy. It&#x27;s well tested, has a great development feedback loop, and any feature I want is a small code change away. For example, I replaced Google Analytics with simple email alerts that inform me when a piece of content gets a surge of attention. It was an hour or two of work.<p>I don&#x27;t think there&#x27;s any grand lessons to be learned from this, other than the one lesson everybody forgets when they&#x27;re contemplating build vs. buy: it&#x27;s not &quot;the cost of building&quot; vs. &quot;the cost of buying&quot;. It&#x27;s &quot;the cost of building + maintaining&quot; vs. &quot;the cost of buying + the cost of keeping up with vendor updates + the opportunity cost of some feature changes being unsupported.&quot;<p>In my case, in 2018-2020, &quot;build it yourself&quot; was the right decision, because I had a robust codebase that I could evolve into a content management engine. In 2005, &quot;buying&quot; Blosxom was the right decision. I don&#x27;t regret either choice, and I&#x27;m happy with where I&#x27;ve ended up.
elecushover 2 years ago
this is an incredible question and ought occur periodic&#x27;ly on here
extreme_museumover 2 years ago
yes
评论 #34164510 未加载