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.
Feel free, my email is my HN username at gmail. As I mentioned in a sibling comment, I'm not in tech anymore (except for fun) but I'm happy to provide any insights or advice to any questions you may have. I last worked with ERP systems about 10 years ago, but the thing about these systems is that they don't really change, so hopefully my knowledge is still helpful!
As a quick summary, this is mostly all ETL (Extract, Transform, Load). Learn the lowest practical level language you can for each system so you can extract / query exactly the data you need (in SAP it's mostly SQL but there are a bunch of proprietary "languages" and extensions that can help. In MS it's mostly SQL, in Infor it's worth learning some RPG /CL, but only enough to get the data you need). Learn the notification paradigms each system offers (this can be as simple as scheduling jobs, it can be file-system watchers, it can be RPC based, etc. etc. Each system is different, but you need to know when to do stuff with the data. Both on change from external influences, and on completion of whatever job you ran). Thirdly, utilise a modern language for the "Transform" and "Load" phases of the job. I used to use everything from C, C#, Perl, Python, etc. These languages are much easier and much more powerful than something like RPG or pure SQL for a non-maestro. There are people who use complex stored procedures for everything, and that's cool, but it's also a steeper barrier of entry than using a modern, "batteries-included" language.
The reason I initially taught myself Go (13 years ago now) was due to the incredibly powerful and simple data manipulation packages built into it's standard library. It's a damn good language for doing high speed, low latency transformation of lots of data, while being simple and easy to code and deploy. Having said this, the afore-mentioned C, C#, Perl and Python were all working fine before I switched to Go! Use what you know, and what's available in the sytem you're working on.
If you have any questions feel free to send me an email.
True, but I'm not actually in tech anymore. I still have a consultancy business, but I make money doing geo-technical rope-access work now. A bit of a sea-change.
I'm happy to impart my thoughts on this topic for free, but I'm not sure how useful they would be after almost 10 years!
> 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.
There's also the issue of having a dozen moving parts form the system, each developed for their own reasons. So you could find that upgrading one product changes something, say collation for utf-16, which might be entirely reasonable taken in isolation but that the rest of the system is unprepared for.
It is up to you to fend off dozens of small things. Over time that accumulates. It's like python programmers using two dozen pypi dependencies because they've heard nih is bad. Or think nodejs if that's your thing. What you do in practice is you freeze everything in place and then you postpone it all for an increasingly indefinite future. Organizations then periodically need to freeze work for weeks or even months at a time just to keep up with dependencies. This is clearly a lot of work.
Terraform, or even better Ansible, is a good choice to document make those changes over time in a standardized way. But it doesn't make the work go away. The work is there and still has to be done. Those tools also clearly suffers from the same many-moving-parts problem, as soon as you include external modules with their dependencies too, so you have take care not to magnify the problem by accident instead.
This is what system admins and integrators do all day. They will tell you in unison that the best integration is the one that doesn't exist.
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.
really well said, imo! it's interesting how there's two views of ERP. one is a G/L + anything needed to support it. and the other is more of a tool that supports operations and planning. i started with a G/L, but have kept it hidden even now, because my thought it that everything else should be good first, and support the G/L second.
Operations and planning are performed when one’s company fits the mold of a classic business. The system you are building suits the companies that break the mold, which is a growing number as personalization/hyper customization grows.
3D print manufactures that print custom parts need to use their manufacturing and billing operation outside the mold. Unixhero provided another example, but there are a lot of examples where big ERPs aren’t the right solution and/or require a lot of money/customization/ongoing costs to make it work well beyond its total ROI.
Anything which needs detailed operations planning of the production. Larger factories and say chemical companies use standard flows of the ERP (SAP) for this.
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.
Yes. Most ERP's also handle 'ingredients'. Really, it is any 'inputs' to the product. And potentially, byproducts produced and also sold. All In's/Out's, and how to track them.
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.
Oh that brings memories! Been in quite a few of those.
Basically the ERP vendor sells you the software and estimates that you need a couple months and a couple consultants for the migration and integration, plus a few users of your product as guinea pigs. It is expensive as heck but well, at least it is only two months (plus hotels, plane and food).
After two months you’re halfway done according to the vendor but you need some extra helping hands for the harder features, so you get more consultants, and a department to handle change. You get a few posters.
After a couple years you have eight consultants and a consulting product manager still doing the migration work, plus eight more freelancing ERP experts, and about four engineers from your own team working full time on apis. The work is halfway done, though! Your non-tech staff is juggling between two products and dissenting voices start to appear. You make and distribute t-shirts with texts like “Project Evolution” or “Project Future” to ensure everyone is on board.
After two more years you are almost halfway there, but staff turnover guarantees that people don’t remember the productivity of yore, and the new ERP is judged as good enough. People have gotten used to it, the jokes aren’t as vicious as before, and only a handful of people were fired in the previous years due to the company going severely over budget. But hey nobody gets fired for buying IBM so the boss who decided to blow 15 million on it is fine.
I've seen this balloon to hundreds of consultants. It can break a company. You get huge sunk cost into you're continually 90% done ERP and management either doubles down to spend one year to just get it barely working and stop, or cancel it.
In my experience companies end up paying as much money as they can.
The companies themselves are to blame, too: they absolutely refuse to change their processes, so the software must adapt to them, no matter what the cost.
Even my grandfather once told me stories of this happening in the 70s when the company he worked for was sold and the new management brought new software, or my parents telling similar stuff from the early 90s.
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.
I worked on an ERP system for construction/architect firms in the 00s. The company was about 15 people when I joined, 40 when I left.
We consistently delivered migrations, but we hand crafted SQL extraction scripts, with data cleaning, etc. You could fully customize it, branding it with your own logos/colours/custom css, etc. There was just a clause that the "powered by" link had to stay visible.
I can't remember a single failed migration, though we were split into three "teams" each covering a different set of customers, so might have not seen one.
I suppose we were fairly small scale, and maybe those were the days where some serious attention to detail and care of the customer were still possible as generally we were replacing paper based workflows, not trying to migrate existing electronic workflows with huge data volumes.
But it's perfectly possible to do (and we worked with some fairly big companies in the space).
One of the funniest, yet saddest, support calls I remember getting was being asked "What do we do with Sue now, we don't have anything for her to do anymore?".
So it entirely depends on your implementation team I think. It's possible to do it well. But you probably need a very good set of consultants. If your ERP trainer is coming in and immediately setting up conflict with your company, that's definitely not a good sign.
Small scale is definitely another world entirely. My experience was not in the Billion dollar range as the parent, but in 20M+ (probably 50M in today's dollars) project territory.
> 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
There's an additional catch to that old argument as well. If you actually do what they say, and stick to all the templates. Well guess what, they're all going to change with next update as well and now you need to change all your business processes at the same cadence as they happen to update their software. You still have to adapt to the changes of the system, it's just not the IT departments problem.
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.
Yeah, but we're talking Tesla here, not some run-of-the-mill carmaker. In fact, given SAP's rep in German manufacturing, they might have even been a net positive for Tesla.
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.
ahh, it does -- but there's a slight hair to split.
on sales, carbon supports quoting, sales orders, invoicing, configurator, etc -- but it does not attempt to create a website for you where you can list your products and their configurations. the idea is that you have a site, the site sends info to carbon through the API (whether it's a quote or an order), and then things begin from there.
similarly with production except that the shop floor is pulling intstead of pushing. carbon manages the schedule, the jobs, the capacity planning, etc. and provides a UI for guys on the shop floor to record their time and materials. but if you want to interface with a machine, you'd be pulling information out of carbon through the API, and relaying it to the machine.
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.
the product was commercial analytics for healthcare sales teams. We worked with our customers (medical device & biotech commercial teams) to define granular patient cohorts (patients with a specific disease and specific pattern of treatment) and then analyzed provider (doctor / facility) interactions with those patients.
One onboarding problem was always - here's what I know about the doctors / facilities I care about, help me understand what I don't know. Well, what they knew was usually in a CRM, with very poor hygiene, or some ERP - dat assembled by hundreds of sales and ops people over years, sometimes decades. So generally the first step for us was to do an MDM exercise to join their data to ours.
This had a huge pay-off for both parties. For us we were able to make our product much more useful to them. For them, they now had a map of their territory they could use across multiple business units, multiple therapeutic areas (these usually operate independently and sometimes sell to the same buyers!)
I'm seeing the same opportunity/challenge in my new company, but this time focusing on the supply chain of these companies.
Super interesting. I had the same experience trying to connect a CRM with various tools and the data was typically an absolute mess. It's a hard problem.
Would you be open to chat further? I'm not sure if I can help you or not without learning more, but I'd love to better understand what you're seeing at minimum for research purposes. My email is in my profile.
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
Interesting, since the past two manufacturers I have worked for in the last 16 years both have Sage as their primary ERP...BUT that directly resulted in them needing a bunch of other software strapped to the side of it to get things done, which sounds exactly like the problem Carbon was made to solve.
I had even taken it upon myself to develop a (very rudimentary, but functional) piece of software to manage the Service Department of my current employer, since RMAs/Repairs were still being handled with paper and email when I arrived a few years ago, Sage apparently lacking a suitable module as well as the looming shadow of "that's the way we've always done it" thinking.
Carbon looks like it would trim a lot of the thorns my current employer gets hung up on, but it would take some serious convincing to migrate over given the entrenchment of old and comfortable habits, inefficient though they may be.
Anyway, thanks for the response, I know you folks are busy.
i appreciate you talking through it with me! i only have my limited experiences, and the term ERP is pretty fuzzy -- a CFO's view is a lot different than a head of production.
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.
like a cmd+k type deal or something different? we do have cmd+k navigation to everywhere currently + global search, but i worry that less sophisticated users might not use it.
No, I mean, like a copilot style AI assistant, the user can chat with to ask what they want to do, and either the assistant can operate and navigate the UI to the right place, or perhaps even shortcut the steps for the user by asking for questions to satisfy inputs for the thing they are trying to accomplish.
An example:
- user intent is to update an attribute for a component part number A21445
- user can click a chat bubble icon in lower right and chat to the assistant
- user describes their intent - "help me update the description for part number A21445
- system replies by informing the user it will open the right screen, opening a part/component editing UI, with the right part loaded, with the cursor positioned in the description field, and the assistant stays open for further assistance; or;
- system replies that it found the part and can update the description, shows the current description for the user, asks "what description do you want?"
- user enters updated description
- system confirms the change is correct
- user confirms the change is correct
- part/component description is updated without even opening the UI
FWIW, it's great that you have cmd-K and also I've seen those kind of search boxes get more smarts like being able to type "part:A21445" to go directly to a specific UI.
I just suggested the above as we learned some interesting user experiences became possible when our AI assistant had the ability to control our UI directly on behalf of a specific user.
An example in the app I worked in (a web based data pipeline tool):
- "Hey assistant, can you help me add some SQL transformation logic to dataflow ABC, to process the customer data?"
- system uses metadata and knowledge of the UI to open the right dataflow, select the right type of UI to open to enable the user to add a SQL query in the right place, maybe even autogenerate the initial SQL query - this all from the main home page of the app, from a side panel chat assistant.
- net result feels like talking to the assistant to operate the app, almost no clicks required.
Instead of arranging things in a logical hierarchy, and enabling quick navigation thru keystrokes - just toss out making the ui make sense because the chatbot can solve all.
Your job is to make a good product. AI-as-interface is just slapping a layer of randomized language parsing in between the user and bad ui.
I’m not actually saying no chatbots. What I am saying is using a chatbot to solve a usability problem is a massive middle finger to anyone who might have to use your product for 8 hours a day. Make it good, then make it idiot-proof. Don’t make it for idiots only.
I used to work in green screen text based UIs from the 80s (TUI).
Power users didn't need search or anything else - they memorized the keystrokes to navigate the text UI and could just type key combinations to blaze through the UI faster than it could render on the screen.
I've never really seen anyone able to replicate that UI in a browser based or GUI desktop app to be honest.
Power users are a different use case, although the end goal is to remove the need for clicks.
I don't believe chatbots/AI assistants are a panacea, definitely encourage the architects of this new ERP platform to weigh the pros and cons.
That said, two jobs back I worked for a major manufacturing company that used the old GUI destop based Oracle EBS ERP. To automate repetitive workflows they were trying to implement UIPath (RPA automation - it drives the UI for the user) on top of the GUI.
This is what lead me to believe that if the ERP application's functionality is discoverable by an AI assistant, it can be used to automate or navigate on behalf of the user, or as part of complex workflows.
That can be done later after the basics are addressed - my only advice would be to just consider it sooner, even if you don't build it first.
It's a little easier to think of how one might simplify the workflows and design for automation into the core of the product, via the UI, APIs, etc earlier than later.
But in general - focus on the user's needs first and different roles/personas - just don't completely ignore new types of automation workflow opportunities (i.e. AI assistants/chatbots).
If the product is API based then it's possible to use a TUI library and make an app that someone can keyboard their way through and have it talk to the mothership through the APIs.
the trouble is that there are 1000s of possible mutations -- and the quality of an agent tends to diminsh with the amount of "tools" you give it. i need to figure out the right abstraction for this.
I pray you focus on your core product and don’t fall into an agentification rabbit hole.
If you do want everything to be automatable take a page from Blender and give every action a key binding plus a Python method, so Python scripts can take the same actions a human would, but as function calls instead of clicks. Then maybe maybe maybe you can have a text field that allows natural language to transform to an action, but please god stay away from chat interfaces.
Rhino CAD is another interesting interface to look at, there’s a million buttons and menus but there’s also a text field at the top of the viewport where you can just type a command if you already know the name instead of rummaging through submenus. Kind of a CLI within the GUI.
I somewhat agree with you, especially that one could identify a common abstraction that later an LLM could piggyback on top of.
Genuine question though - have you implemented an AI assistant/chat interface recently using LLMs on top of a UI?
I agree it can be a rabbit hole, but I just got through doing it on an app and there were definitely some things it really made way simpler and some complex scenarios that I'm not sure could have been done any more simply.
I built a chat interface in 2017 (this was with chatscript dialog trees with hole-filling and semantic search) that was ostensibly to prevent our data scientists from redundant work, ie, before they spent all day writing a SQL script, describe the job of the script and see if one already exists. The chatbot would then ask for the parameters required for a script, run the job, and then present a CSV of the returned data.
As we collected user feedback and refined the UX, we got closer and closer to an option tree that could be better represented by a drop down menu. It was kind of depressing, but I learned that the actual job of that R & D wasn't to come up with a superintelligent chatbot that replaced data scientists, it was to come up with the infrastructure that would allow data scientists to put their python scripts in a common repository to allow re-use without re-installing locally and screwing around with pyenvs.
Anyway, I'm also traumatized by my involvement with a YC startup that actually had a very good (if ENRONish) product around peer to peer energy futures trading that completely fell apart when investors demanded they make it "AI"
Sorry to here about your bad experience. I do understand it, as when the hype cycle causes perfectly good things to be thrown away or messed up for no practical reason, it really bugs me too.
In this case, it's so easy for some to say everything else is bad if it is not AI, or you have to include AI "because it's the future".
I just wanted to clarify that I am very pragmatic in my approach to new tech and AI.
I used to work on enterprise ERP, MRP, sales and support systems (Oracle, Salesforce, ServiceNow, and more)... not always by choice.
At one point a project came up to rebuild our core customer experience portal across our business. I got to build with the rule based chatbots to implement an assistant in that web app.
Not easy, but it worked well enough, especially for simple scenarios. For example, imagine a field support engineer being able to pull up the exact page in a big technical document for some obscure part by just asking for what they need, in seconds.
Or, being able to reorder some quantity of part by just asking for it, or checking the quantity of same.
These are time savers, especially if you have a voice to assistant interface too. So you can just type something, or ask for what you need without typing.
Tablets were common for manufacturing, inventory or service staff. Being able to pull up our interface and just say what they needed and get prompted for simple things - there were TONs of pragmatic small wins there.
Current LLM just make that easier than the old rigid rule based way we had to code those assistants (at the price of going wrong sometimes).
I care about efficiency, pleasant user experience, and pragmatics.. not AI for the sake of AI.
All that to say, if a drop down box works better for some use case, instead of AI - or even a rule based chatbot - hell yeah! Save on them tokens.
I agree with the right abstraction and it's tough to find the balance- in our data pipeline app, what we did is make key core functionality of the app exposed so the assistant can use it, and implemented a handful of basic agents out of the box, including one default one that could shell out work to others. We also made it easy as an extension point for users to add a new agent that used the core functionality/tools, just by defining the agent in a markdown file.
We found starting small for critical use cases that saved the most time, but thinking about building blocks, was useful.
Because the responses of the AI assistant come back and are processed on the UI, we found we could give the LLM our UI docs as well as knowledge about UI element IDs, etc so it could respond with input commands that would drive the UI.
This way, we could do something like, provide the LLM with the input/prompt including the context of like - what page/view is the user on, what is their intent, what tools are available in general, what sub agents are available for specialized tasks, etc.
Please don't let my suggestions sway you away from core progress in your app (take with a grain of salt). But it's great you're already experimenting- keep your eyes open if you see a great use case where it accelerates workflow.
Another HNer mentioned people not reading docs- that's a low hanging fruit use case we had too - "how do I use this view?", "what does this field mean?", or retrieving information from other parts of the app without having to navigate away, etc. It can save having to find answers in a doc or navigate elsewhere.
Edit: perhaps a useful exercise - imagine a workflow of "talking to the app to achieve a task" as a way to explore.
"Hey ERP, open the part entry screen for part 12345"
"Hey ERP, can you update the description for part 12345 to correct the spelling error?"
"Hey ERP, how many of widget XYZ are in stock? If there are enough in stock, can you transfer quantity 10 from warehouse A to B?"
"Hey ERP, how do I cancel a sales order?"
"Hey ERP, how does this screen work?"
I think if you break these down, you'll find common abstractions that map to features, API endpoints, user interface sequences and interactions, triggering workflows, looking things up in docs, etc.
Please share the feedback for keyboard shortcuts from real users. Now shops in India tend to use touchscreens or have staff fiddle with laptops with tiny touchpads, but lots of shops use ERPs (Tally) with 90s UI that dont need mouse.
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.
Mincom, a Brisbane based tech company started in the late 80s with a suite for mining, and oil/gas production. At the time, they had 1-10 customers who paid a LOT of money. I am sure they are bigger now, but the fundamentals here are the same: you have to maintain almost every version of product back to the origin, and backport any change, because you can guarantee there is a mine in Kazakstan making a very large amount of profit, which is unwilling to upgrade, but is willing to pay you to maintain the legacy codebase.
TL;DR -If you support mining, expect to support the FORTRAN code you shipped them in 1960s.
Indeed. That was the very company I was thinking of! The Mincom EAM product (Ellipse) now sits with Hitachi and their technical mining products found their way to Datamine after ABB acquired Mincom, then divested the acquired assets a few years later. The resources sector has a gazillion lines of FORTRAN, some of it freshly coded (new codebase) within the last 10 years, believe it or not.
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.
Feel free, my email is my HN username at gmail. As I mentioned in a sibling comment, I'm not in tech anymore (except for fun) but I'm happy to provide any insights or advice to any questions you may have. I last worked with ERP systems about 10 years ago, but the thing about these systems is that they don't really change, so hopefully my knowledge is still helpful!
As a quick summary, this is mostly all ETL (Extract, Transform, Load). Learn the lowest practical level language you can for each system so you can extract / query exactly the data you need (in SAP it's mostly SQL but there are a bunch of proprietary "languages" and extensions that can help. In MS it's mostly SQL, in Infor it's worth learning some RPG /CL, but only enough to get the data you need). Learn the notification paradigms each system offers (this can be as simple as scheduling jobs, it can be file-system watchers, it can be RPC based, etc. etc. Each system is different, but you need to know when to do stuff with the data. Both on change from external influences, and on completion of whatever job you ran). Thirdly, utilise a modern language for the "Transform" and "Load" phases of the job. I used to use everything from C, C#, Perl, Python, etc. These languages are much easier and much more powerful than something like RPG or pure SQL for a non-maestro. There are people who use complex stored procedures for everything, and that's cool, but it's also a steeper barrier of entry than using a modern, "batteries-included" language.
The reason I initially taught myself Go (13 years ago now) was due to the incredibly powerful and simple data manipulation packages built into it's standard library. It's a damn good language for doing high speed, low latency transformation of lots of data, while being simple and easy to code and deploy. Having said this, the afore-mentioned C, C#, Perl and Python were all working fine before I switched to Go! Use what you know, and what's available in the sytem you're working on.
If you have any questions feel free to send me an email.
That’s exactly how they make the money
True, but I'm not actually in tech anymore. I still have a consultancy business, but I make money doing geo-technical rope-access work now. A bit of a sea-change.
I'm happy to impart my thoughts on this topic for free, but I'm not sure how useful they would be after almost 10 years!
> 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.
There's also the issue of having a dozen moving parts form the system, each developed for their own reasons. So you could find that upgrading one product changes something, say collation for utf-16, which might be entirely reasonable taken in isolation but that the rest of the system is unprepared for.
It is up to you to fend off dozens of small things. Over time that accumulates. It's like python programmers using two dozen pypi dependencies because they've heard nih is bad. Or think nodejs if that's your thing. What you do in practice is you freeze everything in place and then you postpone it all for an increasingly indefinite future. Organizations then periodically need to freeze work for weeks or even months at a time just to keep up with dependencies. This is clearly a lot of work.
Terraform, or even better Ansible, is a good choice to document make those changes over time in a standardized way. But it doesn't make the work go away. The work is there and still has to be done. Those tools also clearly suffers from the same many-moving-parts problem, as soon as you include external modules with their dependencies too, so you have take care not to magnify the problem by accident instead.
This is what system admins and integrators do all day. They will tell you in unison that the best integration is the one that doesn't exist.
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.
thanks, here's the code for it: https://github.com/crbnos/carbon/tree/main/apps/academy
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.
really well said, imo! it's interesting how there's two views of ERP. one is a G/L + anything needed to support it. and the other is more of a tool that supports operations and planning. i started with a G/L, but have kept it hidden even now, because my thought it that everything else should be good first, and support the G/L second.
Operations and planning are performed when one’s company fits the mold of a classic business. The system you are building suits the companies that break the mold, which is a growing number as personalization/hyper customization grows.
Can you give an example of mold-breaking?
3D print manufactures that print custom parts need to use their manufacturing and billing operation outside the mold. Unixhero provided another example, but there are a lot of examples where big ERPs aren’t the right solution and/or require a lot of money/customization/ongoing costs to make it work well beyond its total ROI.
Anything which needs detailed operations planning of the production. Larger factories and say chemical companies use standard flows of the ERP (SAP) for this.
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.
That does ring true.
I've seen the sausage being made, so no longer want to eat it.
But the users, still think it is good enough. They don't see the ugliness on back end.
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.
Yes. Most ERP's also handle 'ingredients'. Really, it is any 'inputs' to the product. And potentially, byproducts produced and also sold. All In's/Out's, and how to track them.
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.
Oh that brings memories! Been in quite a few of those.
Basically the ERP vendor sells you the software and estimates that you need a couple months and a couple consultants for the migration and integration, plus a few users of your product as guinea pigs. It is expensive as heck but well, at least it is only two months (plus hotels, plane and food).
After two months you’re halfway done according to the vendor but you need some extra helping hands for the harder features, so you get more consultants, and a department to handle change. You get a few posters.
After a couple years you have eight consultants and a consulting product manager still doing the migration work, plus eight more freelancing ERP experts, and about four engineers from your own team working full time on apis. The work is halfway done, though! Your non-tech staff is juggling between two products and dissenting voices start to appear. You make and distribute t-shirts with texts like “Project Evolution” or “Project Future” to ensure everyone is on board.
After two more years you are almost halfway there, but staff turnover guarantees that people don’t remember the productivity of yore, and the new ERP is judged as good enough. People have gotten used to it, the jokes aren’t as vicious as before, and only a handful of people were fired in the previous years due to the company going severely over budget. But hey nobody gets fired for buying IBM so the boss who decided to blow 15 million on it is fine.
I've seen this balloon to hundreds of consultants. It can break a company. You get huge sunk cost into you're continually 90% done ERP and management either doubles down to spend one year to just get it barely working and stop, or cancel it.
In my experience companies end up paying as much money as they can.
The companies themselves are to blame, too: they absolutely refuse to change their processes, so the software must adapt to them, no matter what the cost.
> Oh that brings memories! Been in quite a few of those.
Hey! I was just on the receiving end of that. Twice! Its still the same.
Even my grandfather once told me stories of this happening in the 70s when the company he worked for was sold and the new management brought new software, or my parents telling similar stuff from the early 90s.
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.
I worked on an ERP system for construction/architect firms in the 00s. The company was about 15 people when I joined, 40 when I left.
We consistently delivered migrations, but we hand crafted SQL extraction scripts, with data cleaning, etc. You could fully customize it, branding it with your own logos/colours/custom css, etc. There was just a clause that the "powered by" link had to stay visible.
I can't remember a single failed migration, though we were split into three "teams" each covering a different set of customers, so might have not seen one.
I suppose we were fairly small scale, and maybe those were the days where some serious attention to detail and care of the customer were still possible as generally we were replacing paper based workflows, not trying to migrate existing electronic workflows with huge data volumes.
But it's perfectly possible to do (and we worked with some fairly big companies in the space).
One of the funniest, yet saddest, support calls I remember getting was being asked "What do we do with Sue now, we don't have anything for her to do anymore?".
So it entirely depends on your implementation team I think. It's possible to do it well. But you probably need a very good set of consultants. If your ERP trainer is coming in and immediately setting up conflict with your company, that's definitely not a good sign.
Small scale is definitely another world entirely. My experience was not in the Billion dollar range as the parent, but in 20M+ (probably 50M in today's dollars) project territory.
> 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
There's an additional catch to that old argument as well. If you actually do what they say, and stick to all the templates. Well guess what, they're all going to change with next update as well and now you need to change all your business processes at the same cadence as they happen to update their software. You still have to adapt to the changes of the system, it's just not the IT departments problem.
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.
I mentioned the cost, which is probably not a public info. A well known player in the semiconductor space.
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?
Customising SAP is like setting money on fire but the core of it is rock solid.
Yeah, but we're talking Tesla here, not some run-of-the-mill carmaker. In fact, given SAP's rep in German manufacturing, they might have even been a net positive for Tesla.
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!
ahh, it does -- but there's a slight hair to split.
on sales, carbon supports quoting, sales orders, invoicing, configurator, etc -- but it does not attempt to create a website for you where you can list your products and their configurations. the idea is that you have a site, the site sends info to carbon through the API (whether it's a quote or an order), and then things begin from there.
similarly with production except that the shop floor is pulling intstead of pushing. carbon manages the schedule, the jobs, the capacity planning, etc. and provides a UI for guys on the shop floor to record their time and materials. but if you want to interface with a machine, you'd be pulling information out of carbon through the API, and relaying it to the machine.
Great Q&A's, thank you for taking the time to answer! Sounds like a great way to handle the complexities of business reality.
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.
thanks! look forward to talking to you
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.
for that we use "batch" tracking with batch properties
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.
the product was commercial analytics for healthcare sales teams. We worked with our customers (medical device & biotech commercial teams) to define granular patient cohorts (patients with a specific disease and specific pattern of treatment) and then analyzed provider (doctor / facility) interactions with those patients.
One onboarding problem was always - here's what I know about the doctors / facilities I care about, help me understand what I don't know. Well, what they knew was usually in a CRM, with very poor hygiene, or some ERP - dat assembled by hundreds of sales and ops people over years, sometimes decades. So generally the first step for us was to do an MDM exercise to join their data to ours.
This had a huge pay-off for both parties. For us we were able to make our product much more useful to them. For them, they now had a map of their territory they could use across multiple business units, multiple therapeutic areas (these usually operate independently and sometimes sell to the same buyers!)
I'm seeing the same opportunity/challenge in my new company, but this time focusing on the supply chain of these companies.
Super interesting. I had the same experience trying to connect a CRM with various tools and the data was typically an absolute mess. It's a hard problem.
Would you be open to chat further? I'm not sure if I can help you or not without learning more, but I'd love to better understand what you're seeing at minimum for research purposes. My email is in my profile.
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
Interesting, since the past two manufacturers I have worked for in the last 16 years both have Sage as their primary ERP...BUT that directly resulted in them needing a bunch of other software strapped to the side of it to get things done, which sounds exactly like the problem Carbon was made to solve.
I had even taken it upon myself to develop a (very rudimentary, but functional) piece of software to manage the Service Department of my current employer, since RMAs/Repairs were still being handled with paper and email when I arrived a few years ago, Sage apparently lacking a suitable module as well as the looming shadow of "that's the way we've always done it" thinking.
Carbon looks like it would trim a lot of the thorns my current employer gets hung up on, but it would take some serious convincing to migrate over given the entrenchment of old and comfortable habits, inefficient though they may be.
Anyway, thanks for the response, I know you folks are busy.
i appreciate you talking through it with me! i only have my limited experiences, and the term ERP is pretty fuzzy -- a CFO's view is a lot different than a head of production.
a sage integration is actually at the top of our roadmap: https://github.com/orgs/crbnos/projects/1/views/1
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.
like a cmd+k type deal or something different? we do have cmd+k navigation to everywhere currently + global search, but i worry that less sophisticated users might not use it.
No, I mean, like a copilot style AI assistant, the user can chat with to ask what they want to do, and either the assistant can operate and navigate the UI to the right place, or perhaps even shortcut the steps for the user by asking for questions to satisfy inputs for the thing they are trying to accomplish.
An example: - user intent is to update an attribute for a component part number A21445
- user can click a chat bubble icon in lower right and chat to the assistant
- user describes their intent - "help me update the description for part number A21445
- system replies by informing the user it will open the right screen, opening a part/component editing UI, with the right part loaded, with the cursor positioned in the description field, and the assistant stays open for further assistance; or;
- system replies that it found the part and can update the description, shows the current description for the user, asks "what description do you want?"
- user enters updated description
- system confirms the change is correct
- user confirms the change is correct
- part/component description is updated without even opening the UI
FWIW, it's great that you have cmd-K and also I've seen those kind of search boxes get more smarts like being able to type "part:A21445" to go directly to a specific UI.
I just suggested the above as we learned some interesting user experiences became possible when our AI assistant had the ability to control our UI directly on behalf of a specific user.
An example in the app I worked in (a web based data pipeline tool):
- "Hey assistant, can you help me add some SQL transformation logic to dataflow ABC, to process the customer data?"
- system uses metadata and knowledge of the UI to open the right dataflow, select the right type of UI to open to enable the user to add a SQL query in the right place, maybe even autogenerate the initial SQL query - this all from the main home page of the app, from a side panel chat assistant.
- net result feels like talking to the assistant to operate the app, almost no clicks required.
I hope that makes sense.
This is a power-user’s nightmare.
Instead of arranging things in a logical hierarchy, and enabling quick navigation thru keystrokes - just toss out making the ui make sense because the chatbot can solve all.
Your job is to make a good product. AI-as-interface is just slapping a layer of randomized language parsing in between the user and bad ui.
I’m not actually saying no chatbots. What I am saying is using a chatbot to solve a usability problem is a massive middle finger to anyone who might have to use your product for 8 hours a day. Make it good, then make it idiot-proof. Don’t make it for idiots only.
I agree with you.
I used to work in green screen text based UIs from the 80s (TUI).
Power users didn't need search or anything else - they memorized the keystrokes to navigate the text UI and could just type key combinations to blaze through the UI faster than it could render on the screen.
I've never really seen anyone able to replicate that UI in a browser based or GUI desktop app to be honest.
Power users are a different use case, although the end goal is to remove the need for clicks.
I don't believe chatbots/AI assistants are a panacea, definitely encourage the architects of this new ERP platform to weigh the pros and cons.
That said, two jobs back I worked for a major manufacturing company that used the old GUI destop based Oracle EBS ERP. To automate repetitive workflows they were trying to implement UIPath (RPA automation - it drives the UI for the user) on top of the GUI.
This is what lead me to believe that if the ERP application's functionality is discoverable by an AI assistant, it can be used to automate or navigate on behalf of the user, or as part of complex workflows.
That can be done later after the basics are addressed - my only advice would be to just consider it sooner, even if you don't build it first.
It's a little easier to think of how one might simplify the workflows and design for automation into the core of the product, via the UI, APIs, etc earlier than later.
But in general - focus on the user's needs first and different roles/personas - just don't completely ignore new types of automation workflow opportunities (i.e. AI assistants/chatbots).
My opinion only.
If the product is API based then it's possible to use a TUI library and make an app that someone can keyboard their way through and have it talk to the mothership through the APIs.
Chatbots would be great for discoverability, especially if you have a ton of docs that nobody seems to read.
Ai slop to navigate the ai slop docs? Ai seven layer dip.
really appreciate you taking the time to write this!
we've started trying to work through adding agents like this: https://x.com/barbinbrad/status/1903047303180464586
the trouble is that there are 1000s of possible mutations -- and the quality of an agent tends to diminsh with the amount of "tools" you give it. i need to figure out the right abstraction for this.
I pray you focus on your core product and don’t fall into an agentification rabbit hole.
If you do want everything to be automatable take a page from Blender and give every action a key binding plus a Python method, so Python scripts can take the same actions a human would, but as function calls instead of clicks. Then maybe maybe maybe you can have a text field that allows natural language to transform to an action, but please god stay away from chat interfaces.
Rhino CAD is another interesting interface to look at, there’s a million buttons and menus but there’s also a text field at the top of the viewport where you can just type a command if you already know the name instead of rummaging through submenus. Kind of a CLI within the GUI.
I somewhat agree with you, especially that one could identify a common abstraction that later an LLM could piggyback on top of.
Genuine question though - have you implemented an AI assistant/chat interface recently using LLMs on top of a UI?
I agree it can be a rabbit hole, but I just got through doing it on an app and there were definitely some things it really made way simpler and some complex scenarios that I'm not sure could have been done any more simply.
I built a chat interface in 2017 (this was with chatscript dialog trees with hole-filling and semantic search) that was ostensibly to prevent our data scientists from redundant work, ie, before they spent all day writing a SQL script, describe the job of the script and see if one already exists. The chatbot would then ask for the parameters required for a script, run the job, and then present a CSV of the returned data.
As we collected user feedback and refined the UX, we got closer and closer to an option tree that could be better represented by a drop down menu. It was kind of depressing, but I learned that the actual job of that R & D wasn't to come up with a superintelligent chatbot that replaced data scientists, it was to come up with the infrastructure that would allow data scientists to put their python scripts in a common repository to allow re-use without re-installing locally and screwing around with pyenvs.
Anyway, I'm also traumatized by my involvement with a YC startup that actually had a very good (if ENRONish) product around peer to peer energy futures trading that completely fell apart when investors demanded they make it "AI"
Sorry to here about your bad experience. I do understand it, as when the hype cycle causes perfectly good things to be thrown away or messed up for no practical reason, it really bugs me too.
In this case, it's so easy for some to say everything else is bad if it is not AI, or you have to include AI "because it's the future".
I just wanted to clarify that I am very pragmatic in my approach to new tech and AI.
I used to work on enterprise ERP, MRP, sales and support systems (Oracle, Salesforce, ServiceNow, and more)... not always by choice.
At one point a project came up to rebuild our core customer experience portal across our business. I got to build with the rule based chatbots to implement an assistant in that web app.
Not easy, but it worked well enough, especially for simple scenarios. For example, imagine a field support engineer being able to pull up the exact page in a big technical document for some obscure part by just asking for what they need, in seconds.
Or, being able to reorder some quantity of part by just asking for it, or checking the quantity of same.
These are time savers, especially if you have a voice to assistant interface too. So you can just type something, or ask for what you need without typing.
Tablets were common for manufacturing, inventory or service staff. Being able to pull up our interface and just say what they needed and get prompted for simple things - there were TONs of pragmatic small wins there.
Current LLM just make that easier than the old rigid rule based way we had to code those assistants (at the price of going wrong sometimes).
I care about efficiency, pleasant user experience, and pragmatics.. not AI for the sake of AI.
All that to say, if a drop down box works better for some use case, instead of AI - or even a rule based chatbot - hell yeah! Save on them tokens.
Cool! Yeah, that's the kind of UI/UX I meant.
I agree with the right abstraction and it's tough to find the balance- in our data pipeline app, what we did is make key core functionality of the app exposed so the assistant can use it, and implemented a handful of basic agents out of the box, including one default one that could shell out work to others. We also made it easy as an extension point for users to add a new agent that used the core functionality/tools, just by defining the agent in a markdown file.
We found starting small for critical use cases that saved the most time, but thinking about building blocks, was useful.
Because the responses of the AI assistant come back and are processed on the UI, we found we could give the LLM our UI docs as well as knowledge about UI element IDs, etc so it could respond with input commands that would drive the UI.
This way, we could do something like, provide the LLM with the input/prompt including the context of like - what page/view is the user on, what is their intent, what tools are available in general, what sub agents are available for specialized tasks, etc.
Please don't let my suggestions sway you away from core progress in your app (take with a grain of salt). But it's great you're already experimenting- keep your eyes open if you see a great use case where it accelerates workflow.
Another HNer mentioned people not reading docs- that's a low hanging fruit use case we had too - "how do I use this view?", "what does this field mean?", or retrieving information from other parts of the app without having to navigate away, etc. It can save having to find answers in a doc or navigate elsewhere.
Edit: perhaps a useful exercise - imagine a workflow of "talking to the app to achieve a task" as a way to explore.
"Hey ERP, open the part entry screen for part 12345"
"Hey ERP, can you update the description for part 12345 to correct the spelling error?"
"Hey ERP, how many of widget XYZ are in stock? If there are enough in stock, can you transfer quantity 10 from warehouse A to B?"
"Hey ERP, how do I cancel a sales order?"
"Hey ERP, how does this screen work?"
I think if you break these down, you'll find common abstractions that map to features, API endpoints, user interface sequences and interactions, triggering workflows, looking things up in docs, etc.
Please share the feedback for keyboard shortcuts from real users. Now shops in India tend to use touchscreens or have staff fiddle with laptops with tiny touchpads, but lots of shops use ERPs (Tally) with 90s UI that dont need mouse.
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.
Accounting is still not checked off. Has anyone done integrations with FLOSS software like GnuCash?
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
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.
Mincom, a Brisbane based tech company started in the late 80s with a suite for mining, and oil/gas production. At the time, they had 1-10 customers who paid a LOT of money. I am sure they are bigger now, but the fundamentals here are the same: you have to maintain almost every version of product back to the origin, and backport any change, because you can guarantee there is a mine in Kazakstan making a very large amount of profit, which is unwilling to upgrade, but is willing to pay you to maintain the legacy codebase.
TL;DR -If you support mining, expect to support the FORTRAN code you shipped them in 1960s.
Indeed. That was the very company I was thinking of! The Mincom EAM product (Ellipse) now sits with Hitachi and their technical mining products found their way to Datamine after ABB acquired Mincom, then divested the acquired assets a few years later. The resources sector has a gazillion lines of FORTRAN, some of it freshly coded (new codebase) within the last 10 years, believe it or not.
Great UI! Congrats on the launch
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!
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]