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.
I was involved in all things ERP years ago. One thing I noticed was that the National Retail Association of the USA (the other NRA) have specification documents which would be perfect for basing both data models and transforms off. It seems all the big players tend to have almost, but not quite compatible models. It's very frustrating. We're talking SAP, Infor, MS, everyone. The amount of glue code I had to write to get various point of sale, accounting, BI, label printing etc software to work is astounding.
I guess that's how they make the money. Sell the platform and profit off the custom code.
> 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?
It's not just about the initial deployment, although these may help. If you're running Wordpress, the question "why is it slow" is pretty limited in scope – you need a faster webserver, database, or maybe need those two to be closer to each other. A simplification but not much of one. For this, is it the app server, the task queue, or one of several other components, or is it in the Supabase layer, or is it a dependency that someone else runs... etc.
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.
AGPL so I'd wager the idea is to sell this as a service while still allowing self-hosting, perhaps in the hope to gain bug reports, 'free' testing and some leads.
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.
When I worked in manufacturing we had an ERP system that was awful, and we ended up supplementing it with Excel spreadsheets and an Access database. I briefly started writing my own ERP system to replace the whole system, but I realized something: my ERP system would be hopelessly tied to our process at this company, and wouldn't be usable by the manufacturer down the street, which my buddy worked at, without extensive rewriting. Software of this kind has a tension between being general-purpose and being really good for one specific workflow.
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.
This I think will be the future. The ERP I made for my company is hopelessly tied to our process, and it saves time and reduces mental overhead for everyone.
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.
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
I'll bite. I am a ERP consultant in the SMB manufacturing and distribution space. Primarily we operate on Acumatica, Sage and Netsuite.
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?
these are all excellent questions! i think, interestingly, the answer to all of them is basically -- there's an off the shelf version that's opinionated and good. and if you want to take it a step further, you'd want to just modify the source code.
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.
I currently work in an ERP adjacent industry serving M&D. I don’t think this is as beneficial as you think it is.
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.
The problem with forking is that updating becomes a nightmare. Most ERPs provide a stable-ish API and heavily recommend customers to stick with it, because then automatic updates just work.
I think that's going to be a very hard sell in nearly every scenario. In addition to vendor lock-in you'll then also have people on payroll only to keep your vendor lock-in functional.
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.
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"
TLDR Brad: I’d suggest you look at any customers with potential scale, who should have a custom SKU/BOM/order mix. 3D printing and full custom made to order products will have this mix, and it gets increasing painful when scaling past 100s of orders per month. One will find there will be in-house systems and workaround to deal with this complication, which should be fixed decently once a company is in the 1000s of orders per month by necessity of survival.
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 worked on a very similar system for a friend's laser fab shop using the Roda framework (Ruby). Since Tailwind wasn't available at the time, I had to rely on Bootstrap. The project was quite similar to what you've done, although I stopped short of implementing job scheduling and live job tracking. I really love your execution...especially the UI.
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.
Gotta have your G/L tied to your whole system. How else can you do project billing or Make-To-order quoting and have it roll your Cogs and such over to the G/L....
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.
What exactly is an “ERP”? Virtually everything I read about them or on the website of products, is so vague and broad that it sounds like “it’s everything”. How would a business know they need this product? For the big ERPs out there, is there a clear guide with screenshots that show what they concretely do?
Basically the core functionality is to track inventory, manage purchase orders in, and sales orders out. Generally that's also linked to accounting so basically as you buy and sell stuff everything is linked to your accounting ledgers.
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.
Not all materials are parts. For instance, if you run a soup factory you don't order 'soup parts' but bulk ingredients in the same proportions that you end up selling, but there are many other things that you need to worry about in the process of preparation and there are things that don't even make it into the end product at all that you still need during the manufacturing step (for instance, cleaning products, various chemicals). So 'basically parts lists' is a bit of a shortcut.
They do lots of things that’s the problem…
The key items in my experience are: 1. Finance/accounting processes 2. Supply chain processes (for product companies) 3. Project/Services processes (for consulting companies) 4. Procurement
They can have other things like: sales, customer service, order management, payroll, HR, projects, warehouse or factory management, materials management and so on.
A key decision in very large companies is whether to go with one ERP that does most things and they having to integrate the rest (tedious, expensive), or many smaller apps that might be best in class for their niche then having to integrate them (also tedious, expensive)
Thank you for expanding the acronym. I’m always surprised the acronyms aren’t expanded in projects website. This gives me the impression the developers are embedded in the status quo of the problem domain.
I've worked on a erp for a short while and I genuinely still don't know. The amount of bullshit surrounding them is certainly staggering.
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 major ERP vendors do not price based on product or services delivered, but they will just make a price based on your revenue.
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.
It's a type of software that lets business manage and automate core processes in one integrated system. Typically linking finance/accounting with operations like sales, inventory and manufacturing.
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.
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.
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.
I am setting up a large manufacturing operation now.
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 did an ERP implementation for manufacturing years ago, it was such a nightmare.
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!
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.
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.
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)
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.
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.
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.
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
imo, these (supabase, trigger, upstash, novu) are the best hosted solutions in the world, but they are all self-hostable/apache/MIT.
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!
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
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.
Good questions. I'd like to add some, if you don't mind.
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?
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
Congrats on this! Quite interesting for me as I have been working on vertical ERPs for a while, not at all related to manufacturing and as far as I know, accounting is usually the core of any ERP. Who is your ICP at companies in your target groups - ops managers? I’ve mostly seen CFOs being the drivers behind ERP purchasing.
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?
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
Wow how have I never heard of OFBiz? I’ve been keeping an eye out for a good self hosted erp forever and thought ERPnext was as good as it gets but this sounds super.
I'm in this industry and very interested in efforts like this.
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.
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.
I just wanted to throw my 2 cents, I work in IT and in meat processing there is perhaps only one or two software products that does catch-weight processing well due to the time constraints and custom labeling. If you can do that well you stand to gain a lot in that industry. It doesn't look like you guys are focusing on specific industries, but I actually think you can provide an incredible value to real businesses by doing so.
Most companies that want an ERP systems are not and should not be a software development shop. They hire an outside consulting company and sign a statement of work. They aren’t going to want to use a non standard offering.
Besides, no one cares about “vendor lockin”. Every company of any size has a dozen plus SaaS products they subscribe to every month.
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"
I've been thinking about something similar. I think there's a market for "local handmade software" in cases like that, where a software developer can come in and build a little system tailored to a specific problem they have.
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.
founder here. i often advise people to use excel (or some web-based). it's excellent software, and often the simplest way to solve a problem. it just gets untenable as the company gets bigger.
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?
So you could try grouping icons into sections, labeling the sections, and then clearly delineating the space between said sections. For example, you could have small text in all bold and all caps as the section title. Another user suggested using text with the icons, which is good for accessibility. Also, looking at the first screenshot in your Github, you could completely merge the left icon only nav with the nav directly to its right. This could result in saving some space.
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.
if you're gonna keep the left icons-sidebar, its probably a good idea that you label the icons - i think its mentally exhausting for all users to remember what each icon stands for all the time, and also you may want to change the icons themselves in future.
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!
Hm, interesting. With how slow the testimonial carousel on the web page is though, I don't have much confidence that Carbon is performant either. How many pieces of that (frankly massive) techstack require dedicated network trips?
We try to hit the cache as much as possible, and all fetching is done in parallel with Remix. We try to make heavy use of their defer function to only block on the most important data, and await the other data. Remix has the option to merge all parallel requests into a single fetch, but it didn't work for us because we use a hybrid strategy for hosting (where the most common pages are served from v8 edge functions and the less common stuff is served by node functions). The reason we don't put everything (basically) into the edge runtime is because vercel only gives you 2MB of code in the edge runtime before you have to pay HUGE money. But I've definitely put a lot of thought into the performance, so I hope it's great.
This is all cool but i think traditional erp systems are going to get eaten away by software like Optifye.ai, using vision for counting, and then certifying through manual data entry. If there’s no Vision integrated into your erp, you’ll get eaten away by competitors who run faster lean teams through using such systesm
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.
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.
There are a lot of sensible comments on this thread but seems not a very strong consensus. I can see why! ERP is an extremely complicated space...
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.'
Hey guys, Jeremy from UMH (www.umh.app) here. We are OSS as well and focus on data infrastructure for manufacturing. Let me write you guys via Discord to get in contact
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.
I was involved in all things ERP years ago. One thing I noticed was that the National Retail Association of the USA (the other NRA) have specification documents which would be perfect for basing both data models and transforms off. It seems all the big players tend to have almost, but not quite compatible models. It's very frustrating. We're talking SAP, Infor, MS, everyone. The amount of glue code I had to write to get various point of sale, accounting, BI, label printing etc software to work is astounding.
I guess that's how they make the money. Sell the platform and profit off the custom code.
This resonates with me a lot. Can I contact you? My email is in my profile.
3 replies →
> 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?
It's not just about the initial deployment, although these may help. If you're running Wordpress, the question "why is it slow" is pretty limited in scope – you need a faster webserver, database, or maybe need those two to be closer to each other. A simplification but not much of one. For this, is it the app server, the task queue, or one of several other components, or is it in the Supabase layer, or is it a dependency that someone else runs... etc.
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.
1 reply →
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
AGPL so I'd wager the idea is to sell this as a service while still allowing self-hosting, perhaps in the hope to gain bug reports, 'free' testing and some leads.
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.
When I worked in manufacturing we had an ERP system that was awful, and we ended up supplementing it with Excel spreadsheets and an Access database. I briefly started writing my own ERP system to replace the whole system, but I realized something: my ERP system would be hopelessly tied to our process at this company, and wouldn't be usable by the manufacturer down the street, which my buddy worked at, without extensive rewriting. Software of this kind has a tension between being general-purpose and being really good for one specific workflow.
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.
This I think will be the future. The ERP I made for my company is hopelessly tied to our process, and it saves time and reduces mental overhead for everyone.
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.
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.
1 reply →
I'll bite. I am a ERP consultant in the SMB manufacturing and distribution space. Primarily we operate on Acumatica, Sage and Netsuite.
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?
these are all excellent questions! i think, interestingly, the answer to all of them is basically -- there's an off the shelf version that's opinionated and good. and if you want to take it a step further, you'd want to just modify the source code.
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...
I currently work in an ERP adjacent industry serving M&D. I don’t think this is as beneficial as you think it is.
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.
The problem with forking is that updating becomes a nightmare. Most ERPs provide a stable-ish API and heavily recommend customers to stick with it, because then automatic updates just work.
I think that's going to be a very hard sell in nearly every scenario. In addition to vendor lock-in you'll then also have people on payroll only to keep your vendor lock-in functional.
i should also say that the accounting is a WIP but modeled on Dynamics 365 - with posting groups, item ledgers, cost ledgers, and general ledgers.
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.
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"
TLDR Brad: I’d suggest you look at any customers with potential scale, who should have a custom SKU/BOM/order mix. 3D printing and full custom made to order products will have this mix, and it gets increasing painful when scaling past 100s of orders per month. One will find there will be in-house systems and workaround to deal with this complication, which should be fixed decently once a company is in the 1000s of orders per month by necessity of survival.
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.
5 replies →
I worked on a very similar system for a friend's laser fab shop using the Roda framework (Ruby). Since Tailwind wasn't available at the time, I had to rely on Bootstrap. The project was quite similar to what you've done, although I stopped short of implementing job scheduling and live job tracking. I really love your execution...especially the UI.
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.
Gotta have your G/L tied to your whole system. How else can you do project billing or Make-To-order quoting and have it roll your Cogs and such over to the G/L....
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.
1 reply →
What exactly is an “ERP”? Virtually everything I read about them or on the website of products, is so vague and broad that it sounds like “it’s everything”. How would a business know they need this product? For the big ERPs out there, is there a clear guide with screenshots that show what they concretely do?
Basically the core functionality is to track inventory, manage purchase orders in, and sales orders out. Generally that's also linked to accounting so basically as you buy and sell stuff everything is linked to your accounting ledgers.
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.
The M is for “material”. Material Resource Planning.
Not all materials are parts. For instance, if you run a soup factory you don't order 'soup parts' but bulk ingredients in the same proportions that you end up selling, but there are many other things that you need to worry about in the process of preparation and there are things that don't even make it into the end product at all that you still need during the manufacturing step (for instance, cleaning products, various chemicals). So 'basically parts lists' is a bit of a shortcut.
1 reply →
They do lots of things that’s the problem… The key items in my experience are: 1. Finance/accounting processes 2. Supply chain processes (for product companies) 3. Project/Services processes (for consulting companies) 4. Procurement They can have other things like: sales, customer service, order management, payroll, HR, projects, warehouse or factory management, materials management and so on. A key decision in very large companies is whether to go with one ERP that does most things and they having to integrate the rest (tedious, expensive), or many smaller apps that might be best in class for their niche then having to integrate them (also tedious, expensive)
And ERP is Enterprise resource planning.
Thank you for expanding the acronym. I’m always surprised the acronyms aren’t expanded in projects website. This gives me the impression the developers are embedded in the status quo of the problem domain.
This blog post from Retool was really helpful for answering that question: https://retool.com/blog/erp-for-engineers
That was a good read! Thanks
I've worked on a erp for a short while and I genuinely still don't know. The amount of bullshit surrounding them is certainly staggering.
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.
> internally transforming the company
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.
5 replies →
The major ERP vendors do not price based on product or services delivered, but they will just make a price based on your revenue.
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.
3 replies →
Can you say who? Curious who in todays market is spending billions on a new ERP. I'd think the market is pretty dry right now.
1 reply →
It's a type of software that lets business manage and automate core processes in one integrated system. Typically linking finance/accounting with operations like sales, inventory and manufacturing.
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.
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.
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.
Is there a reason for such an arrangement? Why would Tesla not use SAP as their backbone ERP too?
2 replies →
Does the ERP allow you API access, or do you need to do CSV upload/download?
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
API and direct database access.
I am setting up a large manufacturing operation now.
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 did an ERP implementation for manufacturing years ago, it was such a nightmare.
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!
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?
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.
I see, I was under the impression that Carbon encompassed sales and factory floor too. Now it makes more sense. Thanks!
2 replies →
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.
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)
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
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.
1 reply →
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.
1 reply →
this is a big issue in healthcare, a chunk of my last company's revenue was doing MDM for large medtechs.
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.
2 replies →
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
Is this a kind of developer BINGO? ;-)
"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!
imo, these (supabase, trigger, upstash, novu) are the best hosted solutions in the world, but they are all self-hostable/apache/MIT.
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!
Yeah, that's a lot of hosted solutions for an ERP.
a new "MERN" stack of web development post covid era
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
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.
Impressive. Some questions:
- 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?
Good questions. I'd like to add some, if you don't mind.
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?
hey guys -- founder here.
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
2 replies →
Congrats on this! Quite interesting for me as I have been working on vertical ERPs for a while, not at all related to manufacturing and as far as I know, accounting is usually the core of any ERP. Who is your ICP at companies in your target groups - ops managers? I’ve mostly seen CFOs being the drivers behind ERP purchasing.
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?
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
You're responding to an LLM by the way.
Ah gotcha. Makes sense to get the benefits of modular adoption without the headaches. Nice approach.
How's it compare with Apache OFBiz and the things people are building on top of that?
Wow how have I never heard of OFBiz? I’ve been keeping an eye out for a good self hosted erp forever and thought ERPnext was as good as it gets but this sounds super.
Well for one more modern UI, I suspect??
I'm in this industry and very interested in efforts like this.
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.
This has repo has a great prebuilt llm docs sections. This seems like a killer feature for clients who want to roll their own customizations.
https://github.com/crbnos/carbon/blob/main/CLAUDE.md
https://github.com/crbnos/carbon/tree/main/llm
How does this compare with the manufacturing capabilities in ERPNext?
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.
I just wanted to throw my 2 cents, I work in IT and in meat processing there is perhaps only one or two software products that does catch-weight processing well due to the time constraints and custom labeling. If you can do that well you stand to gain a lot in that industry. It doesn't look like you guys are focusing on specific industries, but I actually think you can provide an incredible value to real businesses by doing so.
Years ago I added a catch-weight extension to an ERP for a meat distributor.
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.
For me this is a space that has been long dominated by MRPeasy--it's just such a perfect fit. Happy to see open source solutions slowly catching up.
Most companies that want an ERP systems are not and should not be a software development shop. They hire an outside consulting company and sign a statement of work. They aren’t going to want to use a non standard offering.
Besides, no one cares about “vendor lockin”. Every company of any size has a dozen plus SaaS products they subscribe to every month.
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.
It is both underserved and overserved.
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"
I've been thinking about something similar. I think there's a market for "local handmade software" in cases like that, where a software developer can come in and build a little system tailored to a specific problem they have.
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.
Many large businesses still use Excel! You'd be surprised how much commerce is enabled by spreadsheets.
> a "tarpit idea" (deceptively attractive but actually unscalable, time-consuming)
Well it's hard to be as cheap as a spreadsheet.
founder here. i often advise people to use excel (or some web-based). it's excellent software, and often the simplest way to solve a problem. it just gets untenable as the company gets bigger.
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?
So you could try grouping icons into sections, labeling the sections, and then clearly delineating the space between said sections. For example, you could have small text in all bold and all caps as the section title. Another user suggested using text with the icons, which is good for accessibility. Also, looking at the first screenshot in your Github, you could completely merge the left icon only nav with the nav directly to its right. This could result in saving some space.
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.
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.
14 replies →
if you're gonna keep the left icons-sidebar, its probably a good idea that you label the icons - i think its mentally exhausting for all users to remember what each icon stands for all the time, and also you may want to change the icons themselves in future.
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!
I have no idea why you’re using icons for 13 things. Use words.
Hm, interesting. With how slow the testimonial carousel on the web page is though, I don't have much confidence that Carbon is performant either. How many pieces of that (frankly massive) techstack require dedicated network trips?
We try to hit the cache as much as possible, and all fetching is done in parallel with Remix. We try to make heavy use of their defer function to only block on the most important data, and await the other data. Remix has the option to merge all parallel requests into a single fetch, but it didn't work for us because we use a hybrid strategy for hosting (where the most common pages are served from v8 edge functions and the less common stuff is served by node functions). The reason we don't put everything (basically) into the edge runtime is because vercel only gives you 2MB of code in the edge runtime before you have to pay HUGE money. But I've definitely put a lot of thought into the performance, so I hope it's great.
I'm surprised the carousel is slow, it's just framer motion. https://github.com/crbnos/www/blob/24d2b59150fc21e6b9c9df3b4...
EDIT: i'm going to remove the framer motion -- you're right. it's not helping. i've also got to optimize these images, but that's for another day.
Tangent thought as I've been trying to adopt new programming language. I'm amazed how prolific is typescript in open source project space.
Congratulations on launching! Just curious, why open source vs making a free plan?
founder here. i see open source as a better API for connecting it to other systems
Accounting is still not checked off. Has anyone done integrations with FLOSS software like GnuCash?
This is all cool but i think traditional erp systems are going to get eaten away by software like Optifye.ai, using vision for counting, and then certifying through manual data entry. If there’s no Vision integrated into your erp, you’ll get eaten away by competitors who run faster lean teams through using such systesm
What vertical ERPs does it replace?
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.
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.
2 replies →
There are a lot of sensible comments on this thread but seems not a very strong consensus. I can see why! ERP is an extremely complicated space...
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!
Great UI! Congrats on the launch
Hey guys, Jeremy from UMH (www.umh.app) here. We are OSS as well and focus on data infrastructure for manufacturing. Let me write you guys via Discord to get in contact
Simply use SAP.
There is no such thing as "Simply Us[ing] SAP".
[dead]
[dead]