Forum Discussion
ChayceDuncan2
6 years agoQrew Cadet
It's hard to give a blanket answer. Everyone is different in how they want their organization to work. You could certainly build one big app - and you'd be just fine. You could also build a 'hub and spoke' idea, where you have different apps that are all isolated into smaller chunks/specific purposes - and then you use Quick Base syncs or automations to make them all talk to one another so it still acts like one big system.
The nice part of one big app is that it's all in one place. No one has to worry about 'where' some information might be or where they have to go for it, its just in one place etc. The backdrop to that is that you have everything going on in one place, so you have to be more careful with development as your changes might have big impacts once you go to production.
The advantage of having smaller apps - is that it reduces some of the complexity, especially when it comes to user management. If you think about a true ERP - you'll have 100 people with generic or specific job functions. Since each would be siloed - some people could be in some apps but not others. With one big app - you have to be constantly checking and re-checking permissions - and you end up with a big list of roles to account for people who have abnormal job functions or are kind of floaters and just do a lot of things.
Others on this forum may have a different answer, but personally, I would suggest segmenting it all out. The development lifecycle and user management controls of having different apps makes managing everything easier in the long run. Especially if you're planning for growth - going in with the hub-and-spoke mindset will help in later adoption for 'simple' or one-off apps that you can put together quickly that may not be part of your true ERP system, but can make a difference for small teams. If everyone is used to smaller, more specific apps, their adoption is usually better.
Chayce Duncan | Technical Lead
(720) 739-1406 | chayceduncan@quandarycg.com
Quandary Knowledge Base
The nice part of one big app is that it's all in one place. No one has to worry about 'where' some information might be or where they have to go for it, its just in one place etc. The backdrop to that is that you have everything going on in one place, so you have to be more careful with development as your changes might have big impacts once you go to production.
The advantage of having smaller apps - is that it reduces some of the complexity, especially when it comes to user management. If you think about a true ERP - you'll have 100 people with generic or specific job functions. Since each would be siloed - some people could be in some apps but not others. With one big app - you have to be constantly checking and re-checking permissions - and you end up with a big list of roles to account for people who have abnormal job functions or are kind of floaters and just do a lot of things.
Others on this forum may have a different answer, but personally, I would suggest segmenting it all out. The development lifecycle and user management controls of having different apps makes managing everything easier in the long run. Especially if you're planning for growth - going in with the hub-and-spoke mindset will help in later adoption for 'simple' or one-off apps that you can put together quickly that may not be part of your true ERP system, but can make a difference for small teams. If everyone is used to smaller, more specific apps, their adoption is usually better.
Chayce Duncan | Technical Lead
(720) 739-1406 | chayceduncan@quandarycg.com
Quandary Knowledge Base