Hi Matt,
Welcome to the community!
I fully understand the consultant -> developer nuance. :winking_face: Getting the right fit for your project requires some careful vetting. And while this is important, even when you do find the right developer, there are some additional things that should concern you as well. I’m too swamped to toss my hat into this ring, but I love tossing the architectural salad from time-to-time so here are some issues to be mindful of.
-
Assuming Airtable serves as the “backend” for your web app, your developer must establish a clear cache-forward architecture that separates the back-end from the rendering engine. Rendering web pages for 1 to n… users must pull content through the Airtable API which is woefully unsuitable for web apps where simultaneous users in numbers greater than 5 are likely. This issue relates to the number of requests the API can process to deliver requests based on queries, and with travel-related web apps, users typically perform many searches before deciding on their reservations.
-
Airtable’s API is also known for its sluggishness. This is different from the previous issue - it relates to the responsiveness of the API itself once a request has been made. Large collections of data and the need to assimilate photos at render-time can cause users to feel like the app can’t meet responsiveness expectations that most customers already have. You can see this in the example embedded frame in your Google Sites app (> 3500ms). Yet another reason that caching of data and images is a key requirement for leveraging Airtable as a backend.
-
Increasingly, businesses that operate predominantly on the web are leaning on real-time databases (such as Firebase) to provide cache-forward web experiences that meet the prime directive of 400ms response (the Doherty Threshold). Some say this is a bunch of BS but in all the apps that I created – from Laplink in the early 80’s to Stream It where we move data from Singapore to NYC in under 250ms – the analytics are clear; sustaining the Doherty threshold creates addictive use of your solution. Humans - by and large - are hooked on speed.
These three points are good reason to steer clear of any direct linkage between Airtable and web app users if scale and growth matter. Indeed, this is precisely what the folks at Stacker do. While Airtable may be ideal for many aspects of your business, injecting some realistic requirements into the engineering conversation is really important right about now.
Good luck with your project and make sure you publish the outcome in Show and Tell so we can all learn about your success.
