Skip to main content
Question

Newbie looking for help on the best application architecture for a complex app

  • May 13, 2019
  • 0 replies
  • 136 views

Hello, I am very new to Quick Base and playing with the trial.  While under the trial I am most certainly not going to fully develop this app, but my hope is that I can find a platform in a way to make an ERP system for my company.  Basically a hybrid of an architectural firm and contractor in one so we need to manage projects from design through opening day.  Many phases, many deliverables, etc.  One of my goals is to take what is now independent systems and combine into one:

Project Management Software
CRM
Expense Tracking
Communication Tools
File Storage (for project related material) 
Etc.


So my question is do I develop all of this one application or will that be cumbersome?  Should i build a Contact Manager App, an Opportunity Manager App, a Project Management App and share data or build all under one master application?  

The architecture of Quick Base seams to support individual apps, but most people through forum seem to say one big app.

Currently we are 50 employees and expecting to go through a nice growth period.  But we have a long time until we are in the hundreds count (although certainly hope to get their one day!)

Thanks in advance

This topic has been closed for replies.

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

  • Author
  • Registered
  • May 14, 2019
Thanks Chayce,

I really do buy into the simplicity of future development if nothing else.  For example one major component of the app is going to be to maintain a database of contacts, the contact manager.  That seems to me like it would be a fairly simple system to quickly build out and keeping it isolated could be a real benefit.

I noticed your quick base sync note....  Would I need to sync data or can I just reference tables across apps?  Just wanted to ensure there is no significant performance loss in doing that.  It seems like that would work well on my end but not sure if that creates security issues or otherwise.

You can certainly use cross-app relationships. By the time I realized I left that out of my answer - I was unable to edit. Its certainly a feature to use when setting up this kind of environment

Chayce Duncan | Technical Lead
(720) 739-1406 | chayceduncan@quandarycg.com
Quandary Knowledge Base

Another factor to consider is that when the user opens the app they will land on a dashboard. And of course they can only land on one dashboard for a given app. Yes they can have buttons to take them to different dashboards.

But if you have different apps it does mean that you may have a better opportunity to land users on a relevant dashboard. If you have users which use an app for servers quite different purposes then it�s hard to know what dashboard to land them on.

  • Author
  • Registered
  • May 17, 2019
Oh wow this is a great point and might point me in another direction.  I do want different users to have different initial views.  So I cannot configure it based on role?  It is based on app?

For example I want all users to see their tasks throughout the entire system, but I want Project Managers to see Project Status on their home page, Sales team to see sales pipeline and opportunities, designers to see project status for what they are working on etc.

I cannot create different dashboards based on roles?

Thanks again for the help, this is really great for getting started!

You can definitely assign Roles as to which dashboard they land on so that is no problem.

The point I was making it was that if a user is using an app for multiple quite different purposes then you have to decide which dashboard you�re going to land them on.

I guess it depends how pigeonholed you�re going to make your Roles. You don�t want to go to crazy on the number of Roles because it stars to make you crazy in assigning which Roles users belong in and maintaining these Roles.

.Roles come up in dynamic form rules and in permissions so you do not want an app that has 20 Roles.