Show HN: I've been building an ERP for manufacturing for the last 3 years

Original Article ↗ Hacker News Discussion ↗

UX and Navigation

  • Commenters praise focusing on manufacturing UX, noting legacy systems are atrocious.
  • Main critique: a dense icon-only left nav (13 icons) is hard to learn and remember.
  • Suggestions: add labels to icons, group into titled sections, merge redundant sidebars, consider top-level menus, and optimize information architecture before adding complexity.
  • Several people say needing AI to navigate is a sign the structure is too confusing.

AI Assistants vs Good UX

  • One camp advocates “copilot”-style agents that can operate the UI, shortcut workflows, and answer “how do I do X?” questions, especially for infrequent or non-technical users.
  • Another camp strongly warns against “agentification”: chatbots are seen as a band-aid over poor design and a “nightmare” for power users who want fast, keystroke-based workflows.
  • Some nuance: assistants can help with discoverability, automation, and documentation lookup, but should come after a solid core product.

Scope, Target Market, and Positioning

  • Carbon targets small to mid-sized manufacturers (job shops and assembly), with a vision of manufacturing ERP as a harder core that can later generalize.
  • Multiple commenters argue: let SAP/Sage handle complex multi-ledger accounting; focus Carbon on operations/MES, custom SKUs/BOMs, and integration into existing ERPs.
  • Founder frames Carbon as a standardized “middle layer” (purchasing, BOMs, scheduling, etc.) that custom sales UIs and shop-floor systems plug into via API.

Architecture, Stack, and Self‑Hosting

  • The modern, many‑component stack (Remix, Supabase, Upstash, Trigger, Novu, Vercel, etc.) impresses some but worries others:
    • Harder to self‑host, debug, scale, and keep upgraded than simpler monoliths like Odoo/ERPNext/WordPress.
    • Risk of operational complexity for manufacturing teams that are not software shops.
  • Founder stresses all major pieces are MIT/Apache and theoretically self‑hostable, but acknowledges deployment is currently complex and may need simplification and better tooling.

Customization, Open Source, and Extensions

  • Enthusiasm for open source: consultants and integrators like the idea of modifying source instead of fighting proprietary extension points.
  • Skepticism from implementation veterans: forking core code is a maintenance and upgrade nightmare; enterprises prefer stable extension mechanisms over “just edit the code.”
  • Carbon’s model: opinionated defaults, open code for deeper changes, APIs (Supabase + direct DB) for integrations; accounting modeled after Dynamics but still a work in progress.

Data Quality, Supplier/Material Modeling

  • Discussion of messy supplier master data and duplicated vendors; some are building AI agents specifically for data cleanup and standardization.
  • Carbon currently uses typeahead for suppliers, autogenerated IDs for raw materials, and batch tracking for non-standard materials.
  • Commenters note similar MDM problems in healthcare and CRM/ERP integrations.

ERP Complexity, Horror Stories, and Market Gaps

  • Multiple war stories about multi‑year, multi‑million ERP rollouts (especially SAP), heavy customization, “change management” departments, and frequent partial failures.
  • Tension highlighted between:
    • Monolithic ERPs that try to be “everything” and force companies to adapt to them.
    • Highly tailored, company-specific systems that fit perfectly but don’t generalize.
  • Many small and even large businesses still rely heavily on Excel and bespoke tools; barriers to adopting ERPs include cost, lock‑in risk, need for support, and inflexibility.
  • Several see Carbon’s manufacturing-specific, open approach as promising but extremely ambitious given the breadth and depth of ERP domains.