Ask HN: What's a build vs. buy decision that you got wrong?
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.