DEV Community

Eddy Kim
Eddy Kim

Posted on

I used Google Sheets as a database and it actually worked


I know. You read that title and thought "that's a terrible idea." Hear me out.

I needed a Gantt chart for my team. We tried Notion, Monday.com, even a brief moment of insanity with MS Project. Every tool wanted us to learn their way of doing things. Enter data HERE, use THIS view, upgrade to PRO for the feature you actually need.

Meanwhile, our project schedule was already living in a Google Sheet. It had everything — tasks, dates, assignees, status. We just couldn't see it as a timeline.

So I built a web app that reads from that sheet and renders a Gantt chart. That's it. That's the whole product.

Why Google Sheets is actually fine as a database

Before you roast me in the comments — I'm not suggesting you build your SaaS on Google Sheets. But for a scheduling tool used by a small team? It's weirdly perfect.

Everyone already knows the interface. No onboarding. No training. Your PM who's scared of terminals can add a task by typing in a cell.

Collaboration is built in. Multiple people editing the same sheet simultaneously? Google solved that problem years ago. I didn't have to build any of it.

Backup and version history for free. Every change is tracked. You can roll back to any previous version. Try getting that from a SQLite file.

The API is solid. Python's gspread library makes it trivial to read and write. I had CRUD operations working in under an hour.

The tradeoff? It's slow compared to a real database. You won't be running complex queries. But for a schedule with a few hundred rows? You'll never notice.

The part that surprised me

The moment it clicked was when I edited a row in the spreadsheet, switched to the browser, clicked Refresh, and saw the Gantt chart update instantly. No deploy. No migration. No cache invalidation. Just... data flowing.

That feedback loop changed how my team works. People stopped asking "how do I add a task?" because they already knew. Open the sheet, add a row, done.

Turning it into a product

After using it internally for a while, I figured other small teams might want the same thing. So I spent a few days cleaning it up:

  • Ripped out all our company data
  • Translated the UI from Korean to English
  • Wrote documentation (this took longer than the actual code changes)
  • Built a packaging script that scans for leaked credentials before zipping

The stack is React + TypeScript on the frontend, FastAPI + gspread on the backend. Nothing exotic. I wanted something any developer could deploy in an afternoon.

I put it on Gumroad for $19 as a source code package. Honestly, I'm more interested in learning how marketplace selling works than making money. But if someone gets value from it, that's a nice bonus.

What I'd do differently

If I started over, I'd probably add an option to use it without a backend — having the frontend call the Google Sheets API directly. Right now you need to deploy two services (static frontend + Python API), which is fine for developers but rules out non-technical users.

That might be v2. Or it might not. We'll see.

Try it

Live demo: https://sheetschedule-demo.netlify.app/

The demo is connected to a real Google Sheet. You can see the task list, timeline, project filtering — all of it pulling from a spreadsheet.

If you want to run your own: https://goodhap.gumroad.com/l/sheetschedule

The repo includes deployment guides for Netlify, Railway, Render, and Google Cloud Run. Setup takes about 15 minutes if you've deployed a Python app before.


Happy to answer questions about the Google Sheets API integration or the productization process. It was more work than I expected but also more fun.


Top comments (0)