Built work

Systems I’ve Built

I build small, practical systems for workflows that are too manual: crawl evidence for technical SEO, outreach tracking for sales execution, and implementation support around tracking, performance, and web operations.

This page shows two main working systems, selected labs, and implementation details from the build.

View ILCrawler View ReachLog View labs

Where this fits

wpfixpath.work

Bounded repair work for WordPress, WooCommerce, GTM, GSC, Core Web Vitals, and technical cleanup issues.

indexlane.dev

Systems, automation, crawlers, outreach operations, analytics/tracking implementation, and AI-assisted build work.

Working system

ILCrawler

Docker-first technical SEO crawler for authorized audits, combining raw crawl data, rendered browser checks, Lighthouse audits, issue generation, CSV exports, and a private review UI.

Stack

FastAPI, PostgreSQL, MinIO/S3-compatible storage, Docker Compose, raw HTTP crawler, Playwright rendered audits, local Lighthouse audits, worker processes, bearer-token API auth, CSV exports.

What it does

runs raw HTTP crawls with robots.txt, sitemap discovery, URL normalization, and crawl limits
captures metadata, canonicals, headings, robots directives, hreflang, depth, word count, TTFB, and link graphs
records internal and external links for review and export
generates issue rows for duplicate metadata/content, broken links, orphan/dead-end pages, canonical problems, redirects, and hreflang issues
runs Playwright rendered audits and local Lighthouse checks
exports pages, issues, internal links, and external links as CSV
shows crawl status, issue summaries, pages, links, rendered audits, and Lighthouse output in a private dashboard

Scoped for owned and client-authorized audits.

FastAPI PostgreSQL Docker Compose MinIO S3 Playwright Lighthouse Technical SEO Crawler Worker Queue CSV Exports API Auth Runbooks

Run summary

Audit output

operator UI

Pages crawled

500

Links found

72,340

Issue rows

12,434

Duplicate metadata review

Canonical mismatch fix

Lighthouse audit completed

UI screenshots

ILCrawler in use

Private UI excerpts from a completed crawl run. Tokens and sensitive identifiers are removed.

ILCrawler project configuration showing crawl limits, allowed host, robots and sitemap settings. — Project setup: allowed host, robots/sitemap settings, crawl limits, render policy, and Lighthouse sampling.

ILCrawler completed run overview showing 500 pages crawled, 72340 links, and 12434 issue rows. — Completed run: 500 pages crawled, 72,340 links found, 12,434 issue rows, no crawl errors.

ILCrawler Lighthouse audit output showing mobile and desktop performance metrics. — Lighthouse output: mobile and desktop scores, lab metrics, and audit completion attached to the crawl run.

Working system

ReachLog

Single-owner outreach system for tracking targets, messages, replies, bounces, forms, follow-ups, and dedupe protection.

Stack

Next.js App Router, TypeScript, React, Tailwind CSS, Drizzle ORM, SQLite, Node worker scripts, Proton Bridge-compatible IMAP/SMTP.

What it does

stores outreach targets, contacts, source, status, and dedupe keys
imports canonical CSV outreach data with dedupe preview
tracks emails, forms, replies, bounces, skips, and follow-up state
syncs mailbox activity through worker scripts
links inbound replies to existing threads where possible
surfaces replies needing action and follow-ups due
exports targets, messages, events, forms, and follow-ups
keeps outreach execution tied to visible next actions

Built to keep high-volume outreach auditable, searchable, and hard to duplicate.

Next.js TypeScript React Tailwind Drizzle ORM SQLite IMAP SMTP Node Workers Deduplication Follow-ups CSV Import Exports Private Ops Tool

Workflow summary

Reply and follow-up control

ops UI

Reply triage

Action queue

Follow-ups

Due / overdue / upcoming

Dedupe

Import and send guard

Reply needs action today

Follow-up due open

Dedupe key hit skip

UI screenshots

ReachLog in use

Private UI excerpts from the outreach workflow. Names, emails, and mailbox data are masked where needed.

ReachLog dashboard showing replies needing action, follow-up state, sent no-reply count, and recent mailbox activity. — Dashboard: reply triage, follow-up state, sent/no-reply count, and recent mailbox activity.

ReachLog import screen showing canonical CSV intake and dedupe preview. — Import/dedupe: canonical CSV intake before records are created or updated.

ReachLog target detail view showing contact fields, timeline, thread, notes, and follow-up state. — Target record: contact, timeline, thread, form events, notes, and next action in one place.

AI-assisted engineering

How I use AI in build work

I use Codex and other LLM tools for scaffolding, refactoring, implementation planning, debugging, documentation drafts, and test expansion.

The model does not own the architecture. Data model choices, security boundaries, production changes, debugging, verification, and final review stay with me.

The benefit is cycle time: faster iteration, more complete documentation, and more implementation options without handing judgment to the tool.

Codex-assisted LLM-assisted development Human-reviewed code Private operator tooling Operator prototypes

Implementation excerpts

Selected code from the crawler and outreach systems.

Each excerpt shows an operational constraint: concurrency, dedupe protection, or portable export.

Worker lease / job execution

python

stmt = (
    select(CrawlQueue)
    .where(CrawlQueue.state == "queued")
    .where(or_(CrawlQueue.available_at.is_(None), CrawlQueue.available_at <= now))
    .order_by(CrawlQueue.priority.desc(), CrawlQueue.id.asc())
    .limit(limit)
    .with_for_update(of=CrawlQueue, skip_locked=True)
)

for item in session.scalars(stmt):
    item.state = "leased"
    item.lease_owner = lease_owner
    item.leased_at = leased_at
    item.attempts += 1

Purpose: Lease queued URLs across concurrent crawl workers.
Guardrail: Avoids duplicate work and stalled jobs when several workers run at once.
Tradeoff: Uses PostgreSQL row locking instead of a separate queue service; simpler stack, tighter database coupling.

Dedupe schema / unique-index logic

typescript

export const targets = sqliteTable(
  "targets",
  {
    id: text("id").primaryKey(),
    dedupeKey: text("dedupe_key").notNull(),
    doNotResend: integer("do_not_resend", { mode: "boolean" }).notNull(),
  },
  (table) => ({
    dedupeKeyUnique: uniqueIndex("targets_dedupe_key_unique").on(table.dedupeKey),
  })
);

Purpose: Resolve each target to one canonical dedupe key.
Guardrail: Stops duplicate imports and sends when the same company appears through email, form, or CSV.
Tradeoff: Requires normalization before insert; the database becomes the final protection layer.

Crawl-run status / export endpoint

python

ISSUE_EXPORT_FIELDS = [
    "url",
    "issue_type",
    "severity",
    "confidence",
    "message",
]


@router.get("/{crawl_run_id}/status", response_model=CrawlRunStatusResponse)
def get_crawl_run_status_endpoint(crawl_run_id, session=Depends(get_db_session)):
    crawl_run = get_crawl_run_or_404(session, crawl_run_id)
    return CrawlRunStatusResponse(**crawl_run_status_payload(session, crawl_run))


@router.get("/{crawl_run_id}/exports/issues.csv")
def export_crawl_run_issues_csv_endpoint(crawl_run_id, session=Depends(get_db_session)):
    get_crawl_run_or_404(session, crawl_run_id)

    return _stream_csv_response(
        ISSUE_EXPORT_FIELDS,
        f"crawl-run-{crawl_run_id}-issues.csv",
        lambda export_session, limit, offset: list_issues_for_crawl(
            export_session,
            crawl_run_id,
            limit=limit,
            offset=offset,
        ),
    )

Purpose: Expose crawl status and stream issue evidence as CSV.
Guardrail: Keeps audit findings portable outside the dashboard for review and handoff.
Tradeoff: Streaming controls memory use; pagination and ordering have to remain stable for repeatable output.

Selected labs

Working prototypes and internal systems kept separate from the main tools.

These are working builds kept separate from the two main systems. They show implementation range: programmatic SEO, data ingestion, automation, LLM-assisted triage, GPU orchestration, and controlled performance testing.

Discuss a system

Laravel FastAPI Python SQLite PostgreSQL Docker Prefect RunPod LLM triage Programmatic SEO JSON-LD Sitemaps Worker queues IMAP Crawler handoff Telegram GPU orchestration Object storage

InHomeDayCareMap

Programmatic SEO directory for licensed in-home daycare providers.

Built with Laravel 12, Tailwind, Leaflet, Filament, generated sitemaps, JSON-LD, live search, provider facets, import jobs, and approximate-location handling.

Laravel 12 PHP 8.4 Tailwind CSS Vite Filament Leaflet MarkerCluster Protomaps Spatie Sitemap Spatie Schema.org Laravel Vapor Queue jobs JSON-LD Sitemaps Programmatic SEO

Question tested: Can a directory be structured so search engines and users can move cleanly from state pages to city pages to filtered provider pages?
Result: Built crawlable state, city, facet, and provider pages with live search, maps, provider detail pages, JSON-LD, sitemap generation, and import normalization.
Guardrail: Provider locations are approximate and the app avoids implying that availability, licensing status, or safety records are guaranteed current.
Next iteration: Improve import confidence, add richer admin resources, strengthen tests around facets/search/sitemaps, and expand provider freshness checks.

Marketplace Triage Worker

Python worker for filtering marketplace leads before manual review.

Built with SQLite queues, JSONL ingestion, deterministic hard filters, LLM triage, read-only IMAP intake, crawler handoff, CLI commands, and Telegram notification boundaries.

Python SQLite JSONL ingestion CLI worker IMAP Crawler handoff LLM triage Telegram notifications Ruleset prompts Queue states Audit trail

Question tested: Can marketplace opportunities be filtered before manual review?
Result: Built an intake pipeline with normalization, duplicate checks, hard filters, LLM triage, queue states, audit records, mail-link extraction, crawler handoff, and Telegram notification boundaries.
Guardrail: Hard filters run before LLM evaluation so duplicates, bad parses, low-value budgets, blocked locations, and vague spam do not reach the review queue.
Next iteration: Add a small review UI, stronger replay tooling, and better feedback loops from accepted/rejected leads.

GPU Orchestration Lab

Dockerized multi-stage GPU pipeline with Prefect and on-demand worker pools.

Built with Prefect, RunPod, Docker worker images, PostgreSQL, S3-compatible storage, FAISS, vLLM, FastAPI workers, Stable Diffusion, NLLB, and autoscaling logic.

Docker Prefect RunPod PostgreSQL S3-compatible storage FAISS vLLM FastAPI workers Stable Diffusion NLLB CUDA GPU worker pools Autoscaling Object storage

Question tested: Can a controller stay small while GPU-heavy stages run in specialized worker images?
Result: Built a Prefect-controlled pipeline with separate pools for embedding search, model serving, tagging, image generation, translation, asset generation, and autoscaled RunPod workers.
Guardrail: The controller owns orchestration and state; GPU-heavy work is isolated into worker images so each stage can use the right hardware profile.
Next iteration: Add formal migrations, strengthen test coverage, harden translation workflow checks, and separate demo fixtures from real workload configuration.

Core Web Vitals fixture lab

Controlled WordPress fixture for showing a performance failure path without exposing client data.

Before/after route pairs for script loading, image delivery, cache/CDN behavior, and PageSpeed evidence.

WordPress PageSpeed Cache/CDN behavior Script loading Image delivery

Question tested: Can matched slow/fixed routes make a bottleneck visible?
Result: Matched slow and fixed routes made the before/after bottleneck visible.
Guardrail: This is a controlled proof lab, not a standalone product or client case study.
Next iteration: Add a fixture generator and repeatable crawl/export script for every route pair.

Redacted Laravel systems

Larger Laravel builds in sensitive verticals, available as private proof when relevant.

I have also built larger Laravel systems that are not shown as full public case studies. The relevant technical proof: marketplace workflows, Filament operations panels, advertiser/user dashboards, payments, geodata, SEO route trees, search, media handling, queue workers, scheduled jobs, imports, moderation tooling, video processing, HLS playback, object storage, AI enrichment workers, and feed personalization.

Details are redacted publicly because the verticals and data are sensitive. I can discuss the architecture privately when the work is relevant.

Laravel Filament Livewire Inertia Vue Redis Horizon Scout Meilisearch S3/B2 Payments Queues Scheduler Media pipelines FFmpeg HLS RunPod AI enrichment Moderation tooling Geo SEO

Technical issue or small system?

Send the issue with enough context to verify it.

Send the URL, expected behavior, current behavior, and tools involved. I’ll confirm whether it fits a bounded implementation block.

View service lanes Send the issue