Why Project Shrine Had to Exist

If you have read my previous articles, you may have noticed that I have built and maintained CRM, ERP, eCommerce, accounting, time booking, email marketing and other systems. Some of them are still running and need maintenance; some of them are not. But the features are nice and can be reused in other projects.

Solving my own problems

Primarily, to solve my own problems:

1. Maintainability - It is cumbersome to maintain multiple systems across multiple projects and services.
2. Reusability - Tired of rebuilding the same features over and over again, with every new project. All of them have user authentication, user management, some email notifications, etc.

Solving someone else’s problems

And hopefully, it will solve someone else’s problems too. When starting a new project, you have to use multiple SaaS tools to get the project running (e.g. Calendly, Trello, maybe HubSpot). With this project I am not trying to reinvent the wheel, or explicitly to compete with any of these SaaS tools, but to provide a single platform with bare minimum features to get a project running.

Small dream

I have always dreamed of building a modular, scalable component system where I can add features as I need them (feature flagging).

Afterwords

From a product or developer perspective, you might think that a well-developed product equals great success, but in reality, it is not always the case (to not say mostly not the case). I have seen throughout my professional career that there are businesses running on horribly, terribly developed code bases and infrastructure. It sometimes left me wondering how they were still alive, but they are. People are still using them, and the businesses are still making money.

With that all being said, perfection in product development is not a guarantee of success, and I shouldn’t be striving for the perfect architecture. As long as the product solves my problems, enables the possibility to “fail fast” with new ideas, and stays maintainable, I am happy with it.