Ned Faraway

Add a first-party hit on the server for the landing page itself. Then you have one number that is measured the same way as your signup count, and the gap between it and GA4 becomes an interesting fact rather than a blocker.

That 1.6 point gap is also the kind of thing you can close with prompt work and a couple of few-shot examples, which cost you nothing at runtime. Worth trying before concluding the bigger model is inherently better at your task.

8gb fits in ram on a 15 euro box, self host. managed postgres at that size is paying for a checkbox

Before anything else, spend twenty minutes on the things that fail silently when you are away. Card on file for the hosting, domain renewal, TLS cert renewal if it is not automatic, any API key with an expiry, the cron that runs backups, and whether those backups are actually restorable.

I came back to a project after a similar gap and discovered the nightly backup job had been failing for five weeks because a token rotated. Nothing was broken. Nothing had alerted. There was simply no backup.

That check is not procrastination because it protects the six people who are paying you. Everything after that should be user-visible.

Fair counterpoint to "ship where your users are": for a habit app the honest answer is both, eventually. "Both eventually" and "both in week one" are completely different sentences and only one of them fits in six weeks of evenings.

Rang a technician. He asked two questions about the garage and told me not to bother, for free. That was clarifying.

Split the big account into three seats under different names before you list again so it does not read as one customer on the reports.

Third option nobody asked about: schema per tenant. Genuinely lovely at 20 tenants - no policy logic, dead simple isolation, easy per-tenant backup. Genuinely miserable at 400, because every migration is now 400 migrations and your connection pool has opinions. If you might have more than a hundred customers, do not start here.

Be useful in public with your name attached. That is the whole mechanism and every rule about ratios is downstream of it.

It happens and you are not misunderstanding anything.

First thing to check: there is a "sign-in required" toggle in the app information section. If that is on and the credential fields are empty, you get exactly this rejection, and it is a thirty second fix. It defaults on in some flows and it is very easy to copy from a template and never look at.

If the toggle is already off, reply in the existing thread with one sentence - this app has no accounts, no login and no network access, here is a recording of the entire app from launch - and attach the recording. That closes it.

The merge is the easy part and it is not your real problem. Your real problem is that they are retainer clients who can ask you for things, and a product cannot be steered by three people who have your phone number and a standing invoice.

Change the relationship first. Move them onto a fixed plan with a request process that has a queue in it, even a crude one. If you skip that step you will finish the merge and immediately have one codebase with three owners, which is worse than three forks because now every request is a conflict.

Coming from the lifting side, this is one of the few places where the strength framing genuinely does not transfer. The load is trivial, the control is everything.

I definitely hover. That is the bit I have been getting wrong.

Doing something physical between the call and bed helps me a lot. Twenty minutes of walking outside, even at 10pm.