Production AI systems

AI systems built for the thousandth run, not the first demo.

I design and build generative AI products where orchestration, evaluation, failure handling, provenance and cost control are part of the architecture from day one.

Most recently, I designed and built POCKT, an AI production platform for fashion brands where garments are uploaded once and turned into complete sets of photos, clips and reels on demand. Built solo in eight months.

See the work Discuss a project
Since 1990

Engineering complex systems across motorsport, search, 3D production and AI.

26

Age when I became Head of Aerodynamics at Arrows Grand Prix.

8 months

POCKT designed and built working alone.

0

New orchestration code required to add a POCKT production workflow.

01. The advantage

Four technical reinventions. The same engineering problem.

My career looks unusual from the outside.

Formula 1 aerodynamics. Search. Technical 3D production. Generative AI.

The technology changed each time. The underlying job did not.

Build the system. Measure what comes out. Understand where it fails. Make the next run better.

01

Formula 1 taught me evaluation

I studied Aeronautical Engineering at Imperial College London, then spent ten years in top-level motorsport aerodynamics with Lola, Reynard and Arrows Grand Prix.

At 26, five years after graduating, I became Head of Aerodynamics at Arrows. The work covered wind tunnel, CFD and trackside development.

It is an environment with very little room for narrative. A design either produces a measurable improvement or it does not.

That makes evaluation part of the engineering process, not something added after the work is finished.

02

Search taught me systems with money attached

In 2003 I built gawwk.co.uk, a UK search engine and shopping comparison business that I ran until 2008. I built my own crawler, index and ranking system in PHP.

The backend generated more than 10,000 search landing pages, and organic search eventually brought in more than 70,000 users a day without advertising spend.

I then built a shopping comparison engine around merchant data feeds before affiliate APIs existed. Merchant schemas had to be normalised in-house. Products had to be categorised and matched. Price changes had to be tracked.

On the paid side, I built automated bidding, keyword expansion and per-term margin tracking across roughly £1 million of self-funded advertising spend.

Performance had an immediate cost. Bad decisions lost money.

03

Technical animation taught me production

For nearly fifteen years I ran Kinesomania, a technical 3D animation studio serving companies including Siemens, Rockwell Collins, B|Braun, Belkin and Nordson.

I grew it from a solo After Effects operation to a team of ten, then back to a specialist solo model as the technology changed.

The production stack changed repeatedly. 2D became 3D. 3D required render farms. Rendering moved toward real-time. Cinema 4D gave way to Unreal Engine.

The requirement stayed the same. Deliver complicated work repeatedly to a fixed quality bar.

Every client came through my own inbound acquisition. Every final quality decision came through me.

04

Generative AI combines all three

Generative systems are unusual because the same input can produce a different result every time.

That does not make them unsuitable for production. It means evaluation, failure handling and repeatability have to become part of the architecture.

A model call is easy. A reliable production system around it is not.

That is the part I build.

02. What I build

From model call to production system.

Generative production platforms

End-to-end systems that take structured inputs through generation, evaluation, finishing and delivery.

Not a prompt box. Not a collection of disconnected workflows. A product.

Evaluation systems

Systems that inspect what they have generated while the job is still running. Outputs can be checked against rules for that job and rejected, regenerated or routed differently before the customer sees them.

The customer should not be the quality-control layer.

Model-independent architecture

The model should be a component, not the architecture. I build systems where models and providers can be changed through configuration rather than redevelopment.

The best model available today may not be the one you want in three months. The product should survive that.

Workflow architecture

Reusable production steps rather than one-off scripts. New workflows are composed from capabilities that already exist wherever possible.

That changes the economics of extending the product and reduces the amount of code that has to be maintained.

Commercial infrastructure

Accounts Permissions Queues Billing Credits Cost modelling Audit trails Versioning Multi-tenant isolation

The parts nobody puts in the demo and every real product eventually needs.

03. Production discipline

The hard part starts after the demo works.

Calling a model successfully is not difficult.

Building a system that can do it repeatedly, economically and without handing every failure back to the user is a different problem.

It checks its own work

Evaluation happens while the job is still running. Outputs can be inspected against the requirements for that job and regenerated before delivery when they fall short.

Problems should be caught inside the production run, not by the customer opening a folder of unusable files.

Failure gets absorbed

Generation services fail. They time out. They rate-limit. They sometimes refuse valid requests. Individual items fail inside otherwise successful batches.

A production system should expect that. Retries, backoff and partial failure handling belong inside the system rather than in the user's workflow.

One failed item should not automatically cost an entire run.

New workflows are composed, not rewritten

In POCKT, production capabilities are reusable steps. A new capsule is assembled from existing pieces rather than implemented as another standalone workflow.

That means the system can gain new products without gaining the same amount of new orchestration code.

The tenth workflow should cost less to add than the first. Eventually, adding another one should become mostly configuration.

Models stay replaceable

Models are selected through configuration rather than buried inside workflows. Changing provider or model should be an operational decision, not a redevelopment project.

The architecture should not care which supplier happens to have the strongest model this month.

Costs are architecture

Every generation step has a real operating cost. Those costs need to be known before the product is priced.

That is what makes rational credit pricing, batch sizing, queue priority and margins possible.

Unit economics should be designed into an AI product, not discovered from the first large infrastructure bill.

Running jobs do not change underneath themselves

A running job keeps the instructions and configuration it started with. If the production recipe changes while the job is running, the existing run continues against its original version.

That gives you a record of what actually produced an output.

Repeatability requires more than saving the final file.

04. Governance and provenance

Governance belongs in the pipeline.

Synthetic content introduces questions traditional software often did not have to answer.

Where did this file come from? Was it generated? Can that be proved later? Who or what does it depict? Who is allowed to access it?

Those questions are easier to solve in the architecture than after the product has shipped.

Proof of origin

In POCKT, generated files are signed with Content Credentials and a trusted timestamp so their origin can be demonstrated later. The signed file is read back and checked rather than simply assuming the signing operation succeeded.

Disclosure

AI-generation disclosure is applied to the output where required. A plain-text fallback is available so a failed metadata operation does not silently remove the disclosure.

Fail safe

Where a compliance check cannot be completed, the system takes the cautious route. Uncertainty should not automatically become permission.

Synthetic people

POCKT's models are synthetic and depict no real individual. That removes the likeness and model-release problem from the production process and gives the client clear commercial usage rights.

Customer isolation

Garments, models and generated work belonging to one customer remain separate from another customer's data. Access checks refuse uncertain requests rather than attempting to guess.

05. Work

Selected systems

POCKT

Fashion | Dec 2025 to present

An AI production platform for fashion brands, designed, built and run by me.

The problem

Fashion brands work continuously, but traditional content production happens in shoots.

Generative tools appear to remove that bottleneck until the full workflow is counted.

Prompting Wiring Testing Checking Retrying Correcting Upscaling Cropping Formatting Packaging

The expensive part is not generating an image. It is getting from a garment to a complete, usable and repeatable content set.

The hard part

Consistency.

Producing one striking AI image is no longer particularly difficult. Producing the same person, garment and brand register across a complete body of work is a different problem.

That requires state, persistence and evaluation. It is not simply a prompting problem.

That is why garments, models, collections and looks are stored as real objects in POCKT rather than repeatedly described as parameters in a prompt. It is also why evaluation runs during production rather than waiting until the end.

What I built
  • A reusable library of production steps that can be assembled into different content workflows.
  • Persistent garments, models, styling and looks, so setup can be reused instead of recreated for every run.
  • Evaluation during production, with failed outputs regenerated before delivery.
  • Configurable model selection, allowing providers and models to change without rebuilding the workflow.
  • Retry and failure handling for generation services.
  • Batch behaviour where an individual failure does not automatically stop the rest of the run.
  • Step-level cost modelling underpinning credits, batch sizes and queue behaviour.
  • Subscription, top-up and refund infrastructure.
  • An affiliate system with automated monthly payouts, self-billing invoices, VAT handling and controls against self-referral.
  • Provenance, disclosure and customer isolation built into the production path.
Result

Designed and built solo in eight months. New production capsules can be assembled from reusable steps without writing new orchestration code for each one.

Visit POCKT

Industrial Configurator

Industrial

An AI-driven product configurator for an industrial client.

The problem

Industrial product configuration is usually built around forms, option trees and static product imagery.

The aim here was different. Let a visitor configure a product through conversation while seeing it respond visually.

What I built

The first version was developed in Unreal Engine Blueprint with voice input and streamed interactively to the browser.

A visitor could specify a product conversationally, see the configuration change, save it and route the result into the sales process.

I later rebuilt the visual system browser-native in Three.js.

The hard part

The original Unreal architecture worked, but browser delivery depended on GPU streaming infrastructure. Every active session therefore carried an infrastructure cost.

The browser-native rebuild moved the rendering workload onto the visitor's own device. That removed the streaming-server dependency entirely.

Result

A working browser-native prototype demonstrated to the client, without the GPU streaming infrastructure required by the original version.

brik.works

Property marketing | In development

An AI marketing product for UK estate agents.

Currently in build.

Hevvy

Industrial | Explored, then stopped

An industrial AI concept taken through customer conversations.

Feedback from larger target organisations indicated that companies of that scale were more likely to build the capability internally. I stopped pursuing it.

Stopping a product when the evidence changes is part of product development too.

06. Stack

What I actually use

No technology wall. These are tools and disciplines I use in real work.

Build daily

TypeScript Next.js React Node.js Python Prisma PostgreSQL Tailwind Railway Stripe

AI systems

Workflow orchestration Vision evaluation Prompt and instruction versioning Model routing Retry and failure handling Per-step cost modelling

Generative

fal.ai OpenAI Google Gemini Replicate ElevenLabs ComfyUI Three.js Unreal Engine Cinema 4D

Governance and operations

C2PA Content Credentials RFC 3161 timestamping EU AI disclosure Multi-tenant isolation Audit logging

07. Engagements

Ways to work with me

I keep consulting deliberately limited because I am building POCKT.

That means I am most useful where senior architectural judgement will materially change what gets built.

Architecture review

From £6,000 | typically 1 to 2 weeks

For teams whose AI product works in a demo but starts to break when real users, volume and operating costs arrive.

I review the system across:

orchestration evaluation retry and failure behaviour model dependencies versioning cost architecture operational risk provenance and governance

You get a technical assessment of the current architecture and a prioritised remediation plan.

The aim is not a generic report. It is to identify what will stop the system scaling reliably and what should change first.

Discuss an architecture review

Fractional AI architect

From £4,500 per month | ongoing

Senior technical involvement for a team building an AI product without a production AI architect in-house.

Useful when you already have engineers but need someone to make architectural decisions, challenge assumptions and stop the product becoming a collection of one-off fixes.

Typical work includes:

architecture review workflow design model and provider strategy evaluation architecture reliability and retry design cost modelling governance technical decision-making production readiness
Discuss a fractional role

Larger builds

I occasionally take on end-to-end production builds where the problem is unusually well matched to my experience. These are substantial systems rather than isolated AI features.

I take these on selectively because a full build competes directly with time spent on POCKT. If the project is a strong fit, we can scope it.

Discuss a build

A typical build might cover:

ingestion structured state orchestration generation evaluation retries finishing formatting delivery billing governance operational tooling

08. About

Simon Jennings

I have been building technical systems professionally since 1990.

I studied Aeronautical Engineering at Imperial College London before moving directly into motorsport aerodynamics. I worked at Lola and Reynard, then became Head of Aerodynamics at Arrows Grand Prix at 26.

After motorsport I taught myself web development and search. I started Internetbuff in 2001, building websites and local SEO for small and medium-sized businesses.

In 2003 I founded Gawwk Ltd and built gawwk.co.uk, my own UK search engine and shopping comparison business.

From 2008 to 2023 I ran Kinesomania, a technical 3D animation studio that grew to ten people and worked for companies including Siemens, Rockwell Collins, B|Braun, Belkin and Nordson.

In 2023 I founded AYEYE IO LTD. Today I design and build production AI systems and products, including POCKT.

simon@ayeye.io Connect on LinkedIn
Simon Jennings

The medium has changed several times. The thing I enjoy building has not.

Systems where the difficult part is not making something happen once, but making it happen reliably, repeatedly and economically.

Building something that has to work more than once?

If you are past the AI-demo stage and the difficult questions are now consistency, evaluation, failures, provenance, cost or architecture, that is the work I am interested in.

Tell me:

  • what you are building
  • what already works
  • where it starts to break
  • what production scale looks like for you
Connect
Email simon@ayeye.io
Or call direct +44 (0) 7879 448 247

© 2026 AYEYE IO LTD, United Kingdom: REG. NO. 5113299 VAT NO. GB839353696

We respect your privacy - we use only essential cookies.