Case study · IInsider (Proxity ecosystem) · Product Owner & Builder · May 2026 - now

Shipping a two-service AI content platform to production in 7 weeks - solo

A self-enriching market-intelligence product for the asset-deal market: an AI pipeline that turns a noisy signal stream into a cumulative entity graph, and a subscription storefront where a human editor has the final word.

7 weeksfrom empty repo to production, solo
2 servicesAI pipeline + paywalled storefront
~29%of noise cut before spending a token
Human-gatedan editor approves everything published

Context

IInsider is an adjacent product I own inside the Proxity ecosystem. Where Proxity's due-diligence engine analyses one asset deeply on demand, IInsider watches the whole market continuously: M&A, business sales, distressed assets. On the surface it is a subscription publication; underneath, the strategic asset is not the articles but an accumulating, cross-linked graph of four entity types - news, assets, deals, and market players.

Unlike my founding-PM work at Proxity, here I owned everything end-to-end: the PRD, the architecture decisions, the code (written largely by AI agents under my direction), the deployment, and the operations.

Problem

Intelligence about asset deals is scattered across Telegram channels and business media: noisy, unverifiable, and gone from attention within days. For brokers and investors there is no accumulated history of an asset - who owned it, what was paid, which deals fell through.

Turning that stream into a trustworthy knowledge base normally requires an editorial staff. The challenge I set myself: do it with one person and AI - without publishing AI slop, and without letting LLM costs eat the economics of content.

Discovery

The design was shaped by lessons from the first system I shipped in this domain - the Proxity due-diligence engine - and by the economics of content operations:

  • Most of a content pipeline is not agentic work. Triage, extraction, deduplication, and rewriting are closed tasks with checkable outputs - they belong in deterministic, typed LLM calls, not open agent loops.
  • Credibility requires a human. Readers in a high-stakes market will not trust unattended AI publishing - so the product was designed around an editor gate, with AI producing drafts, never publications.
  • Cost discipline has to be structural. A tiered funnel - free rules first, cheap models next, a human last - decides how much each signal is allowed to cost before it proves its worth.
The key product decision: the graph is the product. News expire in days; the linked history of assets, deals, and market players compounds - and becomes the moat.

Solution

Two services with an explicit contract between them. The pipeline (Python 3.13, Pydantic AI, PostgreSQL + pgvector) runs on a schedule: rule-based triage cuts ~29% of the stream before any LLM call, typed extraction turns posts into structured signals, entity resolution links them to the graph (fuzzy blocking + embeddings, with an LLM judge only for the ambiguous middle), and a contextual rewrite enriches each item with the object's accumulated history before publishing a draft to the storefront.

The storefront (Next.js, 38-model relational domain) carries the public site, the subscriber paywall, and the editorial admin: a moderation queue, duplicate-merge tooling, and a decision journal. Editor decisions - approve, merge, reject - flow back into the pipeline at the start of every run, so the graph learns from every human call.

Rule triage no LLM · ~29% cut Parse & extract typed LLM output Entity resolution fuzzy + vectors + judge Research agent agentic loop · optional Contextual rewrite enriched with graph history Graph update 4 linked entity types Editor gate human decision · storefront decisions feed back into the next run COST GUARDRAILS free rules run first budget cap per run cost tracked per signal flags default to off
The pipeline: deterministic typed stages by default, one agentic loop (blue) for open-ended research, a human gate (amber) before anything is published - and editor decisions feeding back into the graph.

Architecture decisions were made for a one-person team and documented as ADRs:

  • Plain asyncio and a queue table instead of an orchestration framework - idempotent resume by construction, nothing to babysit.
  • A relational graph with recursive CTEs instead of a graph database - Neo4j deferred until query patterns actually demand it.
  • A JSON Schema contract between pipeline and storefront, exported from the storefront's validation schemas and enforced at deploy time - the two services can evolve independently without silent drift.

How it was built: one person + AI agents

The code was written largely by AI agents under my direction - but the reason this shipped in 7 weeks without collapsing is the process around them, the same discipline I'd expect from a full team:

  • A versioned PRD, a domain glossary with canonical terms, and MADR-format architecture decision records - the context that makes agent-written code land in the right place.
  • CI gates on every change: type checking, contract-drift checks between the two services, and smoke suites running against a real database.
  • Deliberate risk allocation: the pipeline, which runs unattended, got the full test suite (57 test files, golden-set evals); the editor-supervised storefront traded automated tests for delivery speed, covered by manual test plans and deploy-time smoke checks.
  • Dark deploys on the storefront: every release goes live with no traffic, passes a smoke test, and only then gets promoted.

The full system behind this way of working - what agents own, what stays human - is in my essay How I actually ship with AI agents.

Impact

The system is in production, pre-launch: the graph is filling ahead of the public opening. Facts from the first production day:

  • 1,167 posts ingested from the signal stream; ~29% rejected by free rule-based triage before a single LLM call.
  • 49 publish-ready drafts delivered to the storefront's moderation queue for editorial review.
  • Re-runs are idempotent - no duplicate cards, no re-spend on already-processed signals.
  • Every signal carries its own LLM cost in the database, so the unit economics of content are measured, not estimated.
  • The pipeline runs unattended on a 6-hour schedule; a two-sided contract keeps both services deployable independently.

What I'd improve next

  • Automated tests on the storefront - the speed-for-coverage trade was right for the build phase, wrong for the growth phase.
  • Expanding the golden-set evals: entity resolution and rewrite quality measured on a fixed corpus before every pipeline change.
  • Public launch mechanics: SEO surfaces on the graph (asset pages, player pages) so accumulated history starts earning traffic.
  • Revisiting deliberately deferred decisions - a dedicated entity-matching engine and a graph database - once real query patterns justify them.

Takeaways

  • The second system confirmed the thesis of the first: agentic loops are a budget to spend, not a default. Most of this pipeline is deterministic typed stages - cheaper, debuggable, and honest about what LLMs are actually needed for.
  • A human gate is a feature, not a bottleneck. The editor's decisions feed back into the graph, so human judgment compounds instead of being spent once.
  • One person with AI agents can ship what used to take a team - but only with the team's discipline: a PRD, decision records, CI gates, and tests where the risk actually lives.
  • Design cost discipline in from day one. The tiered funnel and per-signal cost tracking made the economics of AI content a measured property of the system, not a hope.
← All cases Next: PRObankrotstvo →