What the hell have you built

Original Article ↗ Hacker News Discussion ↗

Context and original rant

  • The site revives a 2013 critique of a startup diagram stuffed with many databases and services for what turned out to be a fairly simple product.
  • Commenters see it as a “choose boring tech” reminder: start with a straightforward stack unless you prove you need more.

Databases and caching

  • Strong support for “Postgres is enough” for most apps; others note SQLite (+ backup tools) is vastly simpler to operate and often sufficient, especially on single servers.
  • Counterpoint: managed Postgres from cloud providers reduces operational burden and is more future‑proof; SQLite may lack resilience for some web workloads, and some ORMs have better Postgres support.
  • A few push MariaDB/MySQL as equally valid “boring” choices.
  • Debate over caching:
    • Some argue you don’t need Redis at all initially and can put cache-like data in Postgres (or avoid caching).
    • Others say Redis is a justifiable exception because it’s simple and buys time when Postgres becomes a bottleneck.
    • One thread notes that at small scale Postgres can easily handle thousands of simple requests/sec.

Overengineering, procrastination, and CV‑driven development

  • Several see complex architectures as procrastination: avoiding talking to customers, sales, or product work by playing with infra.
  • Others frame it as “CV‑driven” or “job‑security‑driven” development: adding Kafka, k8s, microservices, etc. because they are fashionable and safe to justify, not because they’re needed.
  • Some engineers admit deliberately overcomplicating side projects to learn or showcase tech.

Monolith vs microservices and Kubernetes

  • Many argue small teams should start with a monolith + single database, possibly with basic redundancy and simple deployment scripts.
  • Others emphasize that complexity often addresses organizational needs: clearer ownership boundaries, safer deployments, secret management, CI guardrails, and redundancy.
  • There’s strong skepticism of premature microservices (e.g., dozens of services on a single VM), but recognition that they can match team structure and reduce cognitive load when systems and orgs are large.
  • Kubernetes is seen by some as resume‑driven overkill for most startups; others call it a painful but effective standard when you’d otherwise invent brittle homegrown orchestration.

Scale, reliability, and rewrite risk

  • Core tension: “You don’t have scale, so don’t optimize for it” vs “If success depends on future hyperscale, you may regret an unscalable foundation.”
  • One camp: vertical/horizontal scaling of a monolith + Postgres can take you very far; you’ll re‑architect anyway once you truly hit tens of millions of users.
  • Other camp: rewrites at scale are notoriously hard; for businesses whose model requires very high scale, designing for scalability earlier may avoid massive future cost.

Hiring, interviews, and career incentives

  • Multiple comments link overcomplicated stacks to hiring pressures:
    • System‑design interviews often expect microservices, Kafka, multi‑layer caching, etc., even for modest loads.
    • Simple answers like “monolith + Postgres” can be penalized; candidates feel forced to “draw the pet architecture” the company wants.
  • For individuals, not using modern buzzwords (k8s, microservices, cloud‑native) can hurt marketability, so people shoehorn them into small projects to gain experience.

CI/CD, tooling, and “necessary” complexity

  • Some argue CI/CD, basic redundancy, and secret management are non‑optional safety rails even for small teams; manual checklists and scripts don’t scale with multiple developers.
  • Others stress that CI, orchestration, or secret managers add their own accidental complexity and should be layered in gradually rather than adopted by default.

AI and cultural reinforcement

  • One thread notes LLMs tend to propose “robust, scalable” multi‑service stacks (queues, workflow engines, Docker variants) even for simple tasks, reflecting training data full of enterprise‑style architectures.
  • This can further normalize overengineering, especially for less experienced developers copying AI‑generated designs.