Theo

NodeLocal DNSCache plus proportional autoscaling of CoreDNS killed it entirely. Two weeks with no morning burst.

Gently: at $1,100 in revenue this is a couple of tens of dollars a month. You have found an optimisation that is real, verifiable and satisfying to fix, which is precisely why it is dangerous - it feels like work and it is not sales. Set a reminder to revisit at $10k and go find customer 49.

Practical note on "invalidate the download": use short-lived signed links rather than a permanent URL, and regenerate on each visit. If your links live forever then revoking access only stops the person who did not think to keep the URL, which is not the person you are worried about.

Also: log in once, not forty times. Do the login in global setup, save storageState per role, and load it in the specs. On most suites the UI login is a bigger chunk of runtime than anything database related, and it is the flakiest step you own.

Beginner answer since I did this three months ago: set up search console on day one, submit a sitemap, and then do not check it daily like I did. My first post took nine days to get indexed and I convinced myself something was broken about four separate times. Nothing was broken. It just takes a while, and there is no button.

Option B is not the embarrassing choice you think it is.

select * from reminders
where due_at <= now() and sent_at is null
order by due_at
for update skip locked
limit 100

once a minute. 5,000 a day is 3.5 a minute. One table, one query, one cron. Edits are an UPDATE. Cancels are a DELETE. At 3am when something is wrong you can see the entire state of the system with a SELECT, which is worth more than people admit until the night they need it.

Take a photo every day too. Slow changes are impossible to judge by memory and a two-week photo series tells a much clearer story than a description.

This is the bit people miss. You get the issuing country back on the charge, so you can run a weekly query for discounted subscriptions with a mismatching card and deal with those five accounts by hand. In eighteen months mine has been about four accounts, two of which were genuine people travelling.

Small warning from experience: check every gap behind and under kitchen units, and make sure windows and the loft hatch are shut. A frightened cat in a new house will find a space you did not know existed, and getting them out of one is worse than the hiding itself.

Everyone over-rotates on this at four customers. The honest practical answer is that you will either use a merchant of record or you will not, and either way you must not build tax logic yourself. Rate tables change, thresholds change, evidence requirements change, and none of that is your product.

What I would actually do this week: keep selling, switch the plan to a merchant of record, and spend the saved evenings on getting to forty customers. Just do not tell yourself you are compliant when you are only postponing.

Measured it over four days and it is a lot more consistent than I thought. Appointment booked with the numbers written down.

This is the step that surprises everyone, and it surprises them roughly two days before the planned handover date. Anyone reading this mid-deal should open the request now and let it run in the background.

Whichever you pick, do it in a staging cluster first at the same versions, same add-ons. Not as a formality - I have caught a broken admission webhook and an operator that did not support the new API version that way, both of which would have eaten the entire window.