[HN Gopher] Show HN: I've been building an ERP for manufacturing...
___________________________________________________________________
Show HN: I've been building an ERP for manufacturing for the last 3
years
Author : barbinbrad
Score : 286 points
Date : 2025-08-04 22:24 UTC (1 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| jdhn wrote:
| As a UX person, this is the type of stuff I love to see posted
| here. So many people don't understand how atrocious the UX is in
| non-sexy career tracks such as manufacturing. One question I have
| is how users have reacted to your leftmost nav bar. 13 icons is a
| lot, do you show them all at one time, or do they dynamically
| appear based on the user role of the person who's logged in at
| the time?
| barbinbrad wrote:
| man! i wish i knew how to do a better job with that. there's
| just so much stuff. do you have any ideas?
| sixdimensional wrote:
| Give users an AI assistant they can ask to navigate them to
| the right screen or section of the application?
|
| In a previous job, we built our AI assistant so that it could
| operate our UI in the front-end and it was very powerful.
| barbinbrad wrote:
| 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.
| sixdimensional wrote:
| 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.
| barbinbrad wrote:
| 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.
| jazzyjackson wrote:
| 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.
| sixdimensional wrote:
| 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.
| sixdimensional wrote:
| 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.
| kennywinker wrote:
| 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.
| 1899-12-30 wrote:
| Chatbots would be great for discoverability, especially
| if you have a ton of docs that nobody seems to read.
| kennywinker wrote:
| Ai slop to navigate the ai slop docs? Ai seven layer dip.
| sixdimensional wrote:
| 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.
| aitchnyu wrote:
| 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.
| ketedrum wrote:
| 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!
| rubidium wrote:
| I have no idea why you're using icons for 13 things. Use
| words.
| jdhn wrote:
| 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.
| healthbjk wrote:
| What vertical ERPs does it replace?
| barbinbrad wrote:
| 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.
| mindok wrote:
| 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.
| ggm wrote:
| 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.
| mindok wrote:
| 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.
| danpalmer wrote:
| 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.
| plumeria wrote:
| > Carbon on the other hand appears to be quite a few different
| components, with many dependencies, some of which are SaaS
| products, and uses a database (Supabase) which is itself a
| whole microservice ecosystem that is a considerable effort to
| deploy
|
| Perhaps this could be addressed by providing a Pulumi or
| Terraform program?
| barbinbrad wrote:
| 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
| danpalmer wrote:
| 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.
| xorcist wrote:
| 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.
| cess11 wrote:
| 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.
| Intermernet wrote:
| 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.
| helltone wrote:
| This resonates with me a lot. Can I contact you? My email is
| in my profile.
| ssss11 wrote:
| That's exactly how they make the money
| xupybd wrote:
| We built a lot of the custom ERP related systems outside of our
| ERP. Leaving the financials to the big boys and just talk to the
| ERP. It's working really well.
| mtillman wrote:
| 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.
| barbinbrad wrote:
| agree. it's very impressive how SAP maintains multiple ledgers
| for different regulations in different countries. i'm not going
| to replace that any time soon. i think even tesla uses SAP for
| accounting, but something like this for the rest.
| fakedang wrote:
| Is there a reason for such an arrangement? Why would Tesla
| not use SAP as their backbone ERP too?
| xupybd wrote:
| Customising SAP is like setting money on fire but the core
| of it is rock solid.
| fakedang wrote:
| 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.
| d_burfoot wrote:
| Does the ERP allow you API access, or do you need to do CSV
| upload/download?
| barbinbrad wrote:
| 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
| xupybd wrote:
| API and direct database access.
| mfrye0 wrote:
| Congrats on the launch! Love seeing modern manufacturing systems.
|
| Do you handle supplier master data management? We're seeing
| procurement teams struggle with duplicate vendors in their ERPs -
| same supplier gets entered 5 different ways, messes up spend
| analytics and supplier relationships.
|
| We're building AI agents for business data cleanup (still in
| stealth, docs coming). Manufacturing/supply chain customers seem
| to have the messiest supplier data - way worse than other
| industries.
|
| Curious if this is something you're thinking about for Carbon?
| (CTO here, happy to chat)
| barbinbrad wrote:
| 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
| mfrye0 wrote:
| Nice! Yeah, a typeahead works to a degree. I imagine that's
| searching their own instance vs calling out to a standardized
| DB you manage?
|
| Raw materials is definitely a different animal, so auto-
| generating definitely works. I know a company where that's
| all they do - they manually pour over supplier specs to get
| all the model names.
|
| Agent approach looks super cool. I see the supplier search
| piece happening there.
|
| We've mapped out ~265M+ businesses globally. We're thinking
| about this as a data infra angle where products can tap into
| our system to access all the world's businesses. We're
| getting requests for processing millions of ERP records to
| clean/standardize, plus semantic supplier search across our
| full dataset.
|
| I'll shoot you an email to chat more.
| barbinbrad wrote:
| thanks! look forward to talking to you
| daedrdev wrote:
| 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.
| barbinbrad wrote:
| for that we use "batch" tracking with batch properties
| ageyfman wrote:
| this is a big issue in healthcare, a chunk of my last company's
| revenue was doing MDM for large medtechs.
| mfrye0 wrote:
| 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.
| ronameels wrote:
| Do you have any users yet? What's your target size manufacturing
| company? I've been in the industrial software space for a while,
| and at least for large MFG, you only see the major players, with
| SAP being the most common. There is this "UNS" concept that's
| been around for 5ish years now and has caught steam (unified
| namespace, google and you'll find it). It has holes from a
| technical standpoint, but it will get attention if you can show
| how it works with factory data in a UNS. Happy to help if i can.
| I work at a company that does industrial dataops now, focused on
| getting shop floor data in/out of the factory with context.
| barbinbrad wrote:
| 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"
| calvinmorrison wrote:
| 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....
| rancar2 wrote:
| 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.
| barbinbrad wrote:
| 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.
| rancar2 wrote:
| 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.
| robertlagrant wrote:
| Can you give an example of mold-breaking?
| unixhero wrote:
| Anything which needs detailed operations planning of the
| production. Larger factories and say chemical companies
| use standard flows of the ERP (SAP) for this.
| FrustratedMonky wrote:
| 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.
| supplied_demand wrote:
| == 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.
| FrustratedMonky wrote:
| 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.
| MutedEstate45 wrote:
| The modular ERP/MES/QMS approach is interesting and challenges
| traditional manufacturing processes. Most manufacturers obsess
| over single source of truth. (I.e. ensuring a part number means
| exactly the same thing across planning, production, and quality
| systems.) On the one hand, breaking these into separate apps
| creates potential data consistency risks. On the other hand, it
| could enable much better adoption. Start with MES for shop floor
| visibility then add QMS for compliance later rather than massive
| all-in-one ERP implementations that often fail. Curious, how are
| you handling data consistency across modules? What's been the
| feedback from your current or potential customers on this
| approach versus traditional monolithic ERP systems?
| barbinbrad wrote:
| hey founder here. they are separate apps, but use the same
| database, and same api. i'm also a big believer in single-
| source-of-truth and the compound startup idea
| MutedEstate45 wrote:
| Ah gotcha. Makes sense to get the benefits of modular
| adoption without the headaches. Nice approach.
| robertritz wrote:
| I'm the owner of a smallish furniture manufacturer. About 15
| employees. I built out the order management system myself because
| nothing really fit our process.
|
| After looking at the site I can't really say I know how this
| software could help us. I'll look at it later on my desktop but
| first I think some better demo videos or gifs on the landing page
| would be nice.
| barbinbrad wrote:
| 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
| monatron wrote:
| 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.
| barbinbrad wrote:
| thanks, here's the code for it:
| https://github.com/crbnos/carbon/tree/main/apps/academy
| phendrenad2 wrote:
| 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.
| twarge wrote:
| How does this compare with the manufacturing capabilities in
| ERPNext?
| barbinbrad wrote:
| i don't know a ton about ERPNext's manufacturing capabilities,
| but i think there are really great for these reasons:
|
| - free to try - open source - well-documented - great developer
| community
|
| one big difference is in the data model. in ERPNext, everything
| is a doctype, and there's some standard hooks.
|
| in carbon, there are hundreds of different tables. each ui is
| it's own set of react components, so it's a lot more
| manufacturing-specific and a little more opinionated.
| fiatjaf wrote:
| 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?
| jjk166 wrote:
| 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.
| barbinbrad wrote:
| 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.
| fiatjaf wrote:
| I see, I was under the impression that Carbon encompassed
| sales and factory floor too. Now it makes more sense. Thanks!
| barbinbrad wrote:
| 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.
| bavell wrote:
| Great Q&A's, thank you for taking the time to answer!
| Sounds like a great way to handle the complexities of
| business reality.
| yahoozoo wrote:
| Great UI! Congrats on the launch
| calvinmorrison wrote:
| 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?
| barbinbrad wrote:
| 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...
| barbinbrad wrote:
| 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.
| 414techie wrote:
| 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.
| uzerfcwn wrote:
| 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.
| Etheryte wrote:
| 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.
| SilverElfin wrote:
| 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?
| stephen_g wrote:
| 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.
| solumunus wrote:
| The M is for "material". Material Resource Planning.
| jacquesm wrote:
| 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.
| FrustratedMonky wrote:
| 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.
| technotony wrote:
| 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.
| on_the_train wrote:
| 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.
| RossBencina wrote:
| > 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.
| whstl wrote:
| 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.
| delusional wrote:
| > 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.
| whstl wrote:
| 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.
| FrustratedMonky wrote:
| 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.
| whstl wrote:
| 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.
| PeterStuer wrote:
| 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.
| mattmanser wrote:
| 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.
| PeterStuer wrote:
| 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.
| delusional wrote:
| > 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.
| FrustratedMonky wrote:
| 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.
| on_the_train wrote:
| I mentioned the cost, which is probably not a public info.
| A well known player in the semiconductor space.
| thedogeye wrote:
| This blog post from Retool was really helpful for answering
| that question: https://retool.com/blog/erp-for-engineers
| ssss11 wrote:
| 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.
| detourdog wrote:
| 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.
| rubenvanwyk wrote:
| 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.
| davidw wrote:
| How's it compare with Apache OFBiz and the things people are
| building on top of that?
| jazzyjackson wrote:
| 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.
| rubenvanwyk wrote:
| Well for one more modern UI, I suspect??
| yc-kraln wrote:
| 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.
| hedshodd wrote:
| 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?
| barbinbrad wrote:
| 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...
| barbinbrad wrote:
| 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.
| mahidalhan wrote:
| 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
| contingencies wrote:
| 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.
| progx wrote:
| 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!
| tonyhart7 wrote:
| a new "MERN" stack of web development post covid era
| mrweasel wrote:
| Yeah, that's a lot of hosted solutions for an ERP.
| barbinbrad wrote:
| 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!
| roschdal wrote:
| Simply use SAP.
| rswail wrote:
| There is no such thing as "Simply Us[ing] SAP".
| wiradikusuma wrote:
| 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.
| jacquesm wrote:
| Many large businesses still use Excel! You'd be surprised how
| much commerce is enabled by spreadsheets.
| delusional wrote:
| 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.
| delfinom wrote:
| 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"
| barbinbrad wrote:
| 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.
| benhurmarcel wrote:
| > a "tarpit idea" (deceptively attractive but actually
| unscalable, time-consuming)
|
| Well it's hard to be as cheap as a spreadsheet.
| jacquesm wrote:
| 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?
| benchly wrote:
| 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?
| barbinbrad wrote:
| 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
| benchly wrote:
| 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.
| barbinbrad wrote:
| 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
| sails wrote:
| 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!
| FrustratedMonky wrote:
| 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.
| phkahler wrote:
| Accounting is still not checked off. Has anyone done integrations
| with FLOSS software like GnuCash?
| jimnotgym wrote:
| 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
| vindin wrote:
| 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
| stephen wrote:
| 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.
| mattfrommars wrote:
| Tangent thought as I've been trying to adopt new programming
| language. I'm amazed how prolific is typescript in open source
| project space.
| scarface_74 wrote:
| 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.
| gh0stcat wrote:
| 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.
| RaftPeople wrote:
| 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.
| stillsut wrote:
| 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
___________________________________________________________________
(page generated 2025-08-05 23:02 UTC)