SaaS · In development
The decision
The sign-in link origin is never derived from a request header
Whos signs users in with a magic link. The tempting move is to build that link from the request Host header, as half the tutorials do. But a header can be forged: call the API with a chosen Host and the sign-in link goes to an attacker domain, where the user authenticates without noticing anything. So the origin comes from an explicit environment variable, and the Supabase redirect allowlist is the last barrier. The consequence is deliberate: a deployment with no configured origin does not work. It fails closed, not open.
The problem
Prospecting by hand is four separate jobs that get muddled together and done badly: finding who to contact, checking the contact point is genuinely public, writing an angle that does not read like a mail merge, then following up at the right moment without hounding anyone. Bulk-sending tools solve the fourth by ignoring the first three. That is exactly how you get the messages everyone deletes.
My role
Solo, end to end: data model, authentication, generation pipeline, interface, billing, deployment.
What was hard
The expensive part was not writing the code, it was deciding what counted as a real defect. An adversarial review produced a long list of findings; most did not survive the question "show me the input that breaks it". The ones that did were fixed. That sorting is harder than it looks: a plausible, well-written finding gets fixed on reflex, and you end up complicating code that was fine. The rule I settled on: until you can write the concrete failure scenario, it is not a defect, it is an anxiety.
Where it stands
Live and operational. Authentication, generation and billing are in place; the product continues to evolve.