I've built quite a few dashboards while working on proof-of-concept feature/product engineering. Even though people often think I'm joking, almost always the backend database was a Google Sheet. Google Sheets has great API support, easy to write functionality, convenient read and file dumps, works well with Pandas/SQL, and has a universally appreciated UX. Data validation can be annoying if the "admin" directly enters data, but for building a proof of concept, nothing beats Google Sheets. The data from Google Sheets would be passed through an API to a web UI/dashboard. The dashboard I built for end users was a simple Bootstrap (Vue-Bootstrap) table from the API, with enough easy-to-use filters and views to work out of the box. If the data was too large, I would use a templated snippet to convert the JSON into a card view. Ignoring long-term maintainability, this was one of the most foolproof ways to build dashboards. After that, I'd slap Firebase Auth on top, and that was it.
I haven't worked on these types of projects for nearly two years now. Folks I know use Retool or Softr with an API connectivity platform like Portable, Pipedream, or Zapier. If you're staring at a spreadsheet on a daily basis, the next step should be looking into an app builder combined with an API connection platform.
Monzo (online bank in UK) let you see all your transactions in a Google sheet (with some caveats e.g. interest earned is skipped). I wanted to make a total wealth chart over all years.
It's so damn complicated in Google sheets. In MS Excel I could simply make a pivot chart, apply any aggregation on days/weeks and be done with it. But with Sheets I had to make a new aggregate column, filter data in another new column, and make a chart on that.
Your comment does explain that API is why they export to sheets and not excel but Google sheets is way behind in ease of use.
You're fine with Google seeing complete information about your income and spending? I'm not one of those truly paranoid, but this seems like a bit too much.
+1 for googlesheets. It is stable, and provided you don't exceed the API limits, you can run a lot of data through it.
Appscript is also incredibly powerful if you work with tools that have decent APIs. With a few lines of js and the built in trigger functions, you can have an automatically updating dashboard with email notifications when certain conditions are met (e.g. balance too low, user engagement metric does X etc).
I've built a scrabble tournament management app on google sheets, because it was the easiest way I could think of to let multiple people edit it with all the others seeing live updates. From a developer's point of view it kind of sucks, having to maintain everything in one large javascript file and having to use spreadsheet tabs as input and output, not to mention manually attaching the script to a new sheet for every tournament. But the user experience has been excellent, modulo a few permissions glitches.
I'm still trying to rewrite it as a self hosted web app this year because the aforementioned permissions glitches and the difficulty of doing versioned deployments has made me reluctant to continue relying on google, but overall sheets has been a huge boon and we have gotten years of use out of it.
The article mentions appsheets, which I absolutely loved in my last role.
Brilliant for knocking up very simple internal tooling off the back of a Google Sheet. Most importantly, there was zero fucking around with IT on it, as it was already included in our workspace package.
Back in 2010, I was in a work meeting making small talk and we were discussing how cringe some advertising is nowadays. One of us, a program manager who was ~15 years my senior told me it's because we're not the target demographic and that millennials are targeted differently, mainly through word-of-mouth and generally Guerrilla marketing tactics.
Whenever I see articles like these and comments like yours, I can't stop thinking about that meeting.
Edit: to clarify, I am not accusing you of anything. But I do suspect the article to be part of a Google marketing campaign.
If I want a database set up in minutes just to focus on the business side and nothing else, I simply fire up a new Django project (I suspect any other framework with an ORM and auto-generated CRUD UIs would be equally competent for that).
I have nothing against Google Sheets, I really haven't put much thought into it in this context, but I would need some convincing that it's a better and easier way to kick things off.
That Django project needs a host to run on, even if it's just your local machine.
If you want others to interact with it, you need to expose it to the internet through some means and think through the security implications of doing so.
The Google Sheets approach doesn't need you to manage a process or web server. It is instantly shareable while letting Google worry about security, performance, availability, etc.
The specifics of the "what's better?" ratio can shift depending on comfort level / experience with either product, or what infrastructure you may already have available to deploy to. But building on top of GApps does mean you get a lot of useful aspects "free".
You can just query a database and work with the results directly . In a dynamic language like python there is little advantage to loading rows into classes. That Django query language is so painful and opaque.
In small business accounting, I have a persistent need for a FileMaker Pro like solution for invoices. FMP was conscious of on-screen layout and print.
ReTool has been recommended as similar replacement for FMP but they don’t have the idea of creating print-ready documented receipts and invoices. You don’t even need to print it, you just need to keep it for the IRS.
I love the idea of using Google Sheets and turnkey app building apps. But I still need documentation.
I tried going all on on Google Sheets earlier this year. I used the Python API and like almost nothing worked consistently.
I got 1 sheet to work well with like 1k rows and thought woohoo this is great! So I went all-in, put 25k rows in and Google pooped the bed. It gave errors all the time, rows and columns were funky. API issues galore.
SQLite however handled 25k rows without any errors, always rock solid.
I gave up. Overall a terrible experience once I got past 1k rows. I'm glad it's worked well for you.
I only had like 10 columns, so it wasn't like massive amounts of data. I was linking to a file out in Google Drive and that was where most of my issues were. Google drive's API was 99.99% completely useless.
My takeaway from the experience was, Google proclaims they have an API, but it seems more like nobody tests it or cares about it. Perhaps it's malicious compliance, they have it because they have to have an API, but not because they expect anyone to actually use it.
Yes, many of our customers hit the issues you mentioned as they scale spreadsheet-based applications. We built Big Tables for this case: https://www.glideapps.com/big-tables
You keep most of the convenience and programmability of a spreadsheet, but you get Postgres scale and a first-class API (which includes atomic table swapping for updating large datasets). It also supports live updating of any views displaying that data.
Thank you for discussing this openly, it can be a real bummer to write something, test it, have something work up to a point then fail due to situations outside your control.
You probably just saved me about 20 hours of coding.
If you have more than a few thousand records, this is the wrong tool for the job. I've used Google Sheets as a "database" for a few applications in the past. In each case, it was an internal tool that did not generate more than a few thousand records, if that.
Even text files (like CSV) are fine for the amount of data the OP has trouble with, and Excel certainly is, so it’s unclear why Google Sheets should already balk on that. Google Sheets has a limit of 10 million cells per sheet (so for 25000 rows that would be 400 columns), and really shouldn’t be running into errors for sheets below that limit.
I guess? 25k rows with 10 columns shouldn't be a big deal. LibreOffice, Excel, Numbers, they all handled this data without trouble.
It is 99% static data, it would be updated maybe once a year if that. The point was to give users something they were familiar with to look at the data, search it, etc. While being in the "cloud" so I only had to update one place whenever I do get tasked with an update and to handle authn/z easily with no hassles.
Anyways, I used SQLite and a very simple web frontend(it had 3 screens: search, table view and record view). Solved the problem and moved on. Search just filtered the table view.
> If you have more than a few thousand records, this is the wrong tool for the job.
Just to be precise, Google Sheets might be the wrong tool for the job. Other spreadsheet applications can handle "more than a few thousand records" easily, seems this is a Google Sheets specific issue.
The projects I worked on always had a mechanism to dump data into a proper database. For example, I built a daily scraper to collect some of the inventory. I didn’t keep all the data in a single sheet. Instead, all the data was stored in a cloud-based managed SQLite or PostgreSQL database, or sometimes a local SQLite database. Only the day's data was stored in Google Sheets because the client wanted to see the spreadsheet themselves and have the UI be accessible for their users.
I have had a similar experience with their API. Very verbose json structure, lack of stable row IDs, inconsistent data types.
And being a spreadsheet, it also has to have styling/formatting details, complicating it even more.
There are extensions that let you query Excel worksheet files directly from SQLite (no importing, no transformation, just direct query). It's quite fun to do; you can use Excel (or Libre office, etc.) to maintain the spreadsheet, and build reports with SQLite.
Starting with a Google Sheet is perfectly fine, but for building a non tabular user interface, or having a few thousand records, I would directly switch to something like SQLPage with a SQLite database.
Founder of Glide (YC W19) mentioned in the article — thanks for the recognition. This was not an ad from us, we were surprised by the coverage.
Glide’s customers are businesses building software for internal use. During YC we called these “dark apps” but since then we call them “apps for work.” We wanted something usable by IT and operations staff (not developers) that emphasized design and UX.
Glide started as a simple spreadsheet-to-PWA trick but is now a complete programming model and runtime platform for data-driven business apps, including APIs, databases, responsive layouts, a managed AI system, and workflow automations.
One of our Crown Jewels is our data editor, where you program your app with our reactive computed columns. Our data grid has become a popular open source component: https://grid.glideapps.com/
You can also try our new AI-native builder experience, where we’re trying to simplify building even further. It’s very early but just shows our continued effort to make building software simpler: https://glideapps.com/create
I know a few people who started to use glide for personal apps and were put off by the price. ($200/mo for over 3 personal apps is a bit tough).
They showed me what they were doing and that was absolutely incredible for people without programming experience. They integrated with spreadsheets and llms and their PDF collections of manuals for devices etc.
But as lower-income people they were stopped in their tracks and I found that really sad that there isn't an option for non money-making or business supporting applications. In their case they were all doing that for their hobbies or for supporting their aging parents and giving them tools to handle their tasks, chores and care.
I second this. I'm guessing you're limiting access at a lower price point because you're worried too many business customers will opt for the lower cost plan when they should be on the higher priced one? I would pay somewhere in the neighborhood of $10/mo or so for a personal plan that had more than your free tier and less than the business one.
I’ve had the same experience. I really want something of this quality that is accessible to hobbyists or folks managing non revenue generating things — any kind of social organization could really benefit!
I haven’t used Glide yet, but I’ve worked extensively with other ‘front-end interfaces for Airtable and Spreadsheets’, like Softr, Noloco and Bubble.
The first time I tried Glide, I struggled with the interface, and unfortunately, support didn’t respond to my messages, so I had to take a different direction.
That said, I’d love to give Glide a try. It’s incredible that we have direct access to founders like you here on HN.
Congrats on your success! From your perspective, where do you see no-code and low-code heading, especially with AI dramatically lowering the barriers to coding?
Thank you! Please let me know how your second attempt goes.
AI and no code platforms will merge into new high-level software creation tools. We already view Glide as a hybrid—try our AI component for the bottoms-up view. Our top-down AI approach will soon be live in our onboarding.
I favorited it back then. Glad to see it's doing well, it looks like a cool product. I haven't found a reason to use it yet but that's also because I have slowed down on coding personal projects after work in general.
During COVID, I built a quick no-code solution to help ‘all-inclusive resorts’ in Cancun and Punta Cana. It started with guests scanning a QR code, filling out a short form, and scheduling their Antigen/PCR tests. Over time, it evolved to help nurses manage operations, streamline test results, and send certificates via email.
What began as a DIY project during lockdown scaled quickly to Mexico City, the Dominican Republic, and Barcelona, processing over 30,000 tests the day after New Year’s Eve. Using Airtable, an Airtable extension called miniextensions.com, and tools like Docusign, Make, Sendgrid, and Twilio, the solution ended up supporting over 1 million tests. I handled all technical aspects, support, and training myself.
Since the solution was meant to be temporary, I prioritized speed and reliability. Airtable’s relational database capabilities were crucial, especially compared to spreadsheets, for managing multiple linked tables and automations. Airtable also offers a REST API and a pretty amazing self- actualizing database schema that can be copied into tools like GPT or Claude for added context. You can build powerful tools with its scripts, interfaces, and automations.
That said, Airtable is best for use cases with fewer than 250,000 records per month. Above 100,000 records, the web platform’s performance can suffer, though there are workarounds. It’s perfect for small to medium-sized businesses needing custom API integrations for CRMs or internal tools.
On a related note, today I built a cool Airtable automation using ChatGPT and custom scripts. By filling out a corporate email in a form, the system scrapes the web for details like company name, address, phone, fax, and more, which then populates the CRM automatically. I’m still experimenting and plan to make a YouTube video about it soon. Here’s the loom video I sent to a friend about it: https://www.loom.com/share/b9ddbefbdce5434da378667fc2079d00?...
This is very impressive considering the real-world complexities surrounding it, but you've taken that complexity and turned it into a fairly simple work-flow with minimal coding. I've been developing software professionally for nearly 20 years and I find these kinds of projects to be fascinating. I started out my career with a mixture of coding and non-coding "integrations" (hacks) with other software. Over the years I've fallen in the typical "how can I build this from scratch" trap, but in many cases - as you've proven - that's not always the best decision. Kudos and thanks for sharing!
This is great and I look forward to your YouTube video. It is intriguing to me since you went you choose existing tool and piped the entire workflow vs to build the entire thing from scratch in Python, for example.
In the demo Loom video, the part where you are scheduling an appointment, it looks very calendly like but it is not. Did you build the entire UI and UX yourself?
I've recently been toying with the idea of turning my overly complicated weightlifting Excel into an overly complicated me-only webapp / testflight app. It can't be worse than Excel for iOS!
I use Google Forms to send data to a Google Sheet. You just put whatever lifts you have in the Form with spaces to add weights. I use this Google Form --> Google Sheets thing for a dozen different things.
Not just totally aligned, but also "just-in-time" and ephemeral: an LLM goes and does/builds it on request, and then destroys all artifacts when the request has been fulfilled?
If the persistence of something incurs a cost in storage and security, and the traditional penalties of efficiency and learning-curves are removed, why not recreate it every time its needed?
I organize my life with spreadsheets and it works great. Running Spreadsheet, Health Spreadsheet, Investing Spreadsheet, Gardening Spreadsheet, on and on. :) It's just the best way to examine the data that is your life and have any hope of remembering the past and improve the future.
My wife had surgery last summer and had about 10 medications she needed to take immediately afterwards - each of them had their own period so I needed to know what we took, and what was "overdue" at any point in time.
I whipped up a spreadsheet in google sheets and added a google form that allowed me to quickly pick a medication that was just taken - it'd enter it into the sheet and an "overview" page would show me what was pending, with color coding if something was "overdue".
I felt like I was abusing what a spreadsheet was meant for but it worked quite well.
If I knew about Glide I probably could have made it look even nicer.
I think the mobile form factor has something to say about that. I somewhat agree (reluctantly) for desktop usage, but spreadsheets are too complex to be ergonomic with small touch screens.
Readit News
I haven't worked on these types of projects for nearly two years now. Folks I know use Retool or Softr with an API connectivity platform like Portable, Pipedream, or Zapier. If you're staring at a spreadsheet on a daily basis, the next step should be looking into an app builder combined with an API connection platform.
It's so damn complicated in Google sheets. In MS Excel I could simply make a pivot chart, apply any aggregation on days/weeks and be done with it. But with Sheets I had to make a new aggregate column, filter data in another new column, and make a chart on that.
Your comment does explain that API is why they export to sheets and not excel but Google sheets is way behind in ease of use.
I'm still trying to rewrite it as a self hosted web app this year because the aforementioned permissions glitches and the difficulty of doing versioned deployments has made me reluctant to continue relying on google, but overall sheets has been a huge boon and we have gotten years of use out of it.
Brilliant for knocking up very simple internal tooling off the back of a Google Sheet. Most importantly, there was zero fucking around with IT on it, as it was already included in our workspace package.
Supabase is free and checks all the boxes in addition to having auth, vector search, logs, security, and not being ... Google
Whenever I see articles like these and comments like yours, I can't stop thinking about that meeting.
Edit: to clarify, I am not accusing you of anything. But I do suspect the article to be part of a Google marketing campaign.
I have nothing against Google Sheets, I really haven't put much thought into it in this context, but I would need some convincing that it's a better and easier way to kick things off.
If you want others to interact with it, you need to expose it to the internet through some means and think through the security implications of doing so.
The Google Sheets approach doesn't need you to manage a process or web server. It is instantly shareable while letting Google worry about security, performance, availability, etc.
The specifics of the "what's better?" ratio can shift depending on comfort level / experience with either product, or what infrastructure you may already have available to deploy to. But building on top of GApps does mean you get a lot of useful aspects "free".
You can just query a database and work with the results directly . In a dynamic language like python there is little advantage to loading rows into classes. That Django query language is so painful and opaque.
these 2 tools is great for easy/fast prototype various project and honestly its kinda hard to replace
In small business accounting, I have a persistent need for a FileMaker Pro like solution for invoices. FMP was conscious of on-screen layout and print.
ReTool has been recommended as similar replacement for FMP but they don’t have the idea of creating print-ready documented receipts and invoices. You don’t even need to print it, you just need to keep it for the IRS.
I love the idea of using Google Sheets and turnkey app building apps. But I still need documentation.
I got 1 sheet to work well with like 1k rows and thought woohoo this is great! So I went all-in, put 25k rows in and Google pooped the bed. It gave errors all the time, rows and columns were funky. API issues galore.
SQLite however handled 25k rows without any errors, always rock solid.
I gave up. Overall a terrible experience once I got past 1k rows. I'm glad it's worked well for you.
I only had like 10 columns, so it wasn't like massive amounts of data. I was linking to a file out in Google Drive and that was where most of my issues were. Google drive's API was 99.99% completely useless.
My takeaway from the experience was, Google proclaims they have an API, but it seems more like nobody tests it or cares about it. Perhaps it's malicious compliance, they have it because they have to have an API, but not because they expect anyone to actually use it.
Perhaps I'm just not cool enough for Google.
Yes, many of our customers hit the issues you mentioned as they scale spreadsheet-based applications. We built Big Tables for this case: https://www.glideapps.com/big-tables
You keep most of the convenience and programmability of a spreadsheet, but you get Postgres scale and a first-class API (which includes atomic table swapping for updating large datasets). It also supports live updating of any views displaying that data.
You probably just saved me about 20 hours of coding.
It is 99% static data, it would be updated maybe once a year if that. The point was to give users something they were familiar with to look at the data, search it, etc. While being in the "cloud" so I only had to update one place whenever I do get tasked with an update and to handle authn/z easily with no hassles.
Anyways, I used SQLite and a very simple web frontend(it had 3 screens: search, table view and record view). Solved the problem and moved on. Search just filtered the table view.
Just to be precise, Google Sheets might be the wrong tool for the job. Other spreadsheet applications can handle "more than a few thousand records" easily, seems this is a Google Sheets specific issue.
Glide’s customers are businesses building software for internal use. During YC we called these “dark apps” but since then we call them “apps for work.” We wanted something usable by IT and operations staff (not developers) that emphasized design and UX.
Glide started as a simple spreadsheet-to-PWA trick but is now a complete programming model and runtime platform for data-driven business apps, including APIs, databases, responsive layouts, a managed AI system, and workflow automations.
One of our Crown Jewels is our data editor, where you program your app with our reactive computed columns. Our data grid has become a popular open source component: https://grid.glideapps.com/
You can also try our new AI-native builder experience, where we’re trying to simplify building even further. It’s very early but just shows our continued effort to make building software simpler: https://glideapps.com/create
Thanks again!
They showed me what they were doing and that was absolutely incredible for people without programming experience. They integrated with spreadsheets and llms and their PDF collections of manuals for devices etc.
But as lower-income people they were stopped in their tracks and I found that really sad that there isn't an option for non money-making or business supporting applications. In their case they were all doing that for their hobbies or for supporting their aging parents and giving them tools to handle their tasks, chores and care.
The first time I tried Glide, I struggled with the interface, and unfortunately, support didn’t respond to my messages, so I had to take a different direction.
That said, I’d love to give Glide a try. It’s incredible that we have direct access to founders like you here on HN.
Congrats on your success! From your perspective, where do you see no-code and low-code heading, especially with AI dramatically lowering the barriers to coding?
AI and no code platforms will merge into new high-level software creation tools. We already view Glide as a hybrid—try our AI component for the bottoms-up view. Our top-down AI approach will soon be live in our onboarding.
I favorited it back then. Glad to see it's doing well, it looks like a cool product. I haven't found a reason to use it yet but that's also because I have slowed down on coding personal projects after work in general.
What began as a DIY project during lockdown scaled quickly to Mexico City, the Dominican Republic, and Barcelona, processing over 30,000 tests the day after New Year’s Eve. Using Airtable, an Airtable extension called miniextensions.com, and tools like Docusign, Make, Sendgrid, and Twilio, the solution ended up supporting over 1 million tests. I handled all technical aspects, support, and training myself.
Since the solution was meant to be temporary, I prioritized speed and reliability. Airtable’s relational database capabilities were crucial, especially compared to spreadsheets, for managing multiple linked tables and automations. Airtable also offers a REST API and a pretty amazing self- actualizing database schema that can be copied into tools like GPT or Claude for added context. You can build powerful tools with its scripts, interfaces, and automations.
That said, Airtable is best for use cases with fewer than 250,000 records per month. Above 100,000 records, the web platform’s performance can suffer, though there are workarounds. It’s perfect for small to medium-sized businesses needing custom API integrations for CRMs or internal tools.
If you’re interested, I wrote a brief case study about the project here: https://rashidazarang.com/covid-testing.
On a related note, today I built a cool Airtable automation using ChatGPT and custom scripts. By filling out a corporate email in a form, the system scrapes the web for details like company name, address, phone, fax, and more, which then populates the CRM automatically. I’m still experimenting and plan to make a YouTube video about it soon. Here’s the loom video I sent to a friend about it: https://www.loom.com/share/b9ddbefbdce5434da378667fc2079d00?...
In the demo Loom video, the part where you are scheduling an appointment, it looks very calendly like but it is not. Did you build the entire UI and UX yourself?
OT nitpick, but isn’t this “New Year’s Day?” Or did you mean January 2nd?
didn't even know you can embed videos on HN!
There are now quite a few reliable FOSS version of no-code tools (but the mobile space seems to be missing alternatives). Few nice no-code FOSS that I love using are listed at https://blog.n0c0de.com/articles/1635ef6f-f616-8023-b336-ff3...
https://github.com/bcspragu/stronk
Might inspire you as you continue to develop your app
I exported most of my data from "Strong" into Stronk, was easy. Thanks !
The interface showed lbs, but my values were all kg, still works.
Deleted Comment
I want a simple front end that lets me log lifts to a sheet/database
For all the apps that are supposed to make this easier none of them do it right.
[0] https://www.hevyapp.com/
It's interesting to think there's still a market for this type of small scale enthusiast application.
One scenarios I've been thinking about recently is the death of the generic app.
If LLMs end up being able to create software easily, why wouldn't we choose to have software that's totally aligned our specific needs?
If the persistence of something incurs a cost in storage and security, and the traditional penalties of efficiency and learning-curves are removed, why not recreate it every time its needed?
As an analogue to this; would each iteration adapt and evolve in the same way an organism might?
Deleted Comment
Deleted Comment
I whipped up a spreadsheet in google sheets and added a google form that allowed me to quickly pick a medication that was just taken - it'd enter it into the sheet and an "overview" page would show me what was pending, with color coding if something was "overdue".
I felt like I was abusing what a spreadsheet was meant for but it worked quite well.
If I knew about Glide I probably could have made it look even nicer.