MyCornerman

Why it exists

Looking for work is lonely in a way that is hard to explain to anyone not doing it. You send applications into a void. Most are never answered, and the few that are rarely say why. With nothing coming back, there is no way to tell whether the problem is the market, the posting, or you — so after long enough, you assume it is you.

A layoff makes it worse. The job goes, the routine goes with it, and so do the people you saw every day and the reason to get up. Then, at the exact moment you have least to give, you are expected to go sell yourself to strangers, cheerfully, over and over, into the same silence.

This was built in the middle of that, out of more than 150 applications — not as a product idea, but as the thing its author needed and could not find. Everything on the market was built for the employer, or sold a percentage that meant nothing, or quietly treated the person as inventory.

A cornerman does not fight for you. He tells you the truth between rounds, patches up what is bleeding, and sends you back out — and he has no stake in the fight except yours. That is the entire design brief: honest when honesty is unwelcome, but never cold, and never leaving someone to work it out on their own.

• The protective half is free, forever, no card. The person most likely to be hunted by a fake posting is the one least able to spare $9.95. The entitlement gate is scoped to the model-backed read, not to the scam, harvester and ghost-job checks.
• There is no match score anywhere in the product. A percentage is a guess wearing the clothes of a measurement, and a false one is cruel in both directions. The read gives a plain call and the reasoning behind it, so it can be argued with.
• Reframe, never invent. Nothing is written into a resume or letter that the person did not already say about themselves, and every stretch is flagged before it is sent.
• The seeker is the client, never the product. No posting text crosses between accounts, no profile is sold or shared, and the whole account can be exported or permanently deleted from inside the product.

What it is

A seeker-first job-search tool. A person pastes a job posting and gets an honest read: whether it shows the markers of a scam or a resume harvester, whether the title matches the actual job, whether it has been reposted for months, and whether it genuinely fits their background. It then drafts a tailored resume and cover letter from their own profile and audits every claim that stretches.

Architecture

One Node process serves both the JSON API and the built single-page app. That gives one origin, no CORS, one place that owns the Content-Security-Policy, and a single DNS record. The alternative — a static host plus a separate API — buys nothing at this size and costs a class of cross-origin bugs.

Analysis runs in two layers. Deterministic heuristics score integrity and produce flags that cite the exact text that triggered them. A model layer then reads substance on top: what the job actually is, whether the title is a costume, how the duties divide, and an honest fit verdict with no percentage anywhere. The model layer catches its own failures, so an outage degrades the product rather than breaking it.

Nothing written into a resume or letter comes from anywhere but the person's own profile, which makes a wrong fact in that profile expensive. Any flagged claim can be corrected in place: the person says what is actually true, the model proposes the edit, and nothing is saved until they confirm it — then the materials can be rebuilt from the corrected record.

Ghost detection compares postings across every account, but only as fingerprints. Postings are reduced to a hash, a company+title key and word trigrams; the comparison happens inside the database through a SECURITY DEFINER function whose return type is the enforcement — dates, a flag and a similarity number. No posting text, employer or owner ever crosses between accounts.

Security posture

• Row-level security on all eleven tables, every policy keyed to the caller's own auth.uid(). Application code never decides who sees what; the database does.
• Privileges granted explicitly per table. The anon role holds nothing at all — stricter than Supabase's own default, which grants blanket select and relies on RLS alone.
• Billing tables are readable only by the account they describe and writable only by the server. Otherwise any signed-in user could mark themselves subscribed or zero their usage meter with one HTTP request.
• Stripe webhooks are verified against the raw request bytes before anything is trusted. Unverified events are refused; a handler failure returns non-2xx so Stripe retries rather than silently losing a payment.
• Two Content-Security-Policies: the API can load nothing at all, and the page is scoped to itself plus the Supabase origin, with no inline script and no eval.
• Secrets exist only in host environment variables. No key of any kind appears anywhere in git history — audited across every commit.
• Account export as JSON and permanent deletion, confirmed server-side by typing the account email. Deleting also removes those postings from the shared ghost-job corpus.

Operating limits

The service runs as a single instance on purpose. The per-minute burst limiter keeps its counters in memory, so a second instance would not share the model-spend budget — it would double it, at exactly the moment traffic spikes. Monthly usage is metered durably in Postgres and is what a subscription allowance is enforced against.

Spend ceilings are set per account and for the service as a whole, so an unmetered public endpoint cannot run up the operator's bill overnight. The service-wide daily ceiling is the backstop that abuse cannot scale past.

The entitlement gate is deliberately not applied to the whole analysis route, because the protective checks live in the same handler as the paid substance read. Gating the route would put scam and ghost-job detection behind the card for the people least able to pay it.

Launch readiness

Worked through against a published launch checklist for consumer apps. Most of it did not apply — there is no user-generated content shown to other people, no mobile app, no health or children's data, and no third-party analytics, advertising pixels, session recording or chat widgets anywhere in the product. The fonts are self-hosted. That leaves the consent and tracking obligations moot by construction rather than by policy.

• Consent stated before input. Every screen where a person types to a model says so above the box, before they type — the follow-up thread, the profile interview and the resume builder.
• Agreement at the button that forms the charge, both documents one click away, rather than on a page a person has to go looking for.
• Every data processor is named in the privacy policy — model provider, database, host, mail sender and payment processor — with what each one receives.
• Terms state the price, auto-renewal, how to cancel, and the refund position — fourteen days, refunded if no model-backed read was spent; cancellation is two clicks through the processor's own portal.
• The charge is legible end to end: the statement reads MYCORNERMAN.AI, the receipt names MyCornerman, and support is an address on that domain — because an unfamiliar name on a bank statement is a leading cause of chargebacks.
• A written breach plan exists (who decides, what to contain and rotate in the first hour, who must be told and how fast) — written for a product whose data is unusually useful for impersonating somebody.
• Dependency licences are MIT, BSD-2-Clause, Apache-2.0 and OFL-1.1 throughout. No GPL or AGPL anywhere; third-party notices are generated from the installed dependency tree and served from the site.

Tested, rather than reasoned about

Policies that have been written are not the same as policies that have been tried. These were run against live production.

• Acting as a stranger — no session, using only the publishable key that already ships in the browser bundle — every one of the tables refused with HTTP 401, and an anonymous insert was refused the same way. An empty 200 would mean RLS filtered the rows; a 401 means the anonymous role holds no grant on the table at all. Both layers are present.
• Every policy read individually. All of them test ownership — auth.uid() against the row owner — on select, insert, update and delete, rather than merely testing that somebody is logged in, which is the most common way this is got wrong.
• The cardless trial exercised end to end on the live database: a new account created, a posting read, and the counter moved against the trial rather than the monthly allowance — the failure that would otherwise have been invisible.
• Backups confirmed present, not assumed. Dated backups are on file and restorable; nothing in the product relies on the host's object storage, which backups exclude.

Known gaps

Stated rather than omitted, because a technical overview that lists only what is finished is a sales document.

• The privacy policy and terms are written from what the code actually does, but have not been reviewed by a lawyer. They should be before this is marketed at scale.
• Three moderate advisories sit in a transitive dependency of the .docx resume parser. The affected path appears to be the library's CLI entry point rather than the one used here, but the input is a file supplied by a stranger, so that deserves confirming rather than assuming.
• Cross-account isolation is covered by the offline suite but has not been exercised between two real accounts against live Postgres. The grant-level refusal makes a leak unlikely; unlikely is not tested.
• No keyboard-only or screen-reader pass has been done end to end. Some of the people this is built for are job hunting because of a disability.
• One person holds every credential. There is no second pair of eyes on a deploy and no recovery path if that laptop is lost.

Commercial model

The deterministic protective layer is free, permanently, with no card. It costs nothing per use and it is the half that protects someone who is being targeted.

$9.95 a month covers the model-backed half: substance reads, follow-up conversation, tailored materials and the resume interview. Cancellation is two clicks through Stripe's own portal and requires contacting nobody.

The first 30 days are free and no card is asked for. A new account gets fifteen model-backed reads inside that window — enough to carry two or three real applications end to end, which is what it takes to judge whether the thing works, and enough to cap a throwaway address at about a dollar. When someone does subscribe, the Stripe trial runs for the days still remaining from their signup date, not a fresh thirty from checkout.