Half blueprint with grid layout and half aerial photo showing irregular grass paths and trees

Episode 3: Breaking Point in a Small App

Written by:

Overview

I built a small application and started running it on Google Cloud.

At first, everything felt simple enough.

But as the app grew, two problems became impossible to ignore:

  • Infrastructure costs were higher than expected.
  • Real users behaved differently than I imagined.

This is the story of how I started rethinking my database setup and reducing unnecessary costs.


The Cost Problem

My Google Cloud database was costing around $7.75 per day.

At first, that didn’t seem like much.

But over a month, it adds up to more than $200.

For a small application, that felt hard to justify.

It was the first sign that my architecture no longer matched the actual size of the project.


What User Testing Revealed

The second issue came from user testing.

When I test the app myself, everything feels obvious.

I know the flow, the logic, and how each feature is supposed to work.

But real users don’t think like developers.

They click unexpected buttons, take different paths, and get confused in places I never considered.

That gap exposed usability issues and design assumptions I couldn’t see on my own.


Rebuilding the System

So I started reviewing my infrastructure.

With the help of AI, I explored alternative PostgreSQL setups that better fit the current stage of the product.

After several rounds of testing and comparison, I ended up with a much simpler structure:

  • Local Development → Supabase PostgreSQL
  • Cloud Run → Supabase PostgreSQL
  • Cloud SQL → Removed

Removing Cloud SQL should reduce costs by roughly $15–30 per month.


The Reality of Building

To be honest, I wasn’t worried as much as I was annoyed.

Infrastructure changes are rarely exciting.

They are the kind of tasks you keep postponing because they feel tedious.

But looking back, I’ve done this many times before.

Something feels bigger than it really is.

Then I finally start.

And a few hours later I wonder why I waited so long.


What I Learned

One thing I’ve learned is that many technical problems look more complicated from a distance.

Once you begin working on them, they often become manageable.

Not easy.

Just smaller than they appeared.


Moving Forward

The migration is done.

The architecture is simpler.

The monthly cost is lower.

And the product is a little closer to matching its actual needs.

Honestly, it still feels a bit improvised.

But that’s part of building.

Ten years ago, I wouldn’t have had this many options.

Today there are services like Supabase, Cloud Run, and AI tools that make experimentation possible for solo builders.

Free tiers alone are kind of amazing.


Closing

Building a product is rarely a straight line.

Most of the time it’s a series of small adjustments, unexpected discoveries, and course corrections.

This was one of them.

And for now, that’s enough.pp, I would really appreciate it.

Real user feedback is one of the most valuable inputs in this process.

Leave a comment