How I turn messy business workflows into operating systems.
This is the narrative route behind the evidence links: the problem, what I built or shaped, which evidence to inspect, and what each case proves about Python/backend ownership, AI automation, integrations, QA/API verification, reliability, and operational handoff.
Open DriveDesk AI Operator route Start conversation Source markdown
DriveDesk / Autoschool54 Operations Platform Direction
Problem
A real business operation breaks when work is spread across chats, documents, schedules, payments, accounts, support questions, admin routines, and fragile deployment or recovery paths.
Build
I use the Autoschool54 operational context to shape DriveDesk: one operations layer for workflows, records, documents, integrations, notifications, AI assistance, deployment, observability, and recovery. The first-job-readable slice is the intake/admin workflow: Telegram request -> backend validation -> database record -> admin queue -> operator status update.
Evidence: Autoschool Intake/Admin work sample, DriveDesk Core, public demo, DriveDesk Core review, and evidence of work summary.
What it shows: I can turn a vague operational domain into explicit backend boundaries, reviewable contracts, runtime checks, docs, public-safe evidence, and a request-to-admin workflow that maps directly to first backend/integration work.
AI Ops Workflow Kit
Problem
AI automation cannot be only a chat wrapper. Documents and transcripts need repeatable retrieval, summaries must be reviewable, and risky outputs need approval state instead of blind automation.
Build
The public evidence turns document intake, privacy redaction, RAG retrieval with quality eval, provider boundaries, transcript analysis, approvals, Telegram callback approval, and CRM handoff into a backend-owned workflow pattern.
Evidence: AI Ops Workflow Kit, reviewer snapshot, privacy boundary, acceptance report, and skill evidence.
What it shows: I can use an AI-assisted engineering workflow while keeping workflow state, RAG quality checks, privacy boundaries, approval boundaries, tests, and integration surfaces explicit.
DeployMate
Problem
Self-hosted systems need deployment paths, target servers, logs, health checks, environment handling, CI/CD, and recovery thinking. Otherwise the product feels fragile even when features exist.
Build
DeployMate is a self-hosted deployment control panel evidence surface focused on making deployment and operations reviewable through repo-first work sample, release gates, logs, docs, and recovery evidence.
Evidence: DeployMate, engineering evidence snapshot, and remote services.
What it shows: I understand the operational side of shipping: deployability, observability, release discipline, health checks, runbooks, and recovery paths matter as much as feature code.
MPlusForm
Problem
Desktop and client-side data is not automatically trustworthy. Local files, addons, sync helpers, and Windows automation need a clear boundary between untrusted evidence and approved state.
Build
MPlusForm is an addon and sync-pipeline proof around validation boundaries, server-side trust checks, approved public snapshots, operation scripts, and handoff docs.
Evidence: MPlusForm, reviewer snapshot, and skill evidence.
What it shows: I can design validation boundaries around untrusted data and document a workflow so another operator can inspect and run it.
The operating loop
- Start from a messy real workflow.
- Identify the risky assumptions and integration boundaries.
- Build the smallest responsible working slice.
- Verify with tests, CI, logs, smoke checks, demos, docs, or runbooks.
- Leave enough evidence that another reviewer can inspect the work.