[nslindtner]

I have allways wondered why there isn't a "headless" erp-system.

I have worked with cms-systems. And in this world it is accepted, you need different frontends for different tasks. Therefore a world of systems - calling themselve headless - support only the backend part of cms management. Worked with Strapi that support this kind of thinking.

How come something similar doesn't exist in the ERP world ?

[mamcx]

One major reason is that both developers/customers who ask for it think in UI first, all the time.

Most developers I know are at the far-end of development practices (one of the ERPs I integrate has tables like `F0001, F0002, ...` and fields `F00001, F00002`), and this ERPs then uses old tools like Cobol, Fox, (Old) Delphi, (OLD) VB where it has a better UI history.

And it causes to be very hard to build an API (you can't image how much torture is when an ERP vendor says "we have an API!" instead of using plain text or direct SQL)

For this, you need people that know how to do good APIs. And the good API for an ERP is NOT Rest, GraphQL, JSON, ... (ideally, you need a DB!)

[arnorhs]

Well the UI-first thinking makes more sense, since in most cases you are solving process-problems, which involves "what does who do when?"

It's hard to communicate a process through a REST API. Sure you could document it incredibly well, maybe even have every part of your ui represented by an API endpoint, but ultimately, due to the number of customizations involved with each ERP view, you'd end up with some sort of bastard, which was never quite the same as the real deal.