Your Spreadsheets Aren’t Bad, Starting Them Is

This week, my partner was trying to answer a simple but surprisingly hard question:

If I keep my US EST work shift hours but visit in Korea, what would my schedule look like when in Korea?
And if I want to be off on Saturday–Sunday in Korea, what does that mean for my US schedule?

This is the kind of problem people always solve with a spreadsheet.

And it’s also the kind of problem spreadsheets are terrible at starting from scratch.

Normally, this turns into:

• Manually listing days

• Converting time zones by hand

• Copying and pasting rows

• Renaming columns

• Creating “another tab just in case”

• Realizing halfway through that the structure is wrong

• Starting over

Not because the math is hard, but because the thinking has to happen before the spreadsheet exists.

Spreadsheets demand structure before clarity.

Humans need clarity before structure.

That mismatch is where most spreadsheet pain comes from.

Instead of opening Google Sheets, we described the problem in plain language:

• EST work hours

• Korea timezone

• Weekends off in Korea

• Same working hours, just translated

• Then… “what does my daily life actually look like?”

From that description, a spreadsheet was generated:

• A weekly schedule showing EST ↔ KST

• A modified schedule reflecting weekends off in Korea

• A daily breakdown into time slots

• Separate tabs to keep things readable

• A structure that could be refined step by step

It wasn’t perfect, but it didn’t need to be.

It answered the real question:

Can I actually work there like this?

And it did that without us having to “think like a spreadsheet user.”

The important part was this shift:

We didn’t build rows and columns.
We externalized reasoning.

The spreadsheet became a representation of the thinking, not the place where thinking had to happen.

That’s the difference.

Most people don’t struggle with spreadsheets because they’re “bad at Excel.”

They struggle because spreadsheets ask them to:

• Design systems

• Normalize data

• Anticipate future use

• Choose layouts

• Avoid breaking automation

…before they even know what they want.

That’s backwards.

I’ve been building a small tool that does one thing well:

Turn plain-English descriptions into clean spreadsheet structures.

Not dashboards.
Not advanced automation (yet).
Not “AI magic.”

Just:

• Tabs

• Columns

• Rows

• Structure

• Iteration

• Documentation

The boring but critical foundation that most spreadsheet problems actually fail on.

You describe what you’re trying to figure out.
The spreadsheet appears after the thinking, not before.

If you’ve ever said any of these:

• “I know what I want, I just don’t know how to structure the sheet”

• “This spreadsheet got messy fast”

• “I rebuilt this three times”

• “I hate starting from a blank sheet”

• “I use spreadsheets to think, not just calculate”

…then you’re probably the audience.

If you only ever open spreadsheets to sum numbers, this probably isn’t interesting.

That’s okay.

You probably could.

If I asked AI this question directly, I’d get an answer.
Maybe even a nicely formatted table in text.

But here’s the difference I felt immediately:

AI gave me an explanation.
I needed something I could keep working with.

I wasn’t done after the first answer.
I needed to adjust assumptions, split days, add detail, compare weeks, and see how changes affected everything else.

That’s where plain chat breaks down.

The moment you want to iterate, refine, or see the whole thing at once, you end up manually rebuilding the structure anyway, usually in a spreadsheet.

What mattered here wasn’t intelligence.
It was a persistent structure.

I’m not launching anything yet.

I’m sharing because I want to see who leans forward when they read this.

The goal isn’t mass appeal.
It’s resonance.

If this post made you think:

“Yeah… that’s exactly how I use spreadsheets”

Then I’m probably building for the right people.