AI case studies

What we have built and run with AI

The systems behind the claims on this site. Each is real AI-driven work, from products in production to delivery tooling and enterprise operations, described by design: what we built and what it shows.

Client data, sources and environments are not shown, and the descriptions stay at the level of design.

The case studies as a connected set DevShop, the delivery method, sits at the center. Around it: AI products and automation at the top and right (informal system interface, Blucanto, email automation, mobile AI, local AI media pipeline); and operations and enterprise delivery on the left (AI compute control, cutover scheduler, AI managed DevOps, AI managed infrastructure management processes). Each node links to its case study. Informal system interface Blucanto Email automation Mobile AI Local AI media pipeline AI compute control Cutover scheduler AI managed DevOps AI managed infrastructure DevShop
DevShop, the method, at the center. AI products and automation at the top and right, operations and enterprise delivery to the left. Select a node to jump to its case study.

Method and tooling

How AI work is controlled and operated.

Delivery method · AI engineering

DevShop

The proprietary delivery system behind every AI engagement: AI coding agents follow an enforced, auditable process.

DevShop: six stages with three client approval points Six stages in order: scaffold, specify, plan, test first, build and review, release. The client approves at three points: after specify, after plan, and after build and review. A band lists the rules enforced by tooling, and four cards state what that gives you: traceable, tested, reviewable, reversible and auditable. 1 Scaffold Project, repository and restore point 2 Specify Numbered requirements 3 Plan Small tasks, each with a test 4 Test first A failing test comes first 5 Build + review Minimal code, independent review 6 Release Closes only when exit checks pass fails passes You approve You approve You approve Enforced by tooling, not trusted to prompts No code without afailing test first No “done” until thetests pass No force-push, norewritten history Independent reviewbefore merge Task list changedonly through the tool Traceable Every change ties to a task in an approved plan. Tested Tests are written before the code they check. Reviewable A reviewer separate from the builder checks changes before they merge. Reversible and auditable Restore points, and a written record of every step. Vibe coding is prompt, hope, ship. DevShop is specify, test, review, approve.

What we built

A toolchain of command-line tools, skills, agents and commands that takes every engagement through the same six stages, with three approval points that belong to the client. Work is tracked on a task board, tests are written before code, independent reviewers sign off, and every architectural decision is written down. The rules are enforced by tooling, not left to prompts.

What it shows

AI-assisted delivery can be controlled. The process leaves a record, so a client can see what was built, why, and who reviewed it. This is not vibe coding, and it is the method used on every AI engagement.

Beyond the six stages

Written decisions

Every architectural decision is kept as a numbered decision record, so the reasoning outlives the people who made it.

Scope under control

The task tool refuses to let scope quietly grow, and limits review rounds so a review that is not converging goes to a person instead of looping.

Overrides are recorded

Any override of a gate is recorded on the task, so exceptions are visible and can be audited.

Reviews that probe

Deep reviews use mutation probes: they alter the code on purpose to check that the tests notice. Independent reviewers have caught defects that passing tests missed.

Bounded unattended runs

Overnight runs stop on iteration and budget limits, and an optional second-vendor model gives an advisory second opinion on risky changes.

Cost you can see

Model usage is measured by activity, so the cost of coordination is visible. Routine tasks go to a local open-weight model while hard ones go to a frontier model.

Built with itself

DevShop is built with itself, and it proved its own process on its own build.

One method, many projects

The same machinery runs across a whole portfolio of projects, not a single showcase.

AI infrastructure operations

A control panel for AI compute

A control panel that shows, schedules and powers AI compute, and refuses unsafe actions by default.

Compute on demand: from queue to sleep Job to result: Job queue, then Scheduler, then Wake, then Run, then Sleep. Destructive actions always ask for confirmation first. Job to result Job queue Work waits here Scheduler Decides when to run Wake Machine powers on demand Run Job is dispatched Sleep Idle machine powers down Destructive actions always ask for confirmation first.

What we built

A web control panel that queues AI jobs onto owned compute, schedules when the machine runs, powers it on and off to save energy, and asks for confirmation before anything destructive.

What it shows

AI workloads on owned hardware can be operated like a service: scheduled, observable and safe by default, with the machine awake only when there is work to do.

AI products and automation

Systems that put models to work, in production and in design.

AI product · in production

Blucanto

An AI business-planning web product with live payments, built and run by us.

Blucanto: request path and release path Request path: Browser, then Web app, then AI pipeline, then Model providers; Release path: Checks, then Review, then Deploy, then Verify. Request path Browser Founder answers Web app Product and payments AI pipeline Report generation Model providers Spend controlled centrally Release path Checks Unit, AI output, end to end Review Separate reviewer signs off Deploy Automated, from the pipeline Verify Live check after release

What we built

A web product for first-time founders that turns structured answers into an AI-written business blueprint, with live payments. Every change passes automated checks, including automated evaluation of the AI output, and independent review, and model spend is controlled centrally.

What it shows

We can take an AI product from idea to production and run it, not only advise on one: product design, model integration, quality evaluation of AI output, payments and release practice in a single delivery.

LLM email automation · design only

Email organization automation

Unstructured email in, structured records out.

Email organization automation, step by step Design, step by step: Email in, then Classify, then Extract, then De-duplicate, then Record. Design, step by step Email in Unstructured Classify What kind of message Extract Structured fields De-duplicate Rules first, then model Record Spreadsheet, on a schedule

What we built

A scheduled pipeline that reads incoming email, classifies it, extracts structured records, removes duplicates with deterministic rules plus model arbitration, and writes the result to a spreadsheet. The model provider is a configuration choice, hosted or local. This page describes the design only.

What it shows

Email organization with LLMs can be made dependable: safeguards ensure a failed run cannot lose or mislabel mail, and the model is used where language understanding is needed while rules handle the rest.

Mobile AI apps

Native iPhone apps with vision AI

Two iPhone apps in which a vision model reads photos.

Mobile AI: photo to result Photo to result: Camera, then Thin service, then Vision model, then On device. Core features work offline; only photo analysis needs a network. Photo to result Camera Photo taken on the phone Thin service Our own edge Vision model Reads the image On device Log kept locally Core features work offline; only photo analysis needs a network.

What we built

A nutrition diary and a receipt-to-PDF expense tool, both local-first, with the model reached through a thin service of our own. The nutrition app has been through an external beta, with automated test suites behind both.

What it shows

AI features can be added to a native mobile app while keeping data on the device and the model behind a narrow edge.

AI that stays on premises

Local AI media production pipeline

AI that stays in the building, on owned hardware.

Local AI: private batch and media production pipeline Private batch: Recording, then Speech to text, then Language pass, then Notes; Media pipeline: Outline, then Storyboard, then Script, then Produce. No cloud AI service sits in the private batch path. Private batch Recording Audio in Speech to text Local models, owned hardware Language pass Local models enrich the text Notes Searchable output Media pipeline Outline Approved by a person Storyboard Approved by a person Script Approved by a person Produce Providers swap cloud or local No cloud AI service sits in the private batch path.
Steps marked with an outlined border are approved by a person before the next one starts.

What we built

A private transcription and enrichment batch that uses local open-weight models, with no cloud AI service in the inference path, and an AI media-production pipeline whose text-to-speech, avatar, image and script providers are swappable between cloud and local by configuration, with human approval gates before anything goes live.

What it shows

Where data must stay inside the organization, AI can run on owned hardware, with provider choice kept open and a person approving each stage.

Deterministic code around a model

Informal system interface tool (calendar)

The model is not the control loop.

Informal system interface (calendar): the model reads, code decides Deterministic around a model: Spreadsheet, then Parse, then Plan, then Calendar. Deterministic around a model Spreadsheet Source of truth Parse Model reads ambiguous text Plan Code decides every change Calendar Same result on every run

What we built

A scheduled tool that keeps a calendar in step with a spreadsheet. It began as a prompt-run stop-gap and was rebuilt as deterministic code: the model only reads ambiguous cell text, while code decides every change and repeated runs give the same result.

What it shows

Where a task can be made deterministic, we do that, and keep the model for the part that needs language understanding.

Enterprise delivery and operations

The delivery discipline that carries over from enterprise programs.

Spreadsheet-to-web port

Cutover scheduler, from spreadsheet to web

A spreadsheet-driven cutover schedule and its workflow automation, ported to a web-based task scheduler.

Cutover scheduler, spreadsheet to web Spreadsheet to web: Export, then Import, then Engine, then Notify, then Audit. Spreadsheet to web Export Imported as is Import Repeatable, keeps state Engine Rules from the original Notify Each message sent once Audit Every change recorded

What we built

A web-based task scheduler that replaces a spreadsheet-run cutover schedule and its automation. The original behavior is the specification, the existing spreadsheet exports are imported as they are, each notification goes out exactly once at the right time, and every change leaves an audit trail.

What it shows

We can take a fragile spreadsheet-and-macro process and port it to a tested, version-controlled web system while preserving how it behaves for the people who rely on it.

Production support · change control · recovery

AI Managed DevOps

Production support, change control, disaster recovery and decommissioning, written down as an enterprise would.

AI Managed DevOps: change to recovery Change to recovery: Change plan, then Approval, then Change, then Monitor, then Recover. Change to recovery Change plan Backup and rollback included Approval Before anything goes live Change Applied and logged Monitor Checks that work was done Recover Tested restores, safe retirement

What we built

Operational practice documented to enterprise standard: change plans with approval and rollback, tiered backups with tested restores, monitoring that checks work was actually done, root-caused problem records, and planned decommissioning of retired systems.

What it shows

The discipline behind the delivery work: the same change control, recovery and decommissioning an enterprise audit expects, applied to our own systems.

Migrations · security upgrades · audits

AI Managed Infrastructure Management Processes

Read-only evidence first, a gate and a rollback at each stage, and every finding turned into tracked work.

AI Managed Infrastructure Management Processes: evidence to record Evidence to record: Inventory, then Gate, then Change, then Verify, then Record. Evidence to record Inventory Read-only first Gate Approve each stage Change With a rollback Verify Proved after each step Record Findings become tracked work

What we built

Platform migrations, security upgrades and audits run as controlled programs: what is really there is established before anything moves, each stage has a gate and a rollback, results are verified after each change, and every audit finding becomes a tracked task.

What it shows

Change is made safely: we establish the facts first, prove each step worked, and leave a written record.

Have a process that could be improved or automated, or a system we could deliver for you?

Tell us the workflow that hurts or the system that has to ship. A short intro call is enough to know whether we can help.

Book a short intro call

Or write to jerome@mungapenconsulting.com