Ruth

Also worth knowing before you need it: there is a way to request an expedited review, and it is not something you can use routinely. Save it for a launch-day crash or something that blocks users entirely, not for three polish fixes.

The claim-then-send ordering is the bit I was missing. I had it the other way round, which is exactly why my log is useless. Rewrote it with chunks of 100 and a claim step, finished the remaining 1,800 in about a minute.

Two hours. It was two hours. The exit code 0 is what got me: I would have found it in five minutes if it had said "applied to local database".

Before you decide anything, go and look at exactly which scopes you request, because that decides how much work verification is.

If you only ever need files the user themselves picks, the per-file scope covers it and it is not in the restricted bucket. Broad read-everything-in-their-drive access is a different category and drags you into a heavier review, which for a solo developer is the difference between an annoying week and a quarter with a security questionnaire attached.

The other thing to know before you plan around unverified: an app in testing is capped at 100 test users, and if you publish while unverified there is a cap on new users too. Those caps are not a soft warning, they are a wall you hit on a good week - and at 90 signups you are most of the way to it already.

So my order would be: check scopes, narrow them if you can, then start verification because the clock runs while you build the other things.

Pragmatic question: do you actually need dot paths at all? config.services.api.http.server.port costs zero type instantiations, autocompletes better, refactors correctly under rename, and is shorter to read. Dot-path types are a genuinely impressive trick that quietly taxes every person who opens that file.

I have removed two of these from codebases and nobody noticed anything except that the editor got faster.

It also shows you your own pattern. Mine cleared the middle first for about a year, which was a very clear message about where I was standing.

For what it is worth: moving to tsc -b with references took our full check from about 90 seconds to 12 on the incremental path. The migration is a day of converting path aliases into references and updating imports, and it is dull work with no cleverness in it, but the payoff is immediate and permanent.

Do you scrape diced onion off the board with the edge? Everyone does it and it wrecks an edge faster than the cutting does. Flip the knife and use the spine. It feels fussy for about a week and then it is just what you do.

Numbers from something similar, since "is it expensive" deserves a real answer: about 300 rooms, hibernating sockets, storage in the low hundreds of megabytes total. Bill sat under ten dollars a month and roughly 80% of it was request count, not duration. The cost model punishes chattiness far more than it punishes having many objects.

Did both last year on a similar tool, so here are actual numbers rather than opinions.

Directories: 25 submissions, 340 visits over three months, 9 signups, 1 conversion. Still trickling now, about 15 visits a week, which is free forever.

Newsletter: $600 slot, 620 clicks in 48 hours, 41 signups, 3 conversions. Then nothing.

Newsletter won on immediate revenue. Directories won on cost per visit over a year. Both were worth doing, neither was transformative.

If you do want to do something, make it a reason to come rather than a price cut. A new hot dish for the cold weeks worked far better for us than 20% off ever did.

Also check whether you actually need runtime validation in the browser or only the types. Plenty of teams ship a validator to the client to re-check data their own server just validated.

We run about 2.4 GB on D1 at peaks near 40 req/s. Simple indexed read from a colocated Worker is single-digit milliseconds at p50, our own timing, not a marketing number. The pain has been ergonomics rather than performance: seeding a realistic local database is awkward and I miss having a real psql session more than I expected to.

The trap with fourteen annuals is not the chart, it is the renewal calendar.

With monthly subscribers, churn arrives in a thin trickle you can react to. With annuals it arrives on specific days, often several at once, and it reflects how someone felt about the product months ago rather than now. Five renewals in one month means one bad month can take 12% of your revenue in a fortnight, and nothing you do that week changes it.

Put every renewal date in a calendar and treat the six weeks before each one as work: a check-in email, a note about what changed since they signed up, and an actual look at whether they have logged in. My annual renewal rate went up noticeably once I stopped finding out about them on the day.

Budget lead time as well. It is not always an instant self-serve button, and both accounts have to be set up and agreeing to it. Start that conversation with the processor before you sign anything with a closing date in it, because a deal that has to close on the 30th and a migration that needs approvals is how people end up doing something stupid.

Counting strokes instead of hunting for a feeling has made the whole finishing stage much less anxious. I was doing about triple the passes I needed.

Cheap health check you can run right now:

grep -rc " as " src | awk -F: '{s+=$2} END {print s}'

Under about twenty in a real codebase and you are doing fine. Four hundred and you have a JavaScript codebase wearing a TypeScript hat, and the fix is not more casts, it is finding the two or three places generating them.

Tried this and I was hitting the middle of the bevel, not the edge. Explains a lot.

Even where they are within their rights, a phased increase costs them nothing and keeps a four year customer. Worth asking every time.

Work out the actual pound impact before deciding how much energy this deserves. Take the affected items, multiply by last month's real sales counts, and see what 18% costs you per week. I have twice discovered that a scary sounding increase was 40 a week, and once discovered a boring one was 300.

Do the Monday close first, then hire once you can see straight.

The reason is that hiring while you are working 55 hours and doing admin at midnight means you will train badly, supervise badly, and probably hire the first available person rather than the right one. A new part-timer is not free time in month one, it is more work - recruiting, training, correcting, and payroll admin you currently do not have.

Monday costs you 900 gross, not 900 net. Take off the wages you would have paid, the stock and utilities, and it is likely closer to 500-600 of real margin. That is a fair price for reclaiming a day, getting your admin out of the evenings and being fit to hire properly in three months.

Fair, and the half-day version is probably the better first move if the client mix is nervous. My argument is mainly against hiring while exhausted.

A 220 waterstone will remove metal faster than a diamond plate at a similar price, honestly. But it will dish noticeably in one long reprofiling session and you need a flattening solution anyway, which puts you back at the same total spend. The plate wins on the arithmetic even if it loses on raw speed.

Six months is not too early to know, but the number you have is telling you something more specific than "it is not working". You are turning people away at exactly the hours the second room is empty, which means the constraint is not the room, it is having a second pair of hands at evenings and weekends.

A room only pays for itself when someone is in it. 8 hours a week against 300 a month plus the build cost is a slow road; 20 hours a week changes the arithmetic completely. I would put the effort into staffing or renting the room to a self-employed practitioner for the evening and Saturday slots rather than into marketing the room itself.