TenaCity

The handover was built on six conditions. The application had to run locally, draw its language work from Claude, stand on a fresh database, deploy to a live address, answer to a single admin account, and sign that admin in from a personal domain. While they are not outwardly noticeable features, they establish the ownership needed to run this application.

The review queue presents each job with its contacts and drafts, a character meter for the length-limited channels, and controls to edit, approve, or reject. A sending layer moves approved drafts out through two channels. Approved and verified email goes through Resend, gated by a per-user switch that holds sending off until it is deliberately turned on. Approved LinkedIn messages take an operator-run path, bundled into a prompt for Cowork from a button on the navigation bar, which allows manual send from the user.

A feedback loop records the outcome of each message and turns the results into notes that shape later drafts. The database enforces ownership. Every table has a rule that limits a query to the rows owned by the signed-in account, and a query asking for more returns an empty result. The Prompt templates and pipeline schedule tables hold settings shared across accounts. Any account can read both by design.

A model given a blank page writes a message that reads as machine-written. A guessed email address damages a sending domain that takes months to rebuild. A posting link changes or expires, and matching it allows the same job enter twice under a new link. A synchronous scrape blocks the application until a long run finishes. Each of these repeats on every job the pipeline touches.

The Non-Existent Endpoint

The provider swap moved the application off OpenAI and onto Claude. One adapter was removed, another installed, and all six model call sites were repointed to Claude Haiku 4.5. This model was chosen because the tasks are high-volume and light. Every request then failed with a not-found error that looked like an authentication problem. Tracing the actual request revealed that the installed adapter was dropping the address segment that routes to the model. This meant that the correct credentials were landing on a non-existent page. The fix pinned the full endpoint in one shared file and pointed all six call sites at it. A deployment reads the endpoint from the code because the shared file is now the only place it exists.

The Key In The Public Slot

The database was built by hand from the migration files, in strict order. The automated tool was set aside on purpose. The files contain repeated date-prefixes that confuse its ordering. Forty files were applied in order, updating the database from zero tables to twenty.

During this setup, the configuration published to every visitor's browser had a master key in the public key's place. Any site visitor would have had unrestricted access to the database. A cloned project's safety must be checked. Accordingly, I read the published configuration directly and found the key there.

The Twice Repeated Function

Rewriting the scheduling function to accept a new argument created a second copy of it. The database treats a different argument list as a separate function and leaves the old one in place. For a short period two versions existed at once, and the application could have bound to either. I then listed every version of the function, which revealed the duplicate. I removed the old version by naming its full argument list, and a final listing confirmed that only the intended version remained.

The Remaining Phase Work

I renamed the seeded owner account to my email, which brought its working configuration across untouched, and gave it a login and a display name. Deleting a user is irreversible and cascades to everything linked to it, so I confirmed the placeholder account by name and address before removing it. I then published the project to a fresh private repository, deployed it to a live address, and wired it to that address through the database vault. Login email routes through Resend over custom SMTP, and the sign-in template sends a six-digit code, which signed in on the first test.

A second round of work took the scraped-titles cap up to its configured value. I changed the resume parser to merge derived job titles into the existing target list instead of overwriting it, and changed the editor to re-read the saved list so additions appear. I curated the target-title list by hand, cutting 29 leftover seed candidates to a core of 12. An editable start-time control went into the scheduler, showing the local hour beside coordinated universal time. Labeling the picker with the current date resolved a daylight-saving confusion. I recolored the dashboard and chose a new display typeface out of preference.

Scheduled Features

• Multi-source ingest, for postings to arrive from company career boards through their applicant tracking systems.
• The Fit Brief, a short document for a single job that correlates the company and the role with the skills and background on record, including the mismatches.
• An application assist. For each job that clears scoring it would tailor the resume to that posting and prepare the application content, then leave the operator to review and submit.

Four Insights

1. Diagnose before scoping. The not-found error and the clone crash both looked worse than they were until a single variable was tested in isolation.
2. Build correct code. The pinned endpoint file does not depend on anyone remembering a value.
3. Sequence the database ahead of the code. Every table existed before any code pointed at it, and the code that followed ran clean.
4. Confirm the result after a structural change. The listing step that caught the duplicate function existed only to check an assumption, and it prevented a hard-to-trace bug.