The indie developer's Google Workspace stack in 2025

Most indie developers already have Google Workspace before they write their first line of product code. Gmail came first, then Drive for project files, then Sheets for the spreadsheet that became a waitlist, then Docs for the spec that became a product. By the time you are shipping, you are already deep in the ecosystem.

That is not an accident. The free tier covers most solo projects. Google OAuth is trusted by end users at a level that no indie developer can replicate with a roll-your-own login. The data infra is maintained by a company with more reliability engineers than most indie devs have Twitter followers.

This post is about using that stack deliberately - the tools that actually matter, the patterns that work, and where it falls short enough to need help.

What the stack actually looks like

r/indiehackers discussions about tooling are remarkably consistent: at the core of most solo founder stacks is Gmail, Sheets, and Drive, usually supplemented by whatever the founder already had before starting.

Here is how those tools actually get used in practice:

Gmail handles transactional alerts more often than full transactional email. Most indie devs route their real transactional email through Postmark or Resend, but Gmail SMTP works fine for low-volume internal alerts - error notifications, new signups, Stripe webhook summaries. The daily digest you send yourself at 8am from an Apps Script trigger runs on Gmail.

Sheets is the workhorse. It starts as a waitlist tracker and ends up as a lightweight CMS, a feature flag store, a content calendar, a pricing config file, and an operational dashboard - sometimes all in one workbook. The people on r/SideProject threads regularly feature this pattern: someone builds an MVP where the entire data layer is a Google Sheet, because it is fast, it is free, and non-technical co-founders can edit it directly.

Drive is asset storage and backup. Design files, export archives, customer attachments that do not belong in your database, the occasional video demo. For solo developers without an ops team, Drive's folder structure serves as a lightweight file system with a web UI and version history.

Forms handles input collection before you have a proper form backend. Feedback surveys, beta signup intake, feature request voting. The data lands in a Sheet automatically. It is not elegant, but it ships in three minutes.

Meet is client calls, demos, and the occasional pair-programming session. The calendar integration means scheduling friction is lower than tools that require a separate account.

Sheets as a real backend - the most discussed pattern

The conversation that keeps surfacing in r/webdev and r/indiehackers is whether Google Sheets can genuinely serve as a backend data store for a shipped product.

The honest answer: for a specific class of project, yes. If the data is read-mostly, the update frequency is low, and the shape of the data fits a flat table, Sheets can carry an MVP for months. Content-driven sites, simple directories, early-stage waitlists, reference data that changes weekly - all reasonable fits.

The problem is that the raw Google Sheets API v4 was not designed for this. Responses are nested arrays of cell values. You map header rows to keys yourself. A response for a 20-column sheet is verbose enough that you end up writing a normalization layer before you can use any of it. Authentication via service accounts adds setup overhead that slows down iteration.

This is exactly the gap that SheetsAPI fills.

SheetsAPI: skipping the database for your first version

SheetsAPI connects to any Google Sheet via OAuth and generates a versioned REST endpoint that returns clean, keyed JSON - one object per row, with types inferred from cell values. The endpoint runs on Cloudflare Workers, so cold starts are not an issue and you do not manage any infrastructure.

The workflow looks like this: you have a Sheet with columns name, email, plan, created_at. SheetsAPI produces an endpoint that returns:

[
  {
    "name": "Ada Lovelace",
    "email": "ada@example.com",
    "plan": "pro",
    "created_at": "2025-09-14"
  }
]

You can filter by column value, paginate, sort. Your frontend queries the endpoint directly. Your non-technical co-founder edits the Sheet in their browser and the API reflects the change immediately.

For an MVP that needs to ship this week, this is a meaningful reduction in scope. You are not setting up Postgres, not writing migrations, not configuring a connection pool. The data store is a tool your entire team already knows how to use.

SheetsAPI is free in beta and MIT-licensed. The use cases page covers patterns in more detail - content sites, waitlists, configuration stores, lightweight CMS setups.

Drive hygiene: the problem with one account for everything

The other Google Workspace problem that r/SideProject threads surface regularly is storage. One Google account. Years of side projects. Every project generates exports, design iterations, video recordings of demos that might matter someday, backups of backups.

Drive's 15 GB free tier fills up faster than you expect. Shared folders contribute to your quota. Every Google Doc you export as a PDF and then re-export six months later creates a duplicate. The Drive web UI has no native deduplication view and no way to see what is actually consuming storage at a glance.

Drive Cleaner is a periodic audit tool for exactly this situation. It scans your Drive over OAuth, surfaces duplicate files grouped by content hash, and shows you the storage impact before you delete anything. You review, you confirm, it cleans. No new credentials - it works inside the Google account permissions you have already granted.

For a solo developer who has been using the same Google account across three or four side projects, a Drive audit usually recovers enough storage to avoid paying for a storage upgrade for at least another year.

The week in the life

Here is what a realistic working week looks like when you are building on this stack:

Monday: you push a new feature. The deployment trigger sends a Gmail alert to yourself. You check the SheetsAPI endpoint to confirm the Sheet-backed config picked up the change.

Tuesday: a user reports a bug. You pull the JWT from their session, paste it into the JWT decoder at /tools to inspect the claims, and confirm the auth scope is what you expect.

Wednesday: you want to schedule a daily cleanup job. You open the cron builder to validate the expression before wiring it into Apps Script.

Thursday: you are debugging a Sheets API response from a third-party integration. You paste the raw response into the JSON formatter and collapse the nested structure to find the field you need.

Friday: quarterly storage audit. Drive Cleaner surfaces 4.2 GB of duplicate video exports from six months ago. You delete them. Storage drops back under quota.

None of these tasks take long individually. But each one, without the right tool, is either a context switch to a terminal session or a tab you open, forget to bookmark, and re-search for next time.

The free utility layer

The GKit tools page has 50+ browser-based utilities that run with no account, no rate limits, and no setup. For developers working in the Google Workspace ecosystem specifically, the ones with the most daily utility:

• JSON formatter - API responses from Sheets, Drive, and Calendar are verbose. Format and collapse to find fields quickly.
• JWT decoder - Google OAuth tokens are JWTs. Inspect claims, expiry, and scopes without leaving the browser.
• Timestamp converter - Drive API uses RFC 3339. Convert between Unix, ISO 8601, and human-readable formats without a calculator.
• Cron builder - Apps Script time-based triggers use cron syntax. Build and validate expressions visually.
• curl builder - Construct authenticated curl commands for testing Sheets or Drive endpoints directly.
• UUID generator - Useful for stable row identifiers in Sheets-backed data stores.
• CSV to JSON - Sheets exports as CSV. Convert before feeding data into another tool or loading it into a frontend.
• Base64 encoder/decoder - Google APIs occasionally return base64-encoded content. Decode it in the browser.
• Regex tester - Apps Script runs standard JavaScript regex. Test patterns against real data before deploying.
• Markdown to HTML - Useful when Sheet cells contain markdown-formatted content you want to render on a frontend.

These are the small-but-frequent tasks that break flow when you have to context-switch to a terminal or a separate tool. Having them in one place, in the same tab you are already using for SheetsAPI config, matters more than it sounds.

Cost and comparison

For a solo developer in the early stages of a side project, the entire Google Workspace + GKit stack costs nothing. The jump to a paid tier is usually driven by storage requirements or the need for a custom email domain - not by hitting a ceiling on what the tools can do.

The competing tools for the individual pieces - Airtable as a Sheets replacement, Dropbox for storage, separate JWT and JSON utilities spread across bookmarks - each add a subscription or an account. The one-Google-login model is not a feature pitch, it is a practical reduction in cognitive overhead.

The setup that costs nothing and wastes nothing

The indie developer's Google Workspace stack is not glamorous. It is Gmail, Sheets, Drive, and a set of small tools that fill the gaps the official suite leaves open.

SheetsAPI is for the moment when you want to ship an MVP without setting up a database. Drive Cleaner is for the moment when you realize years of side project files have eaten your free storage. The tools page is for every small conversion and inspection task that would otherwise cost you a context switch.

All of it runs on your existing Google account. None of it requires a new subscription to evaluate. Get started at the dashboard, or read more about what GKit is building on the about page.

If you already know what you need, the SheetsAPI product page and Drive Cleaner page have the specifics. Pricing is published openly - no forms required.