Full-stack engineer and creative practitioner. I build the production
systems that automate the Adobe stack.
I am the glue between the C-suite, the people doing the work and the
engineers who build it — an engineer myself, and a marketing officer who has run the
sales meetings. Architect and bridge builder: I can hold all three of those conversations
in the same room, which is usually what decides whether a system gets adopted.
Right now I run my orchestration on Hermes Kanban, a layer I
wrote myself instead of reaching for n8n or ComfyUI. For anything that has to stay on
site I run Qwen 3.8 on local hardware, and on my own workloads it is beating
Gemini 3.1. Day to day, Fable 5 and Kimi K3 do most of the heavy lifting.
Self-assessed, 1–10, master at the top. The second row is the rest of what I reach for — listed at what it honestly is, including where it is thin.
Engineering
Production systems in front of real users, not prototypes. Python, TypeScript,
Next.js/Astro, Azure and Cloudflare Workers. ~25 shipped products, several with
live public URLs below.
Craft
Not familiarity — practice. After Effects, Premiere, Photoshop, Illustrator,
and enough of the render chain to script it end to end. Former Flash/ActionScript
developer.
In the room
I run the sessions myself — whole departments at a time, in person and over
Zoom, as the speaker. Discovery, architecture, deployment and training are one
engagement, not four vendors.
How the engagements run
1 · I am the speaker (with 4 ears)
Discover
I host the session and do the asking — entire departments, sometimes
several at once, in person or over Zoom. The questions are about their actual day: what
recurs, what they dread, where the hours disappear.
2 · Design
Architect
Those answers become agentic flows, designed against the tools the team
already has rather than a stack they would have to adopt.
3 · Build
Deploy
I build and ship them. Running systems in front of real users, not a deck of
recommendations handed to somebody else to implement.
4 · Adoption
Enable
Then I train the department on what was built, and on the custom systems
already deployed for them. The measure is whether people are still using it the week after
I leave.
The seam is the whole point. Plenty of people
can build an agentic pipeline; plenty of others can stand in front of a marketing department.
The engagements that stick need the same person to do both — because the flow you design
is only as good as your understanding of the job it replaces, and that understanding comes from
being the one asking the questions.
Hardware
Physical systems — the boxes, the networks and the appliances that
make an agentic flow possible inside somebody else's building.
On-premise inference for regulated clients
Hardware, networking and compliance design
HIPAA and FedRAMP environments · ongoing practice
Some clients cannot send their data to a hosted model. Under HIPAA or FedRAMP
the agentic flow has to run inside their own boundary, which turns an AI project into a
hardware, networking and audit problem before it is a software one. I do that whole side:
specify and build the GPU inference hardware, design the network around it, and run the cloud
HIPAA and FedRAMP compliance auditing and architecture for the parts that do stay in
the cloud.
Actual build A 6× GPU on-site server on
the bench, running a thermal soak before it ships. The Lenovo P8 compute nodes hold the
dual Intel Arc Pro B70s you can see loaded in the fleet manager below —
same machine, same cards, two views
Delivered as a unit, not a parts list
The client's compliance boundary is a rack in their building — firewall,
switching, GPU compute and storage specified, built and burned in together
Thermals are the failure mode nobody catches on paper. Sustained inference
load is not a spec-sheet workload, so every build gets soaked here before it leaves
It arrives commissioned. Nobody on the client's side has to assemble an AI
appliance out of purchase orders
Live rack telemetry — 487 W at the wall, and what that costs hourly
through yearly, with the solar array and battery bank sized to carry it
Fleet view — four GPUs across three machines, local and over the LAN,
with per-card model loading, VRAM, thermals, clocks and power
Deployed and operational
Try this actual hardware, live right now
Nothing leaves the building, so it sits inside most HIPAA and FedRAMP
boundaries — and inside media and production environments where unreleased
assets are not allowed near a hosted model.
Type a prompt and watch the lead model orchestrate across other models on physical
GPUs, splitting the work for maximum efficiency. On these workloads it outperforms a
Blackwell box at a fraction of the operating cost — which is the whole
argument for putting inference in the building.
HIPAA & FedRAMP boundariesMedia & production safeDual Intel Arc Pro B70Open-source modelsZero cloud egress
Read it as instrumentation
This is an operator tool, not a client-facing product — the console I
use to run a client's system: model placement across cards, thermals, power draw,
orchestration state. Built for whoever maintains the rack, not for the marketing team,
who never see it.
The build
Low-cost, low-wattage GPU inference on Intel hardware — or Apple silicon
— rather than a rack of datacentre accelerators the client cannot power or cool
Running Qwen3.8 at 50–100 tokens/sec, which is hosted-frontier-model speed
for the orchestration and execution workloads these flows actually do
Speed stopped being the interesting number a while ago. On my own workloads that
local Qwen 3.8 is now outrunning Gemini 3.1 — which is what makes the
compliance answer viable rather than a sacrifice the client has to accept
Custom management dashboard driving the on-site rack directly: model loading and
placement across GPUs, thermal and utilization telemetry, and live power draw
The photo above and the fleet view below are the same build — a Lenovo P8
with dual Intel Arc Pro B70s, both cards holding a 27B model at 4-bit
Because power is the real objection, the dashboard also costs it — electrical
spend hourly through yearly, and the solar array and battery capacity that would carry
the load overnight
Why clients need it
The compliance answer to “where does our data go” is a room, not a
paragraph in a vendor's terms
Once inference is in-house, the cost model inverts — capital and watts instead
of per-token billing, which is why the energy maths sits on the same screen as the
throughput
Same discipline as the audit work: I have done the cloud-side HIPAA and FedRAMP
design too, so the boundary is drawn deliberately rather than by accident
HIPAAFedRAMPGPU inference hardwareNetwork designIntel Arc / Apple siliconllama.cppQwen3.8Power & solar modelling
In production
Relevant well beyond the regulated clients: every enterprise creative team eventually asks
where their content goes when it hits a model. I can answer that from having built the
alternative, not from having read the datasheet.
USB-stick product photography pipeline
Built for an e-commerce company
Physical trigger → automated cutout, dust removal, lighting correction → a link back
A product photographer plugs a USB stick into a Raspberry Pi sitting on the desk. That is the
entire user interface. The pipeline ingests every image on the stick, cuts out the product,
removes dust and sensor spots, corrects lighting, and emails back a single link to the finished
set. No login, no upload dialog, no training session, no new tab.
Engineering
Raspberry Pi as an ingestion appliance — mount detection triggers the run, so the
physical act of plugging in is the submit button
Batch orchestration with per-image retry, and a delivery link generated on completion
Model-agnostic generation layer — built against the Gemini API ("nano banana"),
and the call site is one adapter
Why it worked
The team had already rejected two web tools. The blocker was never capability —
it was that a photographer mid-shoot will not stop to use a web app
Removing the interface entirely was the adoption strategy, not a shortcut
Consistent output beats best-case output: every image gets the same treatment, so the
catalogue looks like one catalogue
Raspberry PiBatch orchestrationGemini API (nano banana)Firefly-swappable
In useOn the model choice: this shipped against Gemini, and it would run on Firefly today with
no architectural change — Firefly now serves that same model family as a partner model,
selectable alongside Adobe’s own. The orchestration, the trigger and the delivery are the
engineering; the generator is a line in an adapter. Saying otherwise would be dressing it up.
Software
Everything that runs on top — production pipelines, client platforms
and the systems that put generated content in front of real users.
How Firefly gets into a marketing department — custom models, driven by agents
Trained on the client's own product photography · run as a work queue · current work
A marketing team will not adopt a tool that requires somebody to sit in Firefly all day. So the
generation stays in Adobe, where the brand already has a license and a login — and everything
around it is automated. I train a Firefly custom model on the client's own product
photography, then my own harness, Hermes, runs it: work arrives as cards, an agent picks one
up, drives the custom model, and the finished assets come back on the card.
The Adobe side — a trained custom model (Industrial PCs candidate)
generating from a reference image, with the concept token CUSTOMSUBJECT carrying the
client's product through every prompt
The automation side — agents holding two live Firefly jobs: generating
product imagery against the custom model, and preparing the next training dataset. Nobody is
clicking Generate
The method
Open-weight models do the thinking, Firefly does the picture. Orchestration,
prompt construction and dataset prep run on local hardware; the licensed generative call is
spent only on the thing it is uniquely good at
A subject custom model per product family, so the client's actual hardware —
not a generic stand-in — is what appears in every scene
The concept token goes in every caption and every prompt, which is what keeps identity
stable across a whole catalogue rather than per-image luck
Training-set preparation is itself an agent task. Assembling, cropping and
captioning the next reference set is a card on the board, not an afternoon of somebody's week
Cards carry the job URL and the model id, so a run is reproducible and auditable after
the fact rather than living in one person's browser history
Why it lands with a marketing team
Nobody has to become a Firefly operator. The department asks for assets; the assets
arrive
It runs inside the tool the business already pays for, so it survives after I leave
— the license and the logins are already theirs
Volume stops being a headcount question. A new product family is a new custom model and
a new card, not a new shoot
The same board is where the work is reviewed, so the humans stay in the loop at the only
point where their judgement actually matters
In build
Running now against a live manufacturer catalogue. This is the part I would bring to an Adobe
engagement first: the hard problem is never the generation, it is getting generation to happen
without a person driving it — and doing that without moving the customer off Adobe.
Current work — Firefly as the product photography pipeline
Edge AI and rugged computing catalogue · in build · current contract
Purpose-built edge AI systems for machine vision, robotics and physical AI — NVIDIA
Jetson, Intel Core Ultra, IP66-rated rugged platforms that put inference where the data is
created. A deep SKU catalogue where every unit has to be photographed identically, and none
of them are pretty out of the box.
Firefly does the product library. Every unit is upscaled and cut out of its original
shot, then presented on a consistent surface across the whole catalogue — so a page of
five edge computers reads as one product family rather than five different photographers'
work on five different days.
Category hero — the unit cut out of its original plate and placed
on a generated gradient surface
Product grid — five SKUs, one consistent cutout treatment across
the catalogue
JCO-6000-ORN
— upscaled cutout on a generated circuit-trace environment
“Look closer” — the same unit at full resolution, which is
what the upscale step is for
Engineering
Ingested their entire existing image library off their live site, then ran
batch background removal and upscale through Firefly and handed the cleaned set back to
the web design agent that builds the pages
That is the whole point: the asset pipeline and the site generator are one system,
so a catalogue migration is a batch job rather than a design project
Google Veo for video generation alongside the Firefly stills
Astro, deployed to Cloudflare Workers via Wrangler — static-fast at the edge,
which matters when the pages are this image-heavy
Third manufacturer on the same platform pattern — the reusable half is the
point, not the individual site
Creative & roadmap
Cutout treatment, shadow and surface direction that holds across a catalogue of
visually dissimilar hardware
Next: extending into their marketing function for social content generation
Then: building generation directly into the publishing pipeline, so campaign
assets are produced as part of shipping a product page rather than as a separate
request to a design queue
In build
Current contract. The roadmap is the part I care about: generation moving from a
production step someone runs to a stage in the publishing pipeline —
which is the only version of this that survives contact with a marketing team's actual
workload.
Medical, industrial and rugged computers · live · build, then enablement
Purpose-built computers for the places ordinary hardware does not survive — medical
panel PCs certified to UL 60601-1, IP69K washdown industrial units, rugged edge systems. Every
SKU needs to be seen in the environment it was built for, and photographing that is not viable:
three shoots per unit, in facilities you cannot get a camera crew into. So each product is shot
once, clean, and Firefly removes the background and generates the deployment scene.
Split-environment hero — two products composited into generated
industrial and clinical scenes
NVIDIA edge AI
— on-premise inference on the factory floor. 0 bytes sent to the cloud
Guides — every editorial
illustration generated: an operating theatre, a washdown line, a rugged test lab, an IP-rating
diagram, a fanless cooling cutaway. Firefly first, with nano banana where it fits
What I built
Full commercial storefront on Astro / Cloudflare Workers — catalogue, product
detail, configurator, quote flow
Firefly background removal and scene generation wired into the asset pipeline rather
than run by hand per image
Art direction of every generated environment: lighting, perspective, scale and
reflection have to match the product plate or a clinician spots it instantly
Firefly is the default because the client already pays for Adobe. A tool the
marketing team already has a license and a login for is a tool they can keep using after
I leave — that argument closes faster than any quality comparison
What I sold them next
Agentic training for their marketing and sales departments — a paid
engagement teaching staff to hand their everyday tasks to agents
Training on the custom systems I had already deployed for them, so the tools stopped
depending on me being available
The build created the credibility; the enablement is what made it stick
Adobe FireflyBackground removalGenerative scene replacementAstroCloudflare WorkersEnablement / training deliveryUL 60601-1 / IP69K domain
Live, and expanded
Shipped, in market — and then the engagement grew into training. That is the part
I care about: I did not just deliver a system and leave, I sold and ran the enablement that
got a marketing and sales team using agents on their own work. A tool nobody is taught to use
is a tool that quietly stops being used.
Point-of-care medical computing · in build · current contract
The same platform pattern, second manufacturer — and the clearest healthcare case.
The CyberMed G24 is a fanless, antimicrobial, UL 60601-1 certified all-in-one for active
hospital wards: sealed bezel so clinicians can clean it with aggressive sanitizing sprays,
dielectric isolation on every port. The page has to put that unit in a ward, and the
ward is generated.
CyberMed G24 — product detail and live configurator; the hero places
the unit in a generated hospital ward
Edge AI
— “AI that never leaves the building.” Dual RTX PRO 6000, 120B-class models,
zero cloud egress
Engineering
Catalogue, product detail and live configurator (OS, RAM, storage) with a quote flow
One design system serving a second brand, so a new manufacturer is a configuration
rather than a rebuild
Specification data modelled so a SKU's certifications and I/O drive the page instead
of being retyped into it
Creative
A believability bar higher than consumer marketing — a clinician recognises a
wrong ward instantly, and a wrong scene costs the sale
Brand system distinct from Teguar's while sharing the same underlying structure
Video, and where the human goes back in
Stills are only half
of it. For motion I pick the model inside Firefly and generate there, work the frame with
Firefly's own edit tools, then take the clip into Adobe Express to cut it. The last pass is
a person, every time.
Firefly — choosing the model, then working the generated frame. Upscale
at 2× to 2048×1610, alongside Fill, Remove, and Crop and expand. Note the credit
bottom right: powered by Photoshop
Adobe Express — the generated clip on a timeline at 1280×720,
sliced to 8.6 seconds. This is where a person cuts around the frames where the model got the
hardware subtly wrong
Human in the middle
Generated video has artifacts — a bezel that bends, a port that migrates, a logo that
dissolves for four frames. Somebody has to see that and cut it. That is the honest version of
this work: the agents do not do all of it. They do the heavy lifting and hand off. Which is
exactly why the engagement does not end at deployment — the value is in teaching a
marketing team what to look for, and where their judgement still decides the output. A team that
cannot spot the artifact ships it.
Adobe FireflyFirefly video generationAdobe ExpressGenerative scene replacementAstroCloudflare WorkersE-commerce / configuratorHuman-in-the-loop QCUL 60601-1 / point of care
In build
Current contract. The same client also runs the lead-intelligence hub below — the
website and the sales system are one engagement, not two.
Cybernet Lead Intelligence
GIS lead-enrichment hub wired into an Adobe ColdFusion CRM
Inbound lead → lookalike discovery → enriched contacts → sales strategy · current contract
A central intelligence hub for a manufacturer's marketing and sales function. An inbound
lead arrives from the website; the system finds lookalike companies, sources and enriches
contacts, scores buying potential, plots the whole target set on a GIS map, and drafts the
actual approach — contact strategy, email sequence, call script — per account.
The part I am proudest of is the least glamorous. This did not replace anything.
It was integrated into the company's existing Adobe ColdFusion custom CRM over REST
endpoints and webhooks, so an enriched account appears inside the system the sales team
already uses, already trusts, and already has years of history in. Nobody had to adopt a
second tool.
315 target accounts across 12 verticals, scored and mapped. The contact
panel is cropped out of this shot on purpose — it holds real people's details
Engineering
Lead ingestion from the website, lookalike-company discovery, contact sourcing and
enrichment, buying-potential scoring across twelve verticals
Apify network integration for data a marketing department cannot otherwise
reach — the difference between a list and a pipeline
Two-way integration with the incumbent Adobe ColdFusion CRM via REST APIs and
webhooks, including de-duplication against records already in the CRM
GIS map interface over the full target set, with filtering by vertical, geography
and whether an account has been CRM-checked
In use
Live against a real pipeline. Worth noting the shape: the interesting engineering was not the
AI — it was making the AI arrive inside a legacy Adobe system the business had
already standardized on, which is the difference between a tool that gets demoed and one
that gets used.
Flagship — Chirps: an almost 100% Adobe render pipeline
Text → lipsynced avatar video, generated and scheduled automatically · started June 2024 · commissioned work
A platform that turns a written post into a hyper-realistic lipsynced video asset in a
distinctive on-screen format, then schedules it across social networks. The product is the
video. The engineering is the render pipeline behind it — and that pipeline is
Adobe applications driven as headless infrastructure by Python.
Built under commission for a venture capitalist selling technology into news media and
film studios. That shaped every decision in it: the output had to match a broadcast
on-screen treatment rather than a social-native one, and it had to come out the far end at a
volume and consistency a newsroom would accept — which is why the render chain is
Adobe applications on rails instead of a person in an editor.
chirps-navy.vercel.app — the on-screen format the pipeline renders, and the avatar/copy treatment it populates per post
Ingest
User submits an image. Agentic routine removes the background, corrects
lighting, upscales.
Firefly
Matte
Video clip backgrounds stripped and replaced with a green screen so
downstream keying is deterministic.
Express
Composite
Layers, keying and the branded on-screen treatment assembled
programmatically.
After Effects
Assemble
Parts placed on a timeline in order and cut to length, per generated
script.
Premiere Pro
Encode
Final output rendered to delivery specs per destination
platform.
Media Encoder
Distribute
Scheduled publication to X, Rumble, Truth Social and
YouTube.
API
Orchestrated by Python. Every stage above except distribution is an Adobe
application or service being called as a build step.
How the delivery tier evolved
First
Python automation inside Adobe Express
Fastest path to a finished clip. Express did the matte and the assembly,
driven from Python, and it got the product working end to end.
Then
A server running Adobe Premiere
Moved off the desktop so renders were not tied to a workstation. Same
creative template, now on a machine that could take a queue.
Finally
Custom headless ffmpeg + Python
At per-clip volume the encode did not need a creative application at all.
The template still came out of After Effects; only the delivery tier changed.
That progression is the point, not a retreat from the stack. The
creative applications are where the treatment gets designed and where a human can still open
the file and change it. The encode tier is a commodity, and once volume made it the
bottleneck it belonged in a headless process — which is the same reasoning behind
Media Encoder watch folders and behind Firefly Services existing as an API at all.
Knowing which half of a pipeline is craft and which half is throughput is most of this
job.
Output of the Express stage, in my Adobe library — source clips
matted and replaced with a green screen so the After Effects template keys the same way
every time. Two frames here are keyed; two still show the original plate with the matte
edge drawn, which is the before/after of that step.
Engineering
Python orchestration driving After Effects, Premiere Pro and Media Encoder as
scriptable render workers
Agentic workflow triggered on user submission — no human touches an asset
between upload and published video
Web app for script authoring, avatar selection and scheduling
Delivery tier went through three generations — Python driving Adobe Express,
then a Premiere render server, then a headless ffmpeg + Python encoder as per-clip
volume grew
Originally served from Adobe ColdFusion; migrated to Astro on Cloudflare Workers
Creative
Designed the proprietary on-screen video format — a recognisable, high-impact
treatment styled after broadcast lower-thirds
Compositing and keying decisions built into the AE templates the pipeline populates
On holdWhat worked: lipsync quality is convincing, the pipeline runs unattended end to end,
and it was aimed at exactly the customer this kind of system has to survive — media
and entertainment, where volume and format discipline are the whole requirement.
What did not: 3–6 minutes per lipsync plus ~1 minute to render and deliver is
too slow for a scheduling product, and the UI was not good enough to ship. Parked pending a
faster lipsync approach rather than declared finished.
Note on this write-up. The original orchestration code is no longer in
my hands, so the architecture above is a retrospective description of a system I built and ran.
The render half is rebuilt clean-room as adobe-render-bridge — an
aerender wrapper, ExtendScript generation for After Effects / Premiere Pro /
Media Encoder, a Media Encoder watch-folder driver, and a dry-run mode so the whole pipeline
runs on a machine with no Adobe software installed. It is browsable below.
Browse the code
📁 adobe-render-bridge
MIT
Drive After Effects, Premiere Pro and Adobe Media Encoder from Python
as headless render workers. One JSON job spec goes in; a populated comp, a master render,
and every delivery encode come out.
GPU rasterization and color pipeline for wide-format print · my engine, shipping in a live product · in market
BendiRaster vs. Adobe PostScriptBendi wins 8 of 9
Where it is decided
Adobe PostScript — CPSI lineage, 1990s
BendiRaster
Execution model
Single-threaded interpreter loop on the CPU
✓Parallel rasterization on the GPU, WebGL 2.0
Color depth
8 bits per channel through the transform chain
✓Higher bit depth held all the way to the device
Working gamut
Clipped to device CMYK early in the pipeline
✓Wide working space; clip once, at the device
Dynamic range
SDR only — no concept of anything else
✓HDR information carried through to output
Preview
Rasterize, wait, then look at it
✓60fps pan and zoom on multi-gigabyte artwork
Input formats
PS, EPS, PDF
✓Those plus TIFF, PNG, AVIF, WebP
Device control
Generic spooler with a driver in the middle
✓Direct PJL and EWS to the printer
Deployment
One licensed workstation, often a hardware dongle
✓Any PC or iPad on the LAN, unlimited seats
Edge-case fidelity
✓Thirty years of accumulated PostScript edge cases, handled
Younger. This is the one I have to keep earning
Which Adobe engine, exactly: this is Adobe PostScript —
the CPSI-lineage interpreter that wide-format RIP software still ships today — not the
modern Adobe PDF Print Engine. Both are Adobe, and they are not the same architecture.
Naming which one is the difference between a comparison and a boast.
A RIP is where a designer's file stops being artwork and becomes ink on a substrate: color
transforms, ICC profiles, halftoning, rasterization, and the device controls that decide whether
the result matches the proof. BendiRaster is mine — an independent raster engine and
color pipeline I built from the ground up, matching what Adobe PostScript does and then going past
it on the axes above. BendiRip is the commercial product it ships inside, and it is live
and in market, so the engine can be judged on running software rather than on my description of
it.
BendiRip Studio driving an HP Latex 570 — job queue and cost per square
foot, ICC profile and substrate/cure controls, live printer, ink and hardware telemetry
The engineering
An independent raster engine. I characterized how Adobe PostScript and the
RIPs built on it transform color on the way to the device, then built a pipeline that
matches FlexiPRINT-accurate ICC output on its own terms — and beats it on gamut,
depth and speed
Rasterization on the GPU. Adobe PostScript was architected in the era of
single-threaded CPU interpretation and 8-bit output, and it is very good at what it was
built for. I built for the constraints that exist now: parallel raster, higher bit depth, a wider working gamut, and
enough headroom in the pixel format to carry HDR information to the device
WebGL 2.0 canvas holding 60fps pan and zoom on multi-gigabyte artwork, which is
the difference between a usable prepress tool and one operators fight
Direct PJL and EWS integration rather than a generic spooler — HP Latex
315 through 570 verified, with Epson SureColor S-series, Mimaki and HP Scitex flatbeds in
progress
The delivery
Go-to-market in two months, solo: raster engine, color pipeline, studio UI,
printer drivers, queue, telemetry and the shop-management layer around it
Mirrored the incumbent feature set first so a print shop could switch without
retraining, then upgraded the parts operators complain about — profile and heat
settings in one click instead of five levels of nested dialogs
Runs across the LAN from any PC or iPad rather than being locked to one licensed
workstation, which is what actually changes how a shop floor works
The same engine now carries a whole suite — cutter, laser and CNC toolpath
products built on the same foundation, which is the point of owning the layer underneath
rather than shipping one application
How it was built — agents at three levels
Two months solo is only
possible if the work is graded. I do not point one model at a problem and hope. I decide what tier
of thinking each layer actually needs, and route it there.
Level 1 · volume
Local open-weight models
Format parsers, driver scaffolding, test fixtures, the long tail of device profiles.
High volume, low judgement — running on my own GPUs at no per-token cost, which
is what makes exhaustive coverage affordable instead of a corner to cut.
Level 2 · analysis
Mid-tier models in a loop
Characterizing how the incumbent transforms color: generate output, measure the difference,
adjust, repeat. Empirical work rather than clever work — the value is in running
the loop thousands of times and holding every result, which is exactly what an agent is for.
Level 3 · architecture
Frontier models, and me
The color math, the shader design, and every decision about what the engine is.
This tier does not get delegated — the model is a sounding board and a second
reader. Knowing which problems belong here is the whole skill.
Substrate, ICC profile, pass count and cure temperature — the color
decisions a print operator actually makes, surfaced in one panel instead of buried
In market
Shipping, with a founder funding round live. The reason this one matters beyond the print
industry: color management and rasterization are where a creative file meets a physical
device, and knowing that layer is what lets you promise a brand that what they approved on
screen is what comes off the machine.
Email authentication and security auditing platform · live
A production platform that audits email servers and enforces DMARC, SPF and DKIM, with hosted
MTA-STS, BIMI, SPF flattening and TLS reporting. The Adobe angle is the go-to-market:
Express and Firefly run inside agentic routines that produce the marketing team's social content,
so campaign creative for a security product is generated on a schedule rather than commissioned.
tangent.com/dmarc — live platform; the marketing creative around it is generated by Express and Firefly on a schedule
One of several internal marketing dashboards integrating Adobe services
Social publishing automation built on Adobe APIs: Firefly image generation and video generation
calls, Express for product background removal, and scheduling on top. Part of a broader pattern
— I have built a number of internal marketing automation dashboards that sit directly on
Adobe services and applications rather than around them.
Firefly image generation APIFirefly video generation APIAdobe ExpressScheduling / distribution
Internal, in use
Built for and used by an internal marketing function.
Software license management with a custom-trained model · live
A centralised license and subscription management platform — real-time tracking, renewal
alerts up to 90 days out, unused and underused license detection, and audit-readiness. Built on a
custom model trained on license data and compliance rules, not a general-purpose LLM with a
prompt. No Adobe technology in this one; included because it is the clearest example of me
training a domain model against a compliance corpus and putting it in front of paying users.
tangent.com/cubes — software license management on a model trained against license and compliance data
Ambient clinical dictation · absorbed and redirected after acquisition
I helped build the technology behind an always-listening clinical dictation system that
transcribed healthcare information into patient charts — LangChain orchestration over
pre-trained open weights with fine-tuning on domain data. Healthcare and life sciences,
with the data-handling constraints that come with it.
LangChainOpen-weight modelsFine-tuningHealthcare & life sciencesAlways-on ASR
Contributed to an exit
The project was absorbed and redirected, and contributed to a large sale for the company I was
working for. Worth saying plainly: at roughly a year old, the underlying approach is already
dated by current standards. It was the right architecture then and it would not be my first
choice now.
Gunhawk
Custom model, custom hardware, heavy compliance
End-to-end build taken to acquisition · sold to a third party
A project that required a purpose-built AI model, custom hardware, and substantial regulatory
and compliance research before anything could ship. I built AI agents to carry each leg of the
work — research, model, hardware integration, compliance — and drove it through to
completion and sale.
Custom AI modelCustom hardwareRegulatory researchMulti-agent delivery
Political data aggregation and prediction · live tool, being productised
Built as a live tool for a California congressional candidate: aggregates data from many
sources to model political outcomes and let a campaign target voters directly. The client has since
asked to turn it into a SaaS product.
matrix1.base44.app — the live tool delivered to the campaign, now being productised at the client's request
Live, expanding
Delivered to a live campaign; the customer has asked to expand it into a product — the
adoption-to-expansion path, in miniature.
Azure Security Scanner (Scout)
Buy-vs-build, argued with numbers
Cloud security auditing SaaS on an open-source engine · started Sept 2025
Enterprise-grade cloud security auditing at a fraction of market cost by wrapping ScoutSuite in
a purpose-built dashboard and API. The interesting part was not the code — it was making the
commercial case: Wiz, Orca and Prisma Cloud start around $20–30K a year for roughly 100
workloads and scale into six figures, against an open-source engine that produces the same
foundational posture data. I owned the argument and then the architecture split across a
three-person delivery team.
ScoutSuiteAzurePython APICustom UI
On hold
Engine deployed and validated against a live Azure environment; UI built. Parked before the
multi-cloud expansion to AWS and GCP.
Twenty-seven years on this stack
1999
Photoshop 5.5
Where it started. Still the tool I reach for first.
2005
FreeHand → Illustrator
Switched after Adobe acquired Macromedia.
Macromedia era
Flash / ActionScript
Shipped as a Flash developer — creative tool as a programming target,
which is still the throughline.
Then
Adobe ColdFusion
Production hosting, including the first version of Chirps.
Now
Cloudflare Workers
Machine-learning-generated content — Firefly, Express and Firefly
Services output — hosted at the edge.
Now
AE / Premiere / Media Encoder, scripted
Creative applications driven as headless render infrastructure.
SKYNET — live GPU swarmLenovo P8 · dual Intel Arc Pro B70 · on-premise, no cloud egressOpen full ↗
Operator tool, not a client-facing product — this is the
management console for the rack, so it is instrumentation rather than a polished front end.
Real hardware, not a recording: type a prompt into the Orchestrator panel and watch the fleet
view assign it across cards.