I named the same side project nine times before I wrote any of it down

Sunday night, three weeks ago. I opened a folder called amzapp looking for a developer secret I was sure I had saved somewhere. Six other folders turned up instead: larify, arify, amz, Amzs, skayel360, brevlin. Every one of them held a piece of the same side project - an Amazon seller profit tracker I had been building on and off for months. None of them held the whole picture.

If you keep a side project alive between real work, you already know this feeling. You open it up after a gap, and the first hour goes to onboarding yourself back into it instead of building. Which folder is current? Which key still works? What you tried last time and why it failed?

I spent that hour again, then finally did the thing I should have done the first time. I stopped trying to remember and wrote it all down in one place instead.

The confusion was never the API

Amazon's Selling Partner API has real sharp edges:

• Four logins that look identical but grant completely different access.
• Two credential types that sound interchangeable and are not.
• Three separate approval processes hiding behind what looks like one login.

None of that explains months of stalling. What explains it is nine names, spread across six folders, and nothing connecting them. Every session started from zero. The blocker was never Amazon. It was that a single place holding the truth never existed.

The four logins, one table

This part is worth stealing even if you never touch Amazon's API. Any platform with a separate developer console and business console has some version of this trap.

I burned real time on one wrong assumption: full access in the developer console grants nothing on a seller's actual data. Two systems that share a login page and share nothing else.

Two credentials, one has a permanent kill switch

The other trap worth writing down. Your app has a client id and secret. Every seller who connects gives you a separate refresh token. You need both to call anything.

Here is the part that should be printed on every API onboarding page and rarely is. Generating a new refresh token does not invalidate the old one. Amazon says this outright in the console. If a refresh token ever leaks, re-authorizing does nothing at all. Rotating the client secret is the only way to kill it - the token exchange cannot happen without one.

I would not have known that without reading the fine print twice, and I would not have remembered it three weeks later without writing it down where I could find it.

What fixed the stall

One file. A single page naming every identity, every credential, where each key lives, and which assumption already cost real time. Every time something changes, that page changes with it, in the same sitting, never later.

The API had not gotten any simpler when the stall broke. I had stopped re-discovering the same three facts every time I came back to the project.

The number that made me fix this

Nine names. Six folders. Zero of them cross-referenced. That count came from sitting down and checking, the night the map finally got written.

A scattered set of folders. A half-remembered decision from two months ago. A key you are pretty sure still works. If your own long-running project has a version of this, the fix here is small, smaller than it probably feels like it should be:

• One page.
• Updated the moment anything changes.
• Read before you touch anything else.

Your turn

How many names does your oldest side project have right now, and do you know which folder is the real one?

If this was useful: I work through this in public, the wins and the freezes both, mostly on LinkedIn and YouTube. If the real version of building in the open is useful to you, that is where it lives. Find me on X, GitHub, and the work at next8n.com.