Ask HN: Should we bring software dev in-house?

Hacker News Discussion ↗

Strategic Question: Build vs. Buy (or Hybrid)

  • Many argue in-house dev only makes sense if software is core to your competitive advantage or your niche is badly served and unlikely to improve.
  • Others say the cheapest and least risky path is often: fix the relationship with the current vendor, pay more, or co-fund new features (NRE), or even acquire the vendor or their code.
  • Several note that most in‑house projects are underestimated by 10–100× and often stall at ~80% completion.

Leadership & Ownership

  • Strong consensus: do nothing major without a senior technical leader (CTO/VP/lead engineer) with both business and tech sense.
  • This person must deeply learn your workflows, own requirements, control scope, and be empowered to say “no”.
  • Some caution against “paper CTOs” who haven’t coded in years; others warn that purely business-side PMs will mismanage engineering.

Migration Strategy & Architecture

  • Common advice: avoid “big bang” rewrites; use the Strangler Fig pattern—replace slices of functionality while the old system keeps running.
  • Start with a small but real vertical slice / MVP that handles a critical yet bounded workflow.
  • Modular monolith is preferred by many; strong warnings against premature microservices.
  • EDIFACT and integrations are seen as tricky but solvable via libraries, shims, or cloud B2B/EDI services.

Team Structure & Talent

  • Popular pattern: start with a very small, very senior team (often freelancers/consultancy), then gradually hire FTEs as you gain clarity.
  • Internal domain experts must be heavily involved; some suggest they should almost act as PMs.
  • Hiring is feasible even in “boring” logistics if you offer: good pay, autonomy, remote work, decent tools, and visible impact.

Risks, Costs & Culture

  • Development is “expensive forever”: after V1 you pay ongoing maintenance, upgrades, and support.
  • Danger of over-engineering “startup-grade” platforms for what is really internal tooling.
  • Serious cultural risk: treating software as a mere cost center, understaffing, or layering bureaucracy and multiple non-technical managers over one codebase.

Alternatives & Variants

  • Use or extend open-source ERP/low-code platforms, focusing custom dev on your true differentiators.
  • Contract a specialized software house with strong domain experience, but keep architecture/ownership in-house.
  • In extreme cases: industry consortia or open-sourcing to share cost and avoid lock-in.