Show HN: I've been building an ERP for manufacturing for the last 3 years
37 comments
·August 4, 2025danpalmer
plumeria
> Carbon on the other hand appears to be quite a few different components, with many dependencies, some of which are SaaS products, and uses a database (Supabase) which is itself a whole microservice ecosystem that is a considerable effort to deploy
Perhaps this could be addressed by providing a Pulumi or Terraform program?
barbinbrad
I think we can simplify this over time. Everything in our stack is MIT/Apache. I'm keeping my eye on this fastabase project from Drizzle: https://github.com/drizzle-team/fastabase/tree/main
robertritz
I’m the owner of a smallish furniture manufacturer. About 15 employees. I built out the order management system myself because nothing really fit our process.
After looking at the site I can’t really say I know how this software could help us. I’ll look at it later on my desktop but first I think some better demo videos or gifs on the landing page would be nice.
barbinbrad
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
ronameels
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 attention if you can show how it works with factory data in a UNS. Happy to help if i can. I work at a company that does industrial dataops now, focused on getting shop floor data in/out of the factory with context.
barbinbrad
Hey I'd love to learn more about your thoughts. We have a discord if you'd like to join.
I see the market like this: - small job shops and startups are using it now (we have 5 customers today using it to run operations) - mid-market manufacturers with 200-ish employees are where i'd like to go, but many want all the accounting baked in and that's still a WIP - large players have to use SAP for accounting because they have multiple-ledgers, but i see this as a good "custom MES starting point"
xupybd
We built a lot of the custom ERP related systems outside of our ERP. Leaving the financials to the big boys and just talk to the ERP. It's working really well.
mtillman
We recently replaced Oracle financials for two of our customers-mid size manufacturers doing around $10B/yr in revs. We’re pretty small so grateful they trust us with that level of work.
d_burfoot
Does the ERP allow you API access, or do you need to do CSV upload/download?
barbinbrad
we give people access to the same supabase API as us, but it's scoped to their company with RLS. the docs are autogenerated: https://x.com/barbinbrad/status/1873043714454811100
you can use the API from inside the codebase, or outside of it: https://github.com/crbnos/carbon?tab=readme-ov-file#api
barbinbrad
agree. it's very impressive how SAP maintains multiple ledgers for different regulations in different countries. i'm not going to replace that any time soon. i think even tesla uses SAP for accounting, but something like this for the rest.
fakedang
Is there a reason for such an arrangement? Why would Tesla not use SAP as their backbone ERP too?
mfrye0
Congrats on the launch! Love seeing modern manufacturing systems.
Do you handle supplier master data management? We're seeing procurement teams struggle with duplicate vendors in their ERPs - same supplier gets entered 5 different ways, messes up spend analytics and supplier relationships.
We're building AI agents for business data cleanup (still in stealth, docs coming). Manufacturing/supply chain customers seem to have the messiest supplier data - way worse than other industries.
Curious if this is something you're thinking about for Carbon? (CTO here, happy to chat)
barbinbrad
for the supplier problem, we just use a typeahead/combobox component.
but for raw materials, we auto-generate the ids like this: https://x.com/barbinbrad/status/1947682873416221184
also working on some agents: https://x.com/barbinbrad/status/1903047303180464586
would love to talk, i'm brad@carbon.ms
daedrdev
This is interesting but what about non standard items? There are plenty of cases where the raw material might theoretically have the same name, but was made with a different process by each manufacturer or the resulting item from different manufacturers has slightly diverged for various reasons.
mfrye0
Nice! Yeah, a typeahead works to a degree. I imagine that's searching their own instance vs calling out to a standardized DB you manage?
Raw materials is definitely a different animal, so auto-generating definitely works. I know a company where that's all they do - they manually pour over supplier specs to get all the model names.
Agent approach looks super cool. I see the supplier search piece happening there.
We've mapped out ~265M+ businesses globally. We're thinking about this as a data infra angle where products can tap into our system to access all the world's businesses. We're getting requests for processing millions of ERP records to clean/standardize, plus semantic supplier search across our full dataset.
I'll shoot you an email to chat more.
barbinbrad
thanks! look forward to talking to you
ageyfman
this is a big issue in healthcare, a chunk of my last company's revenue was doing MDM for large medtechs.
mfrye0
Interesting. Was that a MDM focused product for healthcare or something more general infra wise like Informatica?
I don't have much context in the healthcare space and the challenges that exist there. We've been mainly talking to people in fintech, supply chain, and sales & marketing, which is primarily where I ran into this at past roles.
MutedEstate45
The modular ERP/MES/QMS approach is interesting and challenges traditional manufacturing processes. Most manufacturers obsess over single source of truth. (I.e. ensuring a part number means exactly the same thing across planning, production, and quality systems.) On the one hand, breaking these into separate apps creates potential data consistency risks. On the other hand, it could enable much better adoption. Start with MES for shop floor visibility then add QMS for compliance later rather than massive all-in-one ERP implementations that often fail. Curious, how are you handling data consistency across modules? What's been the feedback from your current or potential customers on this approach versus traditional monolithic ERP systems?
barbinbrad
hey founder here. they are separate apps, but use the same database, and same api. i'm also a big believer in single-source-of-truth and the compound startup idea
MutedEstate45
Ah gotcha. Makes sense to get the benefits of modular adoption without the headaches. Nice approach.
twarge
How does this compare with the manufacturing capabilities in ERPNext?
barbinbrad
i don't know a ton about ERPNext's manufacturing capabilities, but i think there are really great for these reasons:
- free to try - open source - well-documented - great developer community
one big difference is in the data model. in ERPNext, everything is a doctype, and there's some standard hooks.
in carbon, there are hundreds of different tables. each ui is it's own set of react components, so it's a lot more manufacturing-specific and a little more opinionated.
fiatjaf
A stupid question from a layman: is it really how people do it?
I would have thought "manufacturing" was too generic and that you would need different software for each industry and so on.
But instead it looks like it doesn't matter if you're making shoes or cars or umbrellas or computer chips, everything uses the same software?
barbinbrad
founder here. great question.
the way i see it, the sales side should be bespoke -- because everyone has a different product, and way of selling/configuring, and the factory-floor side should be bespoke -- because of all the different types of equipment. but the middle layer (purchasing, bill of materials, invoices, sales orders, scheduling, processes, work centers) can be standardized.
for me that's why it's important that the middle layer is open source. so that the bespoke layers can tie into it.
jjk166
At the ERP level everything is abstracted such that every operation is just a black box - stuff (raw materials, subcomponents, labor) goes in, stuff (assemblies, finished goods, scrap) comes out.
jdhn
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?
barbinbrad
man! i wish i knew how to do a better job with that. there's just so much stuff. do you have any ideas?
sixdimensional
Give users an AI assistant they can ask to navigate them to the right screen or section of the application?
In a previous job, we built our AI assistant so that it could operate our UI in the front-end and it was very powerful.
barbinbrad
like a cmd+k type deal or something different? we do have cmd+k navigation to everywhere currently + global search, but i worry that less sophisticated users might not use it.
healthbjk
What vertical ERPs does it replace?
barbinbrad
right now, we're just targeting small-medium manufacturers. there are two types -- one for job shops, and one for assembly type work. we're trying to target both.
imo though, it's fairly straightforward to go from a manufacturing ERP to a non-manufacturing ERP -- but it's very difficult to do the opposite because of the complexity of manufacturing.
486sx33
[dead]
qotgalaxy
[dead]
First off, congrats, this is no small feat, well done.
A question: in my (limited) experience, ERPs are made on the basis of integrations. I'd have thought the best priority order would be data-model first, integration second, everything else third. How do you think about this? What's the goal here?
And secondly, some feedback: It looks like Carbon falls into the same trap as many self-hostable SaaS-like products (including my own!), and that is that software designed for one single hoster is often more complex to deploy and built in a different way, whereas software designed primarily to self-host looks much simpler. As an example, installing Wordpress or Odoo is relatively simple, with basic frontend webserver config and easy to run open source databases. Carbon on the other hand appears to be quite a few different components, with many dependencies, some of which are SaaS products, and uses a database (Supabase) which is itself a whole microservice ecosystem that is a considerable effort to deploy. What's the strategy here? Despite having the skills for it, I'm not sure I'd ever consider self-hosting Carbon, and maybe that's good for Carbon as a business, but it's also less good for the ecosystem.