The story of ERATI Building a web-based ERP / CRM
Welcome, it's great to have you here. We know that first impressions are important, so we've populated your new site with some initial getting started posts that will help you get familiar with everything in no time.
In 2013 I co-created a web-based ERP & CRM called erati. As young entrepreneurs, having just finished my master degree in administrative- and constitutional law we decided to write the name with some classy greek, a capital lambda: ERΛTI. Let me share some fun facts about one of the most educational projects I ever took on.
Developing a webbased ERP CRM: fun facts
- It is by far the largest project I ever took on and it launched me into being an entrepreneur.
- Currently (2020) there are still multiple paying customers of this platform.
- Initially it seemed to be a financial disaster. Having invested thousands of hours into coding all parts of the application. As some customers stuck with us for seven years we can see a future in which the project might become break even.
- It took more than two years to complete the first version of the project.
The stack
After careful and lengthy deliberation we decided on the Laravel PHP framework as the most viable MVC framework to found the project on. For our database we chose PostgreSql and for the frontend we coded the UI ourselves with a combination of Coffeescript and Knockout as a frontend framework. We used a tiny NodeJs script to enable the project to have live reload features. Finally we used Sphinx as a highly flexible search engine. As this was a huge project we chose to work with an ORM (object relational mapping). Eventually we settled on Propel which ended up to be quite a solid choice, although the version we used did end up to have quite some quirks.
The worst part
Often I think back about what the worst part of this humongous project actually was. I cannot forget two major issues we ran into. The first was printing from web to existing line printers. This was eventually fixed by creating custom sized pdf's. The second terrible issue was connecting with very archaic financial software. Initially we were pleasantly suprised by the claim that this product had an API. The pleasant suprise faded when we learned that it was based on SOAP in which we had to supply data in a custom pipe-separated field code model. The data looked a little bit like this and was literally horrible to debug.
101:0.21|041:1|011:1.21Finally
There is a lot more to write about this project. One example of it is the FTP API we had to use to collect product data. But for now I will leave it at this. Eventually I might expand a bit on the experiences I had during and after this project.
