← Blog
ARCHITECTURE5 min read

Building one login for every Dekimu app

Apr 19, 2026Dekimu

Dekimu is an ecosystem of small tools for freelancers. One login, one bill, one account. That sentence took one week of engineering work and is worth every hour.

We could have shipped InvoiceUp with its own auth, HelpMeNegotiate with its own auth, and told users to juggle two passwords for tools that share a brand and a checkout. That's the path most indie hackers take. It moves fast until the moment you ship the second app — then the friction compounds forever.

The shape of the hub

accounts.dekimu.com owns the user. Every other app delegates authentication to it. A user signs in once, gets a short-lived JWT, and every Dekimu app verifies that token locally — no network call per request, no shared database, no Clerk, no third party we don't control.

Each app only knows: the user's id, their email, and which apps they've unlocked. That's the smallest possible surface area. Invoices stay in InvoiceUp. Negotiation drafts stay in HelpMeNegotiate. The hub doesn't care what any app does with its data.

What we refused to build

No tracking cookies. No analytics on the auth domain. No cross-app behavioral data. The auth cookie is security-only — it signs you in and it signs you out. If we wanted to surveil users, we wouldn't have bothered owning this layer.

Every hub-and-spoke system eventually leaks data back to the hub. We designed ours so the leak has nothing to carry.

Why now, before the second app

The cost of adding a shared account system grows with every app you've already shipped. Migrating one app's users is doable. Migrating three is painful. Migrating five is the thing you promise to do next quarter and never actually do.

We wrote the hub before HelpMeNegotiate launched so the second app could be born into it. The third app will cost almost nothing. The tenth will cost almost nothing. That's the whole point.

ARCHITECTURE
← Back to blog