Then there's MRP (M for manufacturing) which is usually an option - for when stuff that you're selling isn't the same as what you're buying.
So the ERP/MRP manages bills of materials for items (basically parts lists), when you want to sell something you make a sales order, it sees if you have the inventory on hand to actually make the things, and if not you can generate purchase orders, and then once you have everything it can create work orders which basically tell your factory people to go and turn the input parts into a product so you can sell it. Invoices are created from sales orders, and workers time is tracked on the purchase order, so the cost of goods and labour is automatically tracked in your financial reports as well as the revenue etc.
And ERP is Enterprise resource planning.
I now work on a large company that is about to introduce a large new erp system and is not only investing billions into that change with the mother of all vendor lock ins; but we're also internally transforming the company so that the erp will work. But no, we can't afford the two days of estimated work to upgrade to c++20 as it's not necessary right now.
I'm not sure how things are now, but I once worked tangentially on a mid-sized corporation ERP rollout. At that time it was not unusual to have an entire department at the ERP-adopting company called "Change Management." Any company-wide process change was managed by the Change Management department.
The reasoning is that a company in a certain vertical with a certain size will spend x% of revenue on IT, and they want all of that.
ERP platforms are ridiculously hard to customise, and maintainance of customisations across version upgrades is even worse. So they will rightfully advise business operations adapt to the ERP template, rather than the other way around. They know full well in advance you will end up not following that advice as the changes would be enormous and lost functionality as compared to the previous system beyond tolerable from a business point of view, but they also know you will only discover the scale of this after the project has been committed.
Speaking about committing: they will leave no room, basically execution a denial of service to the whole of not just your IT departments but also all your business analyst interactions. Any non ERP transformation project will grind to an absolute halt.
Many of not most of these huge ERP migrations fail. The ERP vendor has been covering there ass from before the contract was even signed, and you will find their real expertise was building an airtight very well documented case showing you, not them, were at fault. These cases are nearly always settled and kept out of the press because neither party wants to lose face.
And you are right about the mother of all lockins if the project should succeed and actualy move into production (which they will try to force long before it is ready). They will leave you no room to ever go back. You'll have to commit even a lott more to leave than you needed to get in.
And as for all those business and IT people now trained on the ERP, wich is part of the project from day 1, good luck holding on to them. Their poaching will be not overtly but discreetly facilitated by the ERP's channel.
First day of first 'course' by the ERP vendor for the ERP transformation team, the opening sentence of the instructor litterally was: "I congratulate you all for being here. Next week after completing this course, walk into your manager's office and demand a 20% pay rise, as you are now worth that".
I myself have turned down very lucrative monetary offers, as the downside of working in those projects, whether at vendor or client side, is that the amount of unhappiness you create and are perpetually surounded by in those positions is just to mindnumbing that at least for me the money does not buy you out of that daily misery. But if you thrive on conflict, you can make some great money there.
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.
I guess that's how they make the money. Sell the platform and profit off the custom code.
Perhaps this could be addressed by providing a Pulumi or Terraform program?
Figuring out issues get more complex, scaling gets more complex, backup and recovery get more complex, now you need monitoring for it all too, and with many services the complexity multiplies.
All of that complexity is somewhat justified for a team that exists to build and operate the system (i.e. SaaS), but doesn't really work for a team who exist to build something else and have just been tasked with operating this.
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"
A bit more background as there is various bits of advice in these threads, and I will provide my take with scaling such a startup. Third-Party ERPs from the big vendors are purchased by Finance and are needed for validation pre-IPO and into the IPO (no one is going to trust something else without proof of success in publicly traded companies and it will be a red flag if there is no use cases in reputable publicly traded companies). ERPs are financial focused (like EHRs in healthcare), and their vendors will happily upsell the other addons like MES/BOMs, which are fine for generic manufacturing with limited SKUs. However in a world of customized/personalized SKUs, traditional ERP/finances solutions cannot be easily used to run manufacturing operations. I’d recommend focusing on integrating into ERPs (tack on custom IDs to the related objects) and automating them rather than building the full financial accounting/taxes into the platform. For example, your platform will still track the BOM details, but the totals will get synced for overall financial reporting for the various ledgers and not all the sub-assemblies which the ledgers don’t care about. This keeps the MES purpose built (and the big vendor ERP keeping simple books) and the ultimate source of truth what’s happening on the floor without getting into the accounting details that matter for tax optimization and not manufacturing operations.
I eventually handed my project over to another firm to continue development, as I became occupied with other, larger projects. It's still in use at my friend's shop, which now has about 80 employees.
I would still love to take another stab at it as I really wanted the system to have the ability to parse 3D files, for unfolding and automated quoting. Does your system already handle that? I browsed through your videos and saw that you at least had the preview part of it working.
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.
you can use the API from inside the codebase, or outside of it: https://github.com/crbnos/carbon?tab=readme-ov-file#api
The most important thing about ERP systems is - customization. IE: Scripting (netsuite), or even core programming (Sage100 for example). Not just user defined fields but workflows and being able to override and hook into core parts of the system. Say you want to override your cost basis for a certain productline or maybe serve different prices based on the shipping warehouse.
How do you approach that?
EDIT:
How do you handle the finances, G/L auditing, and allt hat financial wizardy?
customers.. they love PDFs. How do you handle generating things like pick lists, invoice sheets, etc? templating?
EDIT2:
One thing big ERPs provide is basically a cohesive way to extend. Not just an API in a RESTFUL sense, it's more akin to an IDE or like GTK+, there's almost everything rolled in for extension inside the 'world view' of the ERP. Every ERP makes some decisions and the rest of the world may flow, be that how you issue credit memos, handle multiple financial entities (do they all have the same chart of accounts? do they all have the same modules? Are there shared users) and so forth. How do you approach that? IE: when you need to slap something like PO's on top of AP, so basically AP + Items and a whole bunch more, does that "flow"? Do you receive those goods and they end up in your inventory for AR? etc.... Having an extensible system is great for addons and consulting, but the bigger piece is - for you, letting your ERP grow and add capabilities.
EDIT3: "Stripe" is not a billing techstack. Mostly CFOs make decisions about billing options, not us lowly tech monkies. Do you support pluggable vaults or anything akin?
i think open-source gives consultatnts and integrators super powers that they may not be used to -- everything currently has to be done through abstractions on abstractions. if you can just modify the source code, it becomes a little simpler i think.
take the PDFs for example. just make them how you want them in your instance of the software using the most popular tools on the planet (i don't mean crystal reports): https://github.com/crbnos/carbon/tree/main/packages/document...
Your value prop lands really well with the Software Architect in me. That part of my skill set loves the idea of creativity, flexibility, etc.
The Director in me does not want that. That sounds like a money pit, never done, management nightmare. What kind of dev do I hire? Do I need a Product Manager for that? How long will it take? Sounds too hard to get a win as a senior leader.
Most of the software in the adjacent space (and ERPs) have “prescriptions” or an ecosystem to get customizations done. Code may get deployed in a special assembly, a special SDK exists, etc
A prescriptive way to get the job done is much more preferred for predictability, even if it is not as loved by the developers.
I think Carbon is a neat and ambitious offering - happy to chat more with you if desired.
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)
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
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.
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.
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.
The problem for small businesses is ownership and tailoring/complexity. Self-hosted solutions sound great but you need someone that knows how to run it.
Cloud solutions sound great and every VC-funded startup (there is plenty) would love you to buy-in, but that's a massive operational risk to a small business that would become entirely reliant on it. That's on top of every ERP having different workflows and either having to adapt to one or customize it to match your small business. Small businesses often don't exist by copying the ideas and workflow of another company as several industries can be highly competitive and the smallest of "custom steps and processes" can eek out a tiny niche.
And then there's the "big brand, never going away solutions", but they cost a fortune beyond what any small business can afford and likewise need developers just to customize it.
So, with many small business owners, who most likely are not a HN user nor have a github account and work on stuff that has nothing to do with the web. They will look at the ERP offerings, look at their spreadsheet and say "yea imma just go with excel"
My dad has been a solo fabricator for most of my life, and what has always struck me was the way people came to him with jobs. Sometimes they'd show up with drawings and detailed designs, but mostly they'd just ask him to come look at something (or bring a photo), and describe the problem. He doesn't know CAD, so the drawings he makes are mostly just on napkins. The customers quite literally didn't know what they were getting before they got it, but that is fine, because they don't know what they want either.
I wonder if there's an analogue to that for software. A freelance local software developer these small businesses could go to if they had a process problem they'd like to solve.
Well it's hard to be as cheap as a spreadsheet.
Also, if you really wanted to, you could move back to a more traditional top menu where you have the section title, mousing over the section would open a menu (what is now your icons), and then if needed you could have a submenu underneath (what is your left nav with the words in your first Github photo). Discoverability would potentially take a hit but it's a different way of doing it.
If you have any other questions feel free to reach out, I like doing this stuff.
Edit: Another user suggested using AI enhanced chat to navigate around. This is a sign that the information architecture is WAY too confusing. AI agents shouldn't be utilized for navigation purposes.
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.
i'd also suggest to inline the left sub-menu: so much space under the left sub menu ends up unused. better to inline it at the top of the page, and widen the main content area.
anyway congrats on what you've achieved so far; looks great and best of luck!
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.
Maybe ERP is one of those things that co-evolves with the company, shaping the company as much as it's shaped by the company.
It evolves as we do with me making feature updates and bug fixes every few weeks. Of course this is unusual in that I’m a very technical owner, but I feel this is the right way.
As software becomes easier to make custom software will reduce in price as well. Software gives my company an edge and I’ll take every advantage I can get.
i don't know if you build anything custom, but we do have a configurator
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?
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.
"Techstack Remix – framework Typescript – language Tailwind – styling Radix UI - behavior Supabase - database Supabase – auth Upstash - cache Trigger - jobs Resend – email Novu – notifications Vercel – hosting Stripe - billing"
And no joke: congrats to your product!
the easiest one to replace is upstash -- the @io/redis is super easy to switch out -- i think the APIs are the same. but the others encapsulate an insane amount of complexity. my thinking is, if i -- as a fairly competent software engineer -- don't have the bandwidth to sysadmin 10 services -- how is someone whose running a manufacturing going to have the bandwidth.
the setup does suck, but imo it's the best solution for bang-for-the-buck long-term. interested to hear your thoughts!
- Who is 'I'?
- How do you see continuity if something were to happen to you?
- How does it stack up against ERPNext?
- Why did you decide to build an ERP system from the ground up?
- What is the deployment situation?
How does it stack up against Sage?
Expanding on "what is the deployment situation," how long should it be expected to take for full conversion to the Carbon platform from the described situation of discordant software that has been entrenched in a particular business's practice for decades?
here's a little bit about me, and why i decided to build this: https://carbon.ms/#memo
re: sage, i'd say that sage is well-known as being a great general purpose accounting software for multi-location, and multi-entity businesses. but i don't know of many manufacturers running on sage.
re: erpnext, also great. i love their open source model, their developer ecosystem, and great documentation. i'd say the major difference is the data model and the UI that it begets. in erpnext, i think everything is a "doctype" where with carbon things are more bespoke. each ui has it's own specific tables, and specific ui
re: erp
I'm surprised the carousel is slow, it's just framer motion. https://github.com/crbnos/www/blob/24d2b59150fc21e6b9c9df3b4...
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.
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.
- 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.
I remember their freezers where the guys wore special clothing and gloves but they still needed to be able to hit buttons on the computer.
Red flags with your site are: (a) seems to assume a sales order based process; (b) seems to assume B2C sales via Stripe; (c) has a huge bunch of layers but no actual user view.
I would suggest beginning your page with "Assumptions". In there, list all the things you have assumed.
Then I would suggest having a section for each area: ERP, MES, whatever, with a screenshot or two and a quick table based comparison vs. other tools.
Finally, include something about the layers you used and what they do. Nobody really cares about that stuff, it's almost developer documentation rather than user documentation.
I imagine a good approach that would solve some of my reservations would be a strict core ledger, especially as it relates to inventory and finance related transactions, but then relatively flexible around the specific product domain (we did craft beer, which in the end was a nightmare to map to the ERP processes)
Flexible where it matters, strict where it matters. Idk, but good luck!
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
What is the plan to monetize and support.
You'll never get market share without support, and that takes money. Support contracts. SLA's. Any company larger than 10 people aren't going to bother with something that doesn't provide support.
> Edit. Sorry. Had to click around a bit. 90$/Month for business. > Probably light. If business is 1000 people, this could be 1000$/month.
I have to add, I think all of the current tools that do have the market share, are not very good. So I do want something like this to succeed.
Besides, no one cares about “vendor lockin”. Every company of any size has a dozen plus SaaS products they subscribe to every month.
There was a thread a while ago about ERPs on a post about future start up ideas....i'll copy what I wrote there which you may find interesting...you may find that whole thread interesting:
'Ah ok. I'm an interested in this as a topic and would like to take a stab at this as I think it's an almost impossible project. I would like to caveat any opinion first by saying these: I have a great deal of experience customizing and creating little bits of bespoke functionality for various ERP systems (SAP obviously but also some of the smaller ones aimed at niche markets eg construction). I also have similar experience with similarly complicated and sprawling PLM systems. I've spent basically my entire software career around ERP and PLM systems and systems that break out pieces of ERP functionality and try to often do it elsewhere (usually badly), and then usually have to somehow bring everything back into an ERP system anyway, either manually or with at least some level of (but rarely complete) automation. I am a CS graduate from a 'famous' UK university (UCL). I'm also a qualified CAD engineer, project manager within agile (DSDM agile etc)...ITIL qualified etc. i.e I've spent a lot of time across these kinds of many tentacled systems that really do reach across the entirety of any large business. I've worked with these systems from FTSE 50 businesses to small 50 person manufacturing startups.
I've also been involved in the migration between PLM systems (horrible from a data perspective - all those CAD files etc) and also ERP systems (horrible but largely just the mapping between two different Entity Relationship Diagrams almost incomprehensible to any living human in terms of complexity).
It would be an incredibly ambitious undertaking to compete with one of the major players in either of these spaces. It is not something you could really even do at the scale of a start-up the likes of which YC and the media understand as 'start-up'. You would need so many not just 'early stage' founders with wildly different skillsets, you would need effectively an entire large manufacturing business, from end to end, in terms of personnel because your 'domain expert' essentially includes 'every business function you can imagine'. That's before you could even begin to think about software. It's a fascinating idea but think about it - procurement/purchasing, warehousing and logistics, engineering and design, sales and marketing, finance (very important here), HR, operations, R&D, Q&A...and these are just the ones I can think of that I have come across in my dealings with these systems. They really do touch every department.
The length of time to market would also be such that this kind of project would not really be appropriate to describe as a 'start up'. You'd essentially be creating a 'Unicorn Killer' and that unicorn killer would need insane resources to even have a chance at market success. The number and requirement for specialist migration tools into your new system from existing clients would be a 'massive' undertaking also.
It's such a bold idea but I think to describe an undertaking of that size 'start-up' would be to completely stretch the meaning of the term 'start-up' so far beyond its usage that the term would lose all meaning.'
Here is the original thread:
'https://news.ycombinator.com/item?id=39371805'
Good luck! I can't imagine trying this kind of project as a small team. You are very brave!
