How I turn messy business workflows into operating systems.
This is the narrative route behind the proof links: the problem, what I built or shaped, which evidence to inspect, and what each case proves about backend/platform ownership, AI automation, integrations, DevOps, and operational handoff.
Open DriveDesk proof 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.
Evidence: DriveDesk Core, public demo, DriveDesk Core review, and proof of work summary.
What it proves: I can turn a vague operational domain into explicit backend boundaries, reviewable contracts, runtime checks, docs, and a public demonstration path.
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 proof turns document intake, RAG retrieval, provider boundaries, transcript analysis, approvals, Telegram callback approval, and CRM handoff into a backend-owned workflow pattern.
Evidence: AI Ops Workflow Kit, reviewer snapshot, acceptance report, and skill evidence.
What it proves: I can use AI-assisted execution while keeping workflow state, 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 direction focused on making deployment and operations reviewable through repo-first proof, release gates, logs, docs, and recovery evidence.
Evidence: DeployMate, engineering proof snapshot, and remote services.
What it proves: 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 proves: 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.