Live data from Hacker News

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

github.com

121–130 of 161 posts

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

#121

Do you have any users yet? What’s your target size manufacturing company? I’ve been in the industrial software space for a while, and at least for large MFG, you only see the major players, with SAP being the most common. There is this “UNS” concept that’s been around for 5ish years now and has caught steam (unified namespace, google and you’ll find it). It has holes from a technical standpoint, but it will get atten…

The current offerings, like SAP, GE tools, etc.. Are so over-complicated and bloated, that most of the money spent is just to figure out how to configure them. Most people hate SAP but don't know what to do. Caught in catch-22, they hate it, but don't trust any other options.

== Most people hate SAP but don't know what to do. Caught in catch-22, they hate it, but don't trust any other options==

I think it is worth pointing out a little nuance I learned while working at SAP.

- The IT department tends to hate SAP due to its insane complexity and never-ending configurability.

- The business users (procurement, A/P, finance, etc.) tend to like it because once it is set up, it “just works” for them.

It’s important to know that the buyer and user might be different folks/departments.

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

#122

Earlier quoted context omitted.

No, I mean, like a copilot style AI assistant, the user can chat with to ask what they want to do, and either the assistant can operate and navigate the UI to the right place, or perhaps even shortcut the steps for the user by asking for questions to satisfy inputs for the thing they are trying to accomplish. An example: - user intent is to update an attribute for a component part number A21445 - user can click a cha…

This is a power-user’s nightmare. Instead of arranging things in a logical hierarchy, and enabling quick navigation thru keystrokes - just toss out making the ui make sense because the chatbot can solve all. Your job is to make a good product. AI-as-interface is just slapping a layer of randomized language parsing in between the user and bad ui. I’m not actually saying no chatbots. What I am saying is using a chatbot…

Chatbots would be great for discoverability, especially if you have a ton of docs that nobody seems to read.

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

#123
Great work. Everything you say in your Readme about existing systems is true.

I notice you don't have financials yet. In my opinion the API approach is really difficult to get right with financials. Every finance professional will tell you nightmares about 'the stock doesn't balance between the two systems'. The first reason on stock is a costing problem, you must have the same costs in both systems, so every purchase cost change, every bom roll up must change both. The second is on quantities. This is usually caused by a stock movement that somehow failed in the API to the financials. If it is done in a more tightly coupled way, you post the stock movement and the financial movement inside a database transaction and it either fails everywhere or posts everywhere. I worked on one system where it posted each half of the double entry in different transactions, so would fail and leave the ledger out of balance! Happy to chat further

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

#124
post #46
post #43

Earlier quoted context omitted.

ERPs supporting complex asset maintenance (eg mineral processing plants in the middle of nowhere) have a different flavour of complexity, although you could argue they are EAMs.

Mincom, a Brisbane based tech company started in the late 80s with a suite for mining, and oil/gas production. At the time, they had 1-10 customers who paid a LOT of money. I am sure they are bigger now, but the fundamentals here are the same: you have to maintain almost every version of product back to the origin, and backport any change, because you can guarantee there is a mine in Kazakstan making a very large amo…

Indeed. That was the very company I was thinking of! The Mincom EAM product (Ellipse) now sits with Hitachi and their technical mining products found their way to Datamine after ABB acquired Mincom, then divested the acquired assets a few years later. The resources sector has a gazillion lines of FORTRAN, some of it freshly coded (new codebase) within the last 10 years, believe it or not.

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

#125
post #2

As a UX person, this is the type of stuff I love to see posted here. So many people don't understand how atrocious the UX is in non-sexy career tracks such as manufacturing. One question I have is how users have reacted to your leftmost nav bar. 13 icons is a lot, do you show them all at one time, or do they dynamically appear based on the user role of the person who's logged in at the time?

man! i wish i knew how to do a better job with that. there's just so much stuff. do you have any ideas?

I have no idea why you’re using icons for 13 things. Use words.

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

#126

While we're on the topic of ERP: I have noticed that, in 2025, many small businesses still use Excel. Is there an underserved market? Or simply a "tarpit idea" (deceptively attractive but actually unscalable, time-consuming) I asked 5 friends who are business owners and 5 who are working for SMEs. None of them use "apps". The best they use is accounting app.

> a "tarpit idea" (deceptively attractive but actually unscalable, time-consuming)

Well it's hard to be as cheap as a spreadsheet.

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

#127
I really recommend you do more reading on DDD. This codebase is looking like a ticking time bomb. Biggest red flag I’m seeing right now is your supabase/functions/create/index.js. You have 2000 lines of code that contain what I see is your domain logic mixed with database queries and http concerns. In some places there are 8+ levels of conditionals, promises, and error handling. For an ERP system, this is not good. Ideally the domain logic (accounting, rules, core erp stuff) should be isolated by itself, with solid test coverage, free of any external communications/concerns, etc. The reason being that this is not something you want to fuck up. Business rules are tough as I’m sure you know, and this is going to be a pain to maintain in its current state

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

#129

Earlier quoted context omitted.

yeah, good point. the docs could definitely use some work. check this out if you're interested. it's not complete, but it goes through the software pretty well: https://learn.carbon.ms i don't know if you build anything custom, but we do have a configurator

Did you folks roll this yourself? I like the learning platform and was trying to figure out what you've might have used to build it.

thanks, here's the code for it: https://github.com/crbnos/carbon/tree/main/apps/academy

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

#130
post #127

I really recommend you do more reading on DDD. This codebase is looking like a ticking time bomb. Biggest red flag I’m seeing right now is your supabase/functions/create/index.js. You have 2000 lines of code that contain what I see is your domain logic mixed with database queries and http concerns. In some places there are 8+ levels of conditionals, promises, and error handling. For an ERP system, this is not good. I…

I was wondering the same, about their backend domain model (or lack of it).

Fwiw in the TypeScript space, we built Joist (https://joist-orm.io/) to do exactly this.

Granted, we went with a Rails/ActiveRecord minimalist take on DDD instead of some of the more elaborate (overkill imo) implementations that are common i.e. in the .NET space.

Post reply on HN