Part 3 in this series of tracking the development of a new app for a small business in the business of residential lettings and property management.
Good progress! The easy phase is nearly over – in other words, importing the existing datasets from our previous system and then relating them together. So the app is now (or will very soon be) displaying an impressive series of connections and relationships between the following datasets:
This has been a great opportunity to weed out unnecessary data – with my previous system (Filemaker) it was very easy to add fields to an existing dataset – consequently I ‘bolted on’ extra features and functions throughout the last 9 years or so. Whilst that might seem flexible – actually, it created lots of unused data that we don’t need. With Appsheet, in order to add “fields” you need to return to the source table and create another column, then go through a ‘schema regeneration’ process. This is actually good I think – it encourages correct table/data design in the first place. Thankfully, having already managed databases I have a good idea of what we do and don’t need.
Another lesson is breaking down the datasets – previously all our property data was in one table. Now, our property info is spread across 3 tables (addresses, utilities and particulars). This is because not every address is going to be in our management portfolio – eg, we don’t need information on utilities for an address that is a supplier.
The process has also cemented some design of information flow. The app is not going to be public – it’s only for staff. But we still need clients, tenants etc to be able to submit data. So this is achieved by integrations between our website forms and the same table data that the app accesses.
Also, the app is not going to store files – previously, I didn’t really design document management as a separate system from our database – all our records were within the database and retrieved in PDF format on demand. However, this is vulnerable.
With the new app, it will automate appropriate records, documents and PDFs to be sent to clients etc as required – however. It will also save copies to a separate cloud storage area. That way, records and data can be deleted from the app but, for audit trail purposes, documents will still be available in a long-term archive.
Part 2 of this series tracking the progress of the development of an app for our internal business management and workflow.
After an evening with Google Appsheet I finished with a fairly pleasing app on my phone containing property and people data. The 2 respective data sources (tables) for these are Google sheets – this is neat because the same tables can be used for receiving data from online forms. So, for example, a visitor to our website can (via an online form) register their details into the same table as that used by the app. Meaning that staff do not have a data-entry role when registering new people. That’s an improvement and a nice ‘marginal gain’.
The next challenge is to create a relationship between these tables and then create some basic functionality. eg, when I view a property, I want to see who the tenant is and who the landlord is. This looks fairly straight forward although seems to work a little differently to what I’m used to. Once this is resolved, then most of the data-storage and views will be very similar to incorporate – eg, I need a table for log records, a table for inspections etc. And, again, with relationships created between the tables, I should be able to view all the associated people, logs, inspections etc for any given property.
The other area to think about is data and GDPR. ❤
The other consideration is how to break-down our existing datasets into more manageable chunks. For example, each property has details about the address, and utilities, and particulars for marketing – these probably need to be 3 different tables and not one?
So schema design and setting up the primary keys (unique references that will be used in the relationships) are important.
Hopefully, in my next blog on this subject, I’ll have a skeleton app with multiple tables and relationships. Then I can start to look automation and functionality.
In 2013 when I started trading with Proudhouse, I knew that I would need a software management system. Spreadsheets and MS Office lacked functionality. I knew that I would need to automate repetitive tasks etc. I also knew that it would be very difficult to employ staff in the absence of an easy-to-use interface that would ensure consistent results and outputs.
Very long story short: With initial guidance from a friend, I learned how to develop our CRM environment with relational database software called Filemaker.(https://www.claris.com/filemaker/)
It has since been the foundation of our office and management processes. However, I bought lifetime licences to FM13 and we’re now out of date. Furthermore, although it works over a VPN to our office, it’s not Cloud based. And in addition to cost, there are other challenges to migrating it to a Cloud based version of Filemaker.
So – we have a challenge: we need a new system. Over the last 12 months we have trialled other industry solutions. But they’re not suitable – the flexibility and bespoke nature of using our purpose-built solution has spoiled us.
So our requirements are:
Cloud based solution
Predominantly mobile-app based technology allowing staff to work and update records from anywhere
Easy, intuitive interface
Ability to develop and support from in-house (ie, I’m the support guy)
No-code or minimal code solution
Integration with existing software in use
The solution so far seems to be Google AppSheet. We use Google Workspace anyway. I’ll blog every step until our solution is up and running. Let’s see how this goes!