Brief Intro
Building your own SAAS application from scratch seems like a very daunting task. I will outline the major decisions taken by me and Ayman a long time a friend from school. We are both classmates and Alumnus of IC school which is located in Beirut. Basically its a posh school which has a very strong background in math and the sciences.
From Caveman Methods to Modern Solutions
We decided to build our own app after we found out that many residential property managers were still using excel and sending invoices to tenants each month manually. In order for the property manager to check the balance of a certain tenant, the balance in many cases did not reflect real time changes and doing so was a very laborious task on the fly. So in fact many property managers were operating caveman style.
Ensuring Viability and Reducing Risk
We commenced working on Jeerann after finding a client first rather than building an app and trying to market it to businesses. The advantage here is that you know that the product is viable and there is definite demand for it. However the drawback might be that there is the possibility of tailoring the product specifically for this client. From our perspective having a client already lessenes the risk on many fronts.
Major Decisions: Framework Choice and Data Modeling
I will start by outlining the major decision we have made along the way. Not all decisions were correct, but making decisions in many cases requires being haste rather than perfection. With software nothing ever can not be corrected, even though it might come later at a cost.
The first decision made was choosing the framework to use. I think we settled directly on using Django, because we were familiar with the python language and with the capabilities of the framework. Many well known applications were built using Django. One of the big advantages of Django is that you do not need to rediscover the wheel. This means that the modules are well thought out of, there is ample documentation, and there is less risk to steer off some where that does not follow the defined norms. The biggest positive also is that it is full stack, there no need to select one thing for the backed and another for the front end. This means that the product will be faster to bring to market, in addition to it being cohesive.
After selecting the framework a lot of time was invested on the business logic or rather the data modeling. I feel like this took the most amount of our time. This phase entailed drawing the entity relationships diagrams and constant communication with our client. So much time was spent arguing with Ayman too on defining the payments, charges, suppliers, buildings, tenants and how all these entities relate to each other with their foreign or primary keys. We settled on a certain structure that I am honestly proud of.
Designing an Intuitive UI and Tackling Multi-Tenancy Challenges
After the phase of reaching and implementing some form of basic data modelling, we started on the UI design. We wanted the experience to be intuitive rather than robotic. So from our perspective in order to register a payment for the tenant, you need to navigate to the building first and select the specific tenant, rather than doing it in one crud. This gives the user direct familiarity with data itself. Since the building is the entry point for all the data and everything should logically be accessed within this building.
One of the biggest decision we made along the way is to chose how to implement multi tenancy. Multi tenancy is the aspect of the software serving different clients. So the basic premise here is how you establish isolation between different property mangers and their data? To be continued….