←back to thread

YC: Requests for Startups

(www.ycombinator.com)
514 points sarimkx | 1 comments | 14 Feb 24 16:31 UTC | HN request time: 0s | source
Show context
brettv2 ◴[14 Feb 24 15:54 UTC] No.39371339[source]▶
> NEW ENTERPRISE RESOURCE PLANNING SOFTWARE

Very curious if anyone knows how to pull this off. There's so much value to be unlocked but it's just impossible to break through.

I've personally met three very talented founders that tried and failed (one was accepted to YC as a mid-market ERP and successfully pivoted into an application tracking system) and failed very quickly.

I'm guessing an important feature would be an integration system that maps data from the current ERP seamlessly into the new ERP. And that assumes you can even get through the enterprise sales process to even get the company to migrate.

replies(15): >>39371417 #>>39371513 #>>39371559 #>>39373523 #>>39373559 #>>39373655 #>>39373844 #>>39373923 #>>39374114 #>>39375168 #>>39375430 #>>39375543 #>>39377087 #>>39382481 #>>39383460 #
nslindtner ◴[15 Feb 24 13:33 UTC] No.39382481[source]▶
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 ?

replies(1): >>39386186 #
mamcx ◴[15 Feb 24 18:15 UTC] No.39386186[source]▶
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!)

replies(1): >>39454486 #
1. arnorhs ◴[21 Feb 24 14:49 UTC] No.39454486[source]▶
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.