The conversation

vhiremath4HNSource author
Lessons learnedExperience excerpt · English

Funny story

Funny story. Before pivoting my startup to Loom, we were a user testing company named Opentest. Instead of spinning up a DB and creating a dashboard for my co-founders to look at who requested certain user tests, I just dumped everything into a Google Sheet. It was so good. No downtime. Open access. Only 3 people looking/editing, so no conflict. Didn't have to deal with database upgrades or maintenance. I often think about this decision and feel like I've learned a bunch of "good engineering practices" that pale in comparison to how being truly scrappy can be a genius unlock at any level.

Original discussionShow HN: Using Google Sheets as the back end/APIs of your app162 source comments · at import
4

What was this responding to?

Parent context · original excerpt

JO
joaovcoliveiraHN

Hello everyone! At a company I worked for, we needed to develop an MVP (basically a web page) and apply certain business logic to a Google Drive spreadsheet that was frequently updated by the Sales team. In this case, we had two options: Develop a backend to replace the current spreadsheet and have the sales team use it as a new "backoffice" - This would take a very long time, and if the hypothesis we were testing was wrong, it would be time wasted. Create the web page and use Google's SDK to extract data from the spreadsheet. We chose to go with the second option because it was quicker. Indeed, it was much faster than creating a new backoffice. But not as quick as we imagined. Integrating with Google's SDK requires some effort, especially to handle the OAuth logic, configure it in the console, and understand the documentation (which is quite shallow, by the way). Anyway! We did the proj…

Full original

Community replies 0

No community replies yet. Add your perspective.

Replies from the source 4

Direct replies available in this import. Original-language excerpts.

YD
ydantHN

Agreed. Google Sheets is a great scrappy option for a startup / small company. I've used it for a lot of system data that needs to be modified by a few people at most. With a little bit of careful code and caching (I like validating and syncing to S3) you can easily use it as a crud frontend for important system data. It also can make great adhoc dashboards - plug into APIs (even private ones if you add in custom Google Scripts code) or push data updates to the sheets. I've had rather large reports auto updated on a schedule with multiple views of the data (pivot tables, queries, lookups, etc). Fully focused customized views into the data needed to solve specific internal problems with really quick delivery times. Sure, a custom developed option should be substantially better than Google Sheets, but you won't develop it quicker. By the time you actually need something bigger/better, you …

Full original
JO
joaovcoliveiraHN

its a honor to hear from a loom founder, Ive been using your product for a long time and I love it! 100% onboard on what you said.

Full original
HO
hot_grilHN

Google Sheets is the backbone of several projects I work on, even though I'm a SWE at a large company. It's used as a fronend in some places or a backend in others. But part of this is because we have too much red tape around using simple eng tools like React or Postgres.

Full original
JA
jakjak123HN

If you can do this one-way data dump, it sounds like a good idea. The issue starts when you have seven different sheets that is supposed to authoritatively control some other processes. The people writing in the spreadsheet can basically do any kind of mutation to the spreadsheet, so it will break extremely easily.

Full original
Continue on Hacker News

Respect different perspectives. Share concrete experiences.

Sign in to post, reply, repost, and quote.