Selected work-sample projects

Projects that show how I turn messy business workflows into systems.

These are the fastest project surfaces for evaluating my current engineering signal: backend-owned AI workflows, backend foundations, integration boundaries, validation boundaries, Docker/CI release discipline, CI, docs, and recovery paths.

Open DriveDesk AI Operator route Open flagship backend evidence Open verification pack

Role signal map

What I show for remote Python/backend and integration teams

If you are evaluating me for Python/backend automation, internal tools, API/CRM integration, QA Automation Python, AI workflow automation, or reliability work, this is the shortest route from project name to engineering signal.

AI workflow / RAG ownership

Start with DriveDesk AI Operator and AI Ops Workflow Kit. They show backend-owned state, RAG quality checks, transcript analysis, approvals, CRM handoff, audit, retries, and operator-facing workflow design.

Backend automation and integration operations

Open OpsDesk Reviewer Replay first for fresh backend/API code proof, then DriveDesk Core for tenants, RBAC, audit/outbox, workers, workflow rules, adapters, OpenAPI, Docker, CI, and public-safe operations evidence.

First-job backend evidence

Open OpsDesk Reviewer Replay for the clean public code slice, then Autoschool Intake/Admin for the real-work workflow context: Telegram intake, backend validation, database record, admin queue, operator status workflow, and privacy boundary.

Docker/CI handoff and recovery support

Use DeployMate to inspect deployment control, release gates, health/log review, self-hosted runtime discipline, evidence bundles, runbooks, and fallback review paths.

Trust boundaries and desktop automation

Use MPlusForm to inspect validation boundaries, untrusted local files, approved snapshots, optional Python sync, Windows operations docs, and public verification.

Start conversation Open skill evidence map

Flagship review path

DriveDesk AI Operator / AI Sales & Support Workflow Platform

I build the backend-owned layer where documents, transcripts, call audio, CRM leads, and knowledge-base records become RAG-backed analysis, lead scoring, follow-up drafts, Telegram approvals, CRM actions, audit logs, retries, and runbooks.

FastAPI PostgreSQL / pgvector RAG Telegram approvals CRM adapters Backend-owned state

Ownership

  • State, audit, retries, idempotency, adapter contracts, and approval boundaries live in the backend.
  • n8n is used as orchestration, not as the source of truth.
  • AI tooling accelerates implementation while verification and shipped quality stay my responsibility.

Evidence

First-job business workflow evidence

Autoschool Intake/Admin work sample

This is the public-safe representation of the private driving-school workflow: a Telegram request becomes a validated backend record, appears in an admin queue, and moves through operator status changes. It does not expose real learner data, live admin screenshots, internal test names, tokens, logs, admin URLs, or private repository code.

Telegram intake Backend validation Database state Admin handoff Privacy boundary

Ownership

  • User input is normalized before it becomes business state.
  • Requests are reviewable through admin-visible records and statuses.
  • Public evidence uses synthetic values only, never real admin data.

Evidence

Backend foundation

DriveDesk Core - Operations & Integration Backend

I use DriveDesk Core to show the foundation behind real operations software: tenants, RBAC, audit/outbox, workers, workflow rules, adapters, OpenAPI, SDK output, Docker, tests, CI, docs, a public demo route, and a business-intake API handoff path.

FastAPI PostgreSQL RBAC Audit / outbox OpenAPI Public demo

Ownership

  • Public-safe backend workflow evidence for CRM/ERP-style operations workflows.
  • Integration and workflow behavior is documented through review routes, demos, and evidence files.
  • The goal is operable business software, not isolated scripts.

Evidence

Runtime AI evidence

AI Ops Workflow Kit - RAG, Transcript Analysis, Approval & CRM Handoff

I built this as the public runtime evidence for AI workflow automation: document intake, first-slice playbook, privacy redaction before RAG/approval/CRM handoff, deterministic RAG quality eval with citations, transcript analysis, scoring, approval queues, Telegram callback handling, outbox processing, CRM dry-run handoff, live PostgreSQL/pgvector state, restart persistence, smoke checks, and CI evidence.

RAG ingestion RAG eval 2/2 Privacy boundary Transcript analysis Approvals Outbox worker Postgres/pgvector Docker Live smoke

Ownership

  • Provider boundaries, RAG quality eval, live PostgreSQL/pgvector persistence, reviewer acceptance, live evidence, and public status are documented.
  • External CRM writes stay behind dry-run and approval boundaries until integration is intentionally enabled.
  • Evidence focuses on runtime behavior: API, worker state, callbacks, CI, and smoke checks.

Evidence

Docker/CI product evidence

DeployMate - Self-hosted Docker Deployment Control Panel

I use DeployMate to show Docker/CI handoff and platform discipline around self-hosted deployments: FastAPI, Next.js, PostgreSQL, SSH runtime tooling, health/log views, admin workflows, release gates, evidence bundles, review packet export, and public-review gate.

FastAPI Next.js PostgreSQL Docker Compose SSH runtime Release gates

Ownership

  • Deployment, runtime review, admin surfaces, release safety, evidence packets, review packet export, and operational docs.
  • Public review path stays available even when custom-domain or staging conditions change.
  • Recent CI, production-contract, and public-review gates prove the default branch is not just static documentation.

Evidence

Validation boundary evidence

MPlusForm - Validation Boundary / Desktop Automation Evidence

I use MPlusForm to show trust-model and desktop-automation work around untrusted local files, optional Python sync, server-approved snapshots, Windows operations scripts, Lua addon boundaries, and public verification.

Python Lua Windows ops Trust model Public verification

Ownership

  • Untrusted client-side data stays separate from server-approved public snapshots.
  • Optional desktop sync and Windows automation are documented as an operable handoff, not an undocumented local dependency.
  • Public verification checks syntax, required docs, and package boundaries before the repo is presented for review.

Evidence