barbinbrad

oui

oh not at all, i was thinking the same thing. i just needed to hear it from someone else

lol, essentially yes. sorry about that. there's a lot of regulations around software that's used for aerospace and defense, and that's where a lot of the new builds are happening these days. but here's a little decoder ring:

ERP: the core system that manages/plans everything from accounting to inventory MES: the shop floor QMS: the quality system that keeps track of what's went wrong and how we're fixing it CMMC: government regulation NIST 800-171: spec that drives the regulation

there's a lot of good reasons, but the best is there's no perfect off the shelf ERP. things need to become business specific. open-source allows anyone to make the system specific to their business.

ERPNext is more general purpose, Carbon has a lot more for manufacturing.

Haha thanks brother. Hopefully it looks better now

thanks for taking a look. very good read of the state of things. Netsuite level accounting and mrp v2 are what we’re building now. We focused on running a manufacturing business from an “everyone else” perspective first.

I think you’re right in a sense that we’re building the thing I would have wanted — and you’re also right in a sense that there are people out there that know more than me. The key is to learn from them.

most run on BYOC or managed hosting. but for the forks you can tell claude "merge upstream and fix the merge conflicts"

embarrassed founder here. shipped an update to make it look less generic.

you can run the community edition for free. there's enough in there to run a full manufacturing business.

they're awesome. we highly value their opinion. they were the ones who gave me the confidence to open source it

https://minimal.tech -- they build the whole stack from PCB to hardware to wiring to mechanical assembly to telematics software themselves

founder here. extremely accurate comment. we had a customer send us this website recently. they said "we think you need a better website, we made this with claude"

I've been using this for a few years. It's great.

huge fan of elixir. and definitely have some dumb questions.

in some of the realtime architectures i've seen, certain processes get priority, or run at certain Hz. but i've never seen this with the beam. afaik, it "just works" which is great most of the time. i guess you can do: Process.flag(:priority, :high) but i'm not sure if that's good enough?

founder here. i see open source as a better API for connecting it to other systems

thanks, here's the code for it: https://github.com/crbnos/carbon/tree/main/apps/academy

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

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.

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...

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.

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!

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

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.

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.

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...

for that we use "batch" tracking with batch properties

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.

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.

founder here. great question.

the way i see it, the sales side should be bespoke -- because everyone has a different product, and way of selling/configuring, and the factory-floor side should be bespoke -- because of all the different types of equipment. but the middle layer (purchasing, bill of materials, invoices, sales orders, scheduling, processes, work centers) can be standardized.

for me that's why it's important that the middle layer is open source. so that the bespoke layers can tie into it.

i 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.