barbinbrad

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.

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.

thanks! look forward to talking to you

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

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

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

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.

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

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.

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

man! i wish i knew how to do a better job with that. there's just so much stuff. do you have any ideas?

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"

code: https://github.com/barbinbrad

resume: https://bradbarb.in/resume.pdf

email: bradbarbin@proton.me

things: 10 years full stack web + manufacturing

currently: principal engineer at teamworks.com