iksmgtConsulting DEEN Request a project
Project index

All projects

Real projects from own development and client work — anonymized: no names, no domains, just technology, structure and tooling.

P-01

Directory platform with a data pipeline from official registries — own product, live

Django · PostgreSQL · HTMX · SEO
DATA PIPELINE REGISTRIES HTML · SCRAPER REGISTRIES PDF · PARSER TAXONOMY CATEGORIES PIPELINE RAW · STAGING · PROD SEO PAGES CATEGORY × PLACE OPS BACKEND n8n · REQUESTS PROFILE PAGES ~870 ENTRIES IDEMPOTENT · APPROVAL GATES OFFICIAL SOURCES — ONE INDEX
Fig. 1 — Schematic view
Problem
The official registry data of a regulated profession is scattered across dozens of registry bodies — HTML lists and PDF registers, with no central search.
Architecture
Server-rendered Django with HTMX and Tailwind on PostgreSQL. Idempotent scrapers load the registries (HTML and PDF) into a three-stage pipeline — raw, staging, production — with manual approval gates between stages. SEO landing pages per category, location and combination; redirect middleware (301/410) keeps the URL structure clean; contact requests flow via n8n into an ops backend.
Result
A live directory with around 870 profiles from official sources; the index grows in a controlled way, registry by registry.
P-02

Guide portal with postcode-radius search — own product, under construction

Django · PostGIS · HTMX
PORTAL ARCHITECTURE SCRAPERS SOURCE TRACKING GUIDE CMS MARKDOWN KEYWORD DATA PRIORITIZATION DJANGO POSTGIS · HTMX SEO RULES · GATES RADIUS SEARCH POSTCODE REGIONAL PAGES QUALITY GATES QUALITY GATE FIRST, THEN LIVE
Fig. 2 — Schematic view
Problem
A trade-adjacent market is highly fragmented; prospects research a lot but struggle to find providers near them.
Architecture
Django with PostGIS for radius search — HTMX partials instead of a single-page app. A data pipeline with lightweight scrapers and per-record source tracking, a Markdown CMS for guide content, and an information architecture derived strictly from keyword data: fixed indexing rules and quality gates before a page goes live at all.
Result
Data model, first data source (≈1,300 records), radius search and regional pages are in place; expansion follows keyword priority, not gut feeling.
P-03

Agent workflow: from photo to marketplace listing — internal tool

LLM · Vision · APIs
AGENT WORKFLOW — WITH APPROVAL GATE INPUT PHOTOS + NOTE AGENT WORKFLOW VISION LLM READS THE PHOTOS SCHEMA ATTRIBUTES MARKETPLACE API · LIVE PHOTOS DRAFT IMAGES MATCHING FETCH PUBLISHED ONLY AFTER APPROVAL
Fig. 3 — Schematic view
Problem
Creating a listing on a major online marketplace takes many manual steps: prepare photos, research category and required attributes, write copy, publish.
Architecture
Agent-driven workflow: script-based image prep (background removal, normalizing), a vision model reads the photos and grounds the listing copy in what is actually visible, category and attribute schemas come live from the marketplace API — nothing is published without explicit approval.
Result
Photos plus a short note become a reviewable listing draft; only approved content gets published — no invented product claims.
P-04

Multi-agent pipeline for market research — own product

Python · LLM agents · Scheduling
RESEARCH PIPELINE FILINGS MANDATORY REPORTS TRANSACTIONS INSIDER MARKET SCREENS PRICE · VOLUME SCAN + FILTER ENRICHMENT TWICE A WEEK ADVERSARIAL REVIEW AGENT THESIS AGENT COUNTER-THESIS AGENT RISK REPORT 3–5 IDEAS HUNDREDS OF CANDIDATES → 3–5 IDEAS
Fig. 4 — Schematic view
Problem
Public capital-market signals — mandatory filings, insider transactions, screens — are too numerous to review manually; and single LLM answers are too uncritical to be trusted.
Architecture
A pipeline running twice a week: scan of multiple data sources, enrichment and rule-based filtering, then adversarial review by several agents arguing opposing positions. The output is a report with thesis, catalyst and invalidation level per idea, rendered as a static report site.
Result
3–5 vetted ideas per run instead of hundreds of raw hits; every idea documents what would prove it wrong.
P-05

Catalog & marketing site for an equipment manufacturer — client project

Django · Docker · CI
CATALOG SITE OPERATOR ADMIN EDITING PRODUCTION HOST DJANGO SITE CATALOG · SSR ADMIN + FEED VIA ENV FLAG ONLY VISITORS CATALOG PAGES CI PIPELINE DOCKER IMAGE DEPLOY UPDATES WITHOUT A DEVELOPER
Fig. 5 — Schematic view
Problem
A manufacturer of technical equipment needed a low-maintenance catalog and marketing site — without a heavyweight CMS and without ongoing agency costs.
Architecture
Server-rendered Django with a product catalog; the operator maintains content in the admin. Docker image built in CI, deployed by script to the production host; admin and JSON feed are only active via environment flags.
Result
Lean operation with a minimal attack surface; content updates need no developer.