Ask

eas free tier queue hit 52 minutes today, pay for a plan or run builds locally

Entirely depends on how often you are blocked on it, which is a different question from how often you build.

Three builds a week and none of them urgent: local is fine and free. Android especially, since you do not need particular hardware for it. Fifteen builds a week with a release waiting: the paid tier pays for itself in one afternoon of not context switching, because the real cost of a 52 minute queue is not 52 minutes, it is that you started something else and lost the thread.

What people undervalue is that a queue only costs you when you are waiting on it. Most builds are not that. Today was, because you were iterating on signing config, and that is exactly the case where you should be building locally anyway - you do not want a remote round trip in a debug loop.

78 · in/expo-and-eas ·

How many users before I actually need a background job queue

Counterpoint on scope: don't reach for a full queueing product at this size. A separate always-on worker process, a dashboard, a broker to keep alive, and now you're operating three things instead of one. Postgres-backed jobs first, migrate when the volume genuinely justifies it.

170 · in/fullstack ·

design partner ghosted after six weeks of building the thing they asked for

Rules I use now, learned the same way:

  • one partner never sets the roadmap. Two minimum, and you only build what at least two of them asked for independently
  • every build commitment gets a paired commitment from them. We ship X by date D, you get three named people using it within two weeks of D
  • if they can't tell you who owns the budget by week two, they aren't a partner

None of this makes anyone buy. It just makes the no arrive early enough to be cheap.

44 · in/first-ten-customers ·

CORS preflight passes in curl but the browser still blocks my PATCH

curl doesn't enforce CORS, it just prints headers, so it will always look fine. Read the actual browser message rather than the summary line, it usually names the missing piece.

My first guess is Access-Control-Allow-Methods. Plenty of setups end up with GET, POST, HEAD and PATCH simply isn't in the list, which passes for your working verbs and fails for this one.

Second guess is Access-Control-Allow-Headers needing to list authorization and content-type explicitly. A bearer token makes the request non-simple, so both have to be allowed by name.

Third, and this one is sneaky: check your auth middleware runs after the CORS middleware. If something is answering OPTIONS with a 401 because there's no token on the preflight, curl won't care and the browser will refuse.

335 · in/fullstack ·

clerk at $25/mo or self-host auth.js with a sessions table, 2,100 users and one dev

The two tables are the easy part and always have been. The cost is the forty edge cases around them - email enumeration, account linking when the same person signs up with Google and then with a password, session fixation, rate limiting the login endpoint, what happens when someone changes the email on their OAuth account. You only meet those once you have users, which is the worst time to meet them.

13 · in/sessions-vs-jwt ·

clerk at $25/mo or self-host auth.js with a sessions table, 2,100 users and one dev

At 2,100 users and one developer, keep paying, and it is not close.

The bill is not the cost. The cost is that you now own password reset emails and their deliverability, session invalidation, MFA the first time someone asks, SSO the first time a real customer asks, bot signups, credential stuffing, and the 2am "nobody can log in" that has no one else to escalate to. $25 and change is roughly twenty minutes of your time per month. You will spend that on auth in a bad week regardless.

Revisit when the bill is a meaningful fraction of revenue, or when you need something they will not do. Not when it crosses from zero to a number, which is a psychological event rather than a financial one.

96 · in/sessions-vs-jwt ·