A question: in my (limited) experience, ERPs are made on the basis of integrations. I'd have thought the best priority order would be data-model first, integration second, everything else third. How do you think about this? What's the goal here?
And secondly, some feedback: It looks like Carbon falls into the same trap as many self-hostable SaaS-like products (including my own!), and that is that software designed for one single hoster is often more complex to deploy and built in a different way, whereas software designed primarily to self-host looks much simpler. As an example, installing Wordpress or Odoo is relatively simple, with basic frontend webserver config and easy to run open source databases. Carbon on the other hand appears to be quite a few different components, with many dependencies, some of which are SaaS products, and uses a database (Supabase) which is itself a whole microservice ecosystem that is a considerable effort to deploy. What's the strategy here? Despite having the skills for it, I'm not sure I'd ever consider self-hosting Carbon, and maybe that's good for Carbon as a business, but it's also less good for the ecosystem.
I guess that's how they make the money. Sell the platform and profit off the custom code.
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.
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!
Perhaps this could be addressed by providing a Pulumi or Terraform program?
Figuring out issues get more complex, scaling gets more complex, backup and recovery get more complex, now you need monitoring for it all too, and with many services the complexity multiplies.
All of that complexity is somewhat justified for a team that exists to build and operate the system (i.e. SaaS), but doesn't really work for a team who exist to build something else and have just been tasked with operating this.
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.
After looking at the site I can’t really say I know how this software could help us. I’ll look at it later on my desktop but first I think some better demo videos or gifs on the landing page would be nice.
Maybe ERP is one of those things that co-evolves with the company, shaping the company as much as it's shaped by the company.
It evolves as we do with me making feature updates and bug fixes every few weeks. Of course this is unusual in that I’m a very technical owner, but I feel this is the right way.
As software becomes easier to make custom software will reduce in price as well. Software gives my company an edge and I’ll take every advantage I can get.
i don't know if you build anything custom, but we do have a configurator
The most important thing about ERP systems is - customization. IE: Scripting (netsuite), or even core programming (Sage100 for example). Not just user defined fields but workflows and being able to override and hook into core parts of the system. Say you want to override your cost basis for a certain productline or maybe serve different prices based on the shipping warehouse.
How do you approach that?
EDIT:
How do you handle the finances, G/L auditing, and allt hat financial wizardy?
customers.. they love PDFs. How do you handle generating things like pick lists, invoice sheets, etc? templating?
EDIT2:
One thing big ERPs provide is basically a cohesive way to extend. Not just an API in a RESTFUL sense, it's more akin to an IDE or like GTK+, there's almost everything rolled in for extension inside the 'world view' of the ERP. Every ERP makes some decisions and the rest of the world may flow, be that how you issue credit memos, handle multiple financial entities (do they all have the same chart of accounts? do they all have the same modules? Are there shared users) and so forth. How do you approach that? IE: when you need to slap something like PO's on top of AP, so basically AP + Items and a whole bunch more, does that "flow"? Do you receive those goods and they end up in your inventory for AR? etc.... Having an extensible system is great for addons and consulting, but the bigger piece is - for you, letting your ERP grow and add capabilities.
EDIT3: "Stripe" is not a billing techstack. Mostly CFOs make decisions about billing options, not us lowly tech monkies. Do you support pluggable vaults or anything akin?
i think open-source gives consultatnts and integrators super powers that they may not be used to -- everything currently has to be done through abstractions on abstractions. if you can just modify the source code, it becomes a little simpler i think.
take the PDFs for example. just make them how you want them in your instance of the software using the most popular tools on the planet (i don't mean crystal reports): https://github.com/crbnos/carbon/tree/main/packages/document...
Your value prop lands really well with the Software Architect in me. That part of my skill set loves the idea of creativity, flexibility, etc.
The Director in me does not want that. That sounds like a money pit, never done, management nightmare. What kind of dev do I hire? Do I need a Product Manager for that? How long will it take? Sounds too hard to get a win as a senior leader.
Most of the software in the adjacent space (and ERPs) have “prescriptions” or an ecosystem to get customizations done. Code may get deployed in a special assembly, a special SDK exists, etc
A prescriptive way to get the job done is much more preferred for predictability, even if it is not as loved by the developers.
I think Carbon is a neat and ambitious offering - happy to chat more with you if desired.
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"
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.
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.
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.
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.
Then there's MRP (M for manufacturing) which is usually an option - for when stuff that you're selling isn't the same as what you're buying.
So the ERP/MRP manages bills of materials for items (basically parts lists), when you want to sell something you make a sales order, it sees if you have the inventory on hand to actually make the things, and if not you can generate purchase orders, and then once you have everything it can create work orders which basically tell your factory people to go and turn the input parts into a product so you can sell it. Invoices are created from sales orders, and workers time is tracked on the purchase order, so the cost of goods and labour is automatically tracked in your financial reports as well as the revenue etc.
And ERP is Enterprise resource planning.
I now work on a large company that is about to introduce a large new erp system and is not only investing billions into that change with the mother of all vendor lock ins; but we're also internally transforming the company so that the erp will work. But no, we can't afford the two days of estimated work to upgrade to c++20 as it's not necessary right now.
I'm not sure how things are now, but I once worked tangentially on a mid-sized corporation ERP rollout. At that time it was not unusual to have an entire department at the ERP-adopting company called "Change Management." Any company-wide process change was managed by the Change Management department.
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.
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.
Hey! I was just on the receiving end of that. Twice! Its still the same.
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.
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.
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.
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.
you can use the API from inside the codebase, or outside of it: https://github.com/crbnos/carbon?tab=readme-ov-file#api
I imagine a good approach that would solve some of my reservations would be a strict core ledger, especially as it relates to inventory and finance related transactions, but then relatively flexible around the specific product domain (we did craft beer, which in the end was a nightmare to map to the ERP processes)
Flexible where it matters, strict where it matters. Idk, but good luck!
I would have thought "manufacturing" was too generic and that you would need different software for each industry and so on.
But instead it looks like it doesn't matter if you're making shoes or cars or umbrellas or computer chips, everything uses the same software?
the way i see it, the sales side should be bespoke -- because everyone has a different product, and way of selling/configuring, and the factory-floor side should be bespoke -- because of all the different types of equipment. but the middle layer (purchasing, bill of materials, invoices, sales orders, scheduling, processes, work centers) can be standardized.
for me that's why it's important that the middle layer is open source. so that the bespoke layers can tie into it.
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.
Do you handle supplier master data management? We're seeing procurement teams struggle with duplicate vendors in their ERPs - same supplier gets entered 5 different ways, messes up spend analytics and supplier relationships.
We're building AI agents for business data cleanup (still in stealth, docs coming). Manufacturing/supply chain customers seem to have the messiest supplier data - way worse than other industries.
Curious if this is something you're thinking about for Carbon? (CTO here, happy to chat)
but for raw materials, we auto-generate the ids like this: https://x.com/barbinbrad/status/1947682873416221184
also working on some agents: https://x.com/barbinbrad/status/1903047303180464586
would love to talk, i'm brad@carbon.ms
Raw materials is definitely a different animal, so auto-generating definitely works. I know a company where that's all they do - they manually pour over supplier specs to get all the model names.
Agent approach looks super cool. I see the supplier search piece happening there.
We've mapped out ~265M+ businesses globally. We're thinking about this as a data infra angle where products can tap into our system to access all the world's businesses. We're getting requests for processing millions of ERP records to clean/standardize, plus semantic supplier search across our full dataset.
I'll shoot you an email to chat more.
I don't have much context in the healthcare space and the challenges that exist there. We've been mainly talking to people in fintech, supply chain, and sales & marketing, which is primarily where I ran into this at past roles.
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.
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
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.
"Techstack Remix – framework Typescript – language Tailwind – styling Radix UI - behavior Supabase - database Supabase – auth Upstash - cache Trigger - jobs Resend – email Novu – notifications Vercel – hosting Stripe - billing"
And no joke: congrats to your product!
the easiest one to replace is upstash -- the @io/redis is super easy to switch out -- i think the APIs are the same. but the others encapsulate an insane amount of complexity. my thinking is, if i -- as a fairly competent software engineer -- don't have the bandwidth to sysadmin 10 services -- how is someone whose running a manufacturing going to have the bandwidth.
the setup does suck, but imo it's the best solution for bang-for-the-buck long-term. interested to hear your thoughts!
- Who is 'I'?
- How do you see continuity if something were to happen to you?
- How does it stack up against ERPNext?
- Why did you decide to build an ERP system from the ground up?
- What is the deployment situation?
How does it stack up against Sage?
Expanding on "what is the deployment situation," how long should it be expected to take for full conversion to the Carbon platform from the described situation of discordant software that has been entrenched in a particular business's practice for decades?
here's a little bit about me, and why i decided to build this: https://carbon.ms/#memo
re: sage, i'd say that sage is well-known as being a great general purpose accounting software for multi-location, and multi-entity businesses. but i don't know of many manufacturers running on sage.
re: erpnext, also great. i love their open source model, their developer ecosystem, and great documentation. i'd say the major difference is the data model and the UI that it begets. in erpnext, i think everything is a "doctype" where with carbon things are more bespoke. each ui has it's own specific tables, and specific ui
re: erp
I 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.
a sage integration is actually at the top of our roadmap: https://github.com/orgs/crbnos/projects/1/views/1
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 remember their freezers where the guys wore special clothing and gloves but they still needed to be able to hit buttons on the computer.
- 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.
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"
My dad has been a solo fabricator for most of my life, and what has always struck me was the way people came to him with jobs. Sometimes they'd show up with drawings and detailed designs, but mostly they'd just ask him to come look at something (or bring a photo), and describe the problem. He doesn't know CAD, so the drawings he makes are mostly just on napkins. The customers quite literally didn't know what they were getting before they got it, but that is fine, because they don't know what they want either.
I wonder if there's an analogue to that for software. A freelance local software developer these small businesses could go to if they had a process problem they'd like to solve.
Well it's hard to be as cheap as a spreadsheet.
Also, if you really wanted to, you could move back to a more traditional top menu where you have the section title, mousing over the section would open a menu (what is now your icons), and then if needed you could have a submenu underneath (what is your left nav with the words in your first Github photo). Discoverability would potentially take a hit but it's a different way of doing it.
If you have any other questions feel free to reach out, I like doing this stuff.
Edit: Another user suggested using AI enhanced chat to navigate around. This is a sign that the information architecture is WAY too confusing. AI agents shouldn't be utilized for navigation purposes.
In a previous job, we built our AI assistant so that it could operate our UI in the front-end and it was very powerful.
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.
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).
My opinion only.
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.
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.
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.
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"
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.
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'm surprised the carousel is slow, it's just framer motion. https://github.com/crbnos/www/blob/24d2b59150fc21e6b9c9df3b4...
imo though, it's fairly straightforward to go from a manufacturing ERP to a non-manufacturing ERP -- but it's very difficult to do the opposite because of the complexity of manufacturing.
TL;DR -If you support mining, expect to support the FORTRAN code you shipped them in 1960s.