oll.in — the job-application agent, as a solution architecture

The product surface what oll.in actually is

oll.in is not one feature — it's a career service with three distinct surfaces, and they carry very different build risk. Naming them precisely is the whole point of an architecture: it lets us reuse aggressively where the risk is already retired, and spike hard only where it isn't.

The critical read: Surface 1 is almost entirely reuse of what oll.am already runs. Surfaces 2 & 3 carry the genuinely-new backend and the real feasibility risk — which is exactly why they go behind POCs, not into a build-now list.

The thesis lead with this

oll.am is already three frozen spines and a set of product services. oll.in is mostly a matter of pointing them at a new problem shape — a job-seeker instead of a writer, a job description instead of a manuscript. The genuinely-new code is small and well-bounded; the rest is assembly and one thin frontend.

The reuse map every surface → platform capability

Each oll.in surface maps onto an existing capability, an additive extension of one, or a genuinely-new service. This table is the heart of the architecture — read the right-hand column as the actual scope of work.

The solution architecture one picture

Same visual language as the platform diagrams: solid-black boxes are frozen spines / live services, dashed-red are genuinely-new for oll.in, dashed-blue is an external runtime. The seam is MCP. Nothing about the frozen layer changes — oll.in is a client of it.

The platform extensions needed the "in more detail" ask

Each extension is additive, respects the frozen-Core principle (never weaken an existing route), and follows the house pattern for its kind. Ordered by how much oll.in leans on it.

1 · oll-write — three JD-aware verbs new prompts, not architecture

Add tailor_cv(profile, job_description), cover_letter(profile, job_description), interview_prep(profile, job_description). Each reuses the existing _authorize_and_gate → _run_model pattern — new prompt constants only, no new architecture (per the agent-seam plan). Grounding: the applicant's CV/work history is ingested into oll-memory; retrieval supplies cited passages so output is "from real work, not buzzwords," and abstains rather than inventing when the corpus is thin. Prompts follow llm-call-contract (named constants, JSON-schema-in-prompt, fence-strip parse, input caps).

2 · foto-service — unstub Replicate extend

The scaffold, tests, guest-checkout wiring and Core-shaped error envelope already exist. The remaining work is replacing the stubbed Replicate model + photo-upload path with a real headshot model tuned for the Swiss Bewerbungsfoto (neutral background, head-and-shoulders). Feasibility of the output quality is a POC (below), not an assumption.

3 · Core — guest-checkout pair + email allow-list additive, branch exists

Both billing routes are @require_auth and email send is recipient-scoped to the authed user — so a no-login dossier sale needs the additive guest-checkout-session + guest-verify-session pair plus a guest-email allow-list (per guest-checkout-grant; PR #21). One-time payment mode already works. Never weaken the existing authed routes.

4 · Core — Radar price + event-id dedupe smaller than first drawn

Grounding correction: Core already runs Stripe subscription mode as its default (mode = "payment" if plan=="one_time" else "subscription"), and the webhook already handles invoice.payment_succeeded + customer.subscription.deleted. So Career Radar billing is mostly reuse — add a Radar price/plan and turn it on. The one real gap the grounding found: there is no event-id dedupe table (idempotency relies on naturally-idempotent upserts today). Add a ProcessedEvent table before a recurring paid plan rides the webhook (idempotent-paid-fulfillment). Entitlement stays identity-in-JWT, plan-from-/me (token-identity-not-entitlement).

5 · oll-scout — the one new service new · own Neon DB

A small service (per ADR-008 database-per-service: own Neon oll_scout) that on a cron: pulls fresh roles from legitimate job-board APIs / feeds only, stores them, scores each against the applicant's oll-memory profile via oll-model, and emits a daily digest through Core email. Stateless-to-the-user, thin, disposable. Its single hard unknown is data-source feasibility — which listing sources are ToS-compatible, well-structured, and cover Swiss/DACH with usable volume. That is POC-C, and it gates whether Radar is buildable at all.

6 · Postiz + LinkedIn OAuth new · deferred

The get-found engine self-hosts Postiz (OSS, already identified in the constellation audit as a zero-code deploy) and connects LinkedIn via official OAuth. oll-write drafts posts in the applicant's voice; Postiz schedules them after human approval. This is the highest ToS-sensitivity surface and the lowest near-term revenue — deferred to last, behind its own compliance POC.

7 · oll.in frontend new thin client

A thin product frontend that reuses ollwrite's memory-BFF pattern verbatim: the browser never names a collection or holds a service token; the BFF derives collection: mem:user:{id} from the Core JWT. Flow: upload CV → ingest to memory → paste/select a job → generate dossier (the 3 verbs) → order photo (foto guest-checkout) → pay → deliver. Reuses drag-to-cite + honest-abstain from the proactive-memory-sidecar pattern.

Identity, corpus & billing model how a job-seeker maps onto the spines

The honest pricing line the landing already commits to: a tool you own is pay-once; a service that works for you daily is a subscription. The architecture mirrors it exactly — the dossier engine is stateless-per-purchase; Career Radar is the only thing that needs a recurring relationship, and it's the only thing that carries subscription billing.

POC-first plan parallel feasibility lanes

Sam's method: prove feasibility in multiple POC integrations before building out, chunked so the lanes run in parallel. Each POC below states a hypothesis, the smallest integration that tests it, and a binary pass signal. They share nothing at runtime, so they can be worked concurrently — and each one independently green-lights (or kills) a chunk of build-out.

Build-out chunked, each gated on its POC

Only after a POC passes does its chunk get built out. The chunks map 1:1 to POC lanes, so the same parallelism carries through. Sequence reflects revenue proximity and risk, not a rigid waterfall.

Compliance & the honesty line non-negotiable

Decision points for Sam batched, with recommendations

1. Kick off which POCs now? A (dossier quality), B (photo), C (scout source) are independent and parallel-able today. Rec: start A + C first — they're the two master gates.
2. oll.in frontend stack — reuse ollwrite's Next.js + memory-BFF verbatim, or the house Angular/Ionic? Rec: Next.js — reuse the ollwrite BFF, drag-to-cite, honest-abstain wholesale.
3. Dossier billing — guest pay-once (no login, foto pattern) or account-based for the pack? Rec: guest for photo-only; account for the full pack so the corpus persists.
4. Approve the additive Core subscription mode? Needed for Career Radar; additive, behind POC-D + the merge-gate. Rec: yes, but only build after POC-C proves a data source and after the first franc.
5. Career Radar data source — this is the real unknown; POC-C is a research spike. Rec: run POC-C as a pure feasibility spike before committing any Radar build.
6. Presence / Postiz — deploy now or defer to Chunk 4? Rec: defer — lowest revenue, highest ToS care.