Building Apps for Clients

I have built one app for a client.  For that app, I started with the app in my account and when we got the first version complete we transferred it to my client.  This worked alright, except as we went to make enhancements, I would constantly have to ask my client to add data sources and scripts in automations. I had access to all the files and I would even create many of the files, but I couldn't add the files as data in the app for some reason. Is there a solution to this?

In thinking through how would do this again for another client, I feel like it would be easier if I just kept ownership of the app, gave them access to the app as users, and then I billed them for their usage.  This would also allow me to continue to provide support and build some costs for that management into the pricing (i.e. maybe I charge $15/user/month and google will be billing me $10/user/month, leaving that extra $5/user/month to cover my time managing the app). Are there any drawbacks to this approach I should consider? How are other consultants solving this problem?

1 3 275
3 REPLIES 3

Many consultants, including myself, opt for the method you initially outlined: developing the app within our own account and transferring it to the client once the initial version is complete.

  • One improvement on this process is to ensure that the client grants you editor access to their data sources, enabling you to make changes and updates efficiently without the need to continuously request permission.

For ongoing support and enhancements, I prefer to structure a separate agreement with your client for each "dev run". This can involve setting up a new scope of work and providing a quote for each subsequent development phase they request.

  • Clients often appreciate this setup as it allows them to incur costs only when they need additional work, rather than committing to ongoing charges that they may find unnecessary at times.

Regarding retaining ownership of the app and billing clients for usage, while this model simplifies administration and provides a residual income for continued support, it's important to consider:

  • Client's desire for data sovereignty and app ownership.
  • Potential scaling complexities as your client base grows.
  • Liability risks related to data security and app performance.
  • Some clients' preference for a one-time cost structure instead of a subscription model.

It’s essential to weigh these considerations and discuss them with your clients, balancing their need for autonomy and ownership against the ease of ongoing support from maintaining control over the app.

For more detailed strategies on managing major updates when you have active users, I recommend watching the "How to manage Major Version Updates (when you have users in the wild) || AppSheet Explained" video.  This video provides excellent insights on how to use actions like (Force Sync), communication strategies for planned updates, and the use of [Temp] columns during the transition. These tips are invaluable for ensuring a smooth update process that avoids user interruption. 

____________________________________________________________________________________

Ultimately, the decision on how to manage client apps should align with your business model, your clients' preferences, and the complexity of the app enhancements needed. Open and clear communication with your clients about each approach’s pros and cons will help establish a mutually beneficial working relationship.

  • This, of course, is only my opinion and I know other devs out there have taken the subscription approach; I'd be curious to hear their thoughts on the matter.

Thanks for the feedback. We were being fairly iterative in the build of the app and tried to get a simple solution out to them quickly, then kept building on it.  The annoying issues mainly started happening after they had that initial version. At that point, I had edit rights to all the data files (google sheets) but I still wasn't able to actually add them into the app, the client had to go in and do that.  That and then adding scripts in automations.  Those were probably the 2 most annoying things.  Aside from that I didn't really have an issue with that model. Have you worked around those 2 issues somehow in the past?


@devblock wrote:

At that point, I had edit rights to all the data files (google sheets) but I still wasn't able to actually add them into the app, the client had to go in and do that. 


This is definitely something that's a pain point with working with AppSheet

  • Back in the day if you had edit permissions to the app, you could add new tables and connect external things to the app - it was great!  But once Google took over, they put a stop to that.
  • They sited some security reason, but we were all like: yeah... but I was granted access by the owner, so..... ¯\_(ツ)_/¯😂

____________________________________________________________________________________

The solution I Settled On

  • Spin up a dedicated account for the app
    • This way it's all housed in one place
    • Anyone can be given access through sharing the login credentials - and since this is a separate account, you're not sharing your actual Google account.
Top Labels in this Space