Specialized AI applications
Products where task-specific classifiers, sequence models, retrieval, assistants, or carefully bounded LLM components must outperform a generic wrapper.
From raw data to a working AI product.
For teams that need more than a trained model. I design and build the whole product around it: data and annotation, evaluation, models and domain logic, the web app, API, and database, optimized inference, monitoring, and a handoff your team can own.
- First working version
- Within 6 weeks of the start
- Indicative investment
- from €25,000 excl. VAT
- Primary outcome
- A deployed, documented AI product
- Payment
- Per milestone; stop after any one
From a model to a working product
AI projects often fragment at the boundaries: labels do not match product semantics, offline metrics do not reflect user value, model outputs need brittle postprocessing, infrastructure decisions arrive too late, and nobody owns the final experience.
I work across those boundaries. The architecture starts with the decision the product must make and the evidence users need to trust it. Models, rules, geometry, services, interfaces, and operational safeguards are then designed as one system rather than handed between disconnected specialists.
When this is useful
Production computer vision
Multi-stage systems combining detection, segmentation, pose, tracking, geometry, temporal models, and downstream business logic.
Sports and video intelligence
Products that must turn raw footage into reliable events, movement features, biomechanics, scores, recommendations, or visual feedback.
Full-stack AI products
Web products where the AI feature needs the rest of the product built too: the interface, API, database, accounts, and the everyday workflows people use it in.
What the build covers
Data and task definition
- Product metric and failure policy
- Annotation schema and review workflow
- Dataset versioning and quality controls
- Representative evaluation design
Models and domain reasoning
- Model selection and custom training
- Temporal, spatial, and geometric logic
- Postprocessing and confidence handling
- Explainable product outputs
Product and deployment
- Web app, API, and database
- Optimized inference on cloud or edge
- Monitoring and failure visibility
- Documentation and team handoff
From scope to deployment
- 01
Scope the outcome
Define the user decision, constraints, evidence, product boundary, milestones, and the first risk that must be retired.
- 02
Build the foundation
Establish data, annotation, evaluation, architecture, and a thin end-to-end path before scaling individual components. Within six weeks of the start you have a first working version: your model running on your own data, behind an app your team can try.
- 03
Harden the system
Improve model quality, domain reasoning, performance, failure handling, monitoring, and integration against real inputs.
- 04
Ship and transfer
Deploy, document decisions and operations, validate product behavior, and leave the team with ownership rather than dependency.
What each milestone gives you
Before it starts
We agree on the goal, the acceptance criteria, and the price of the milestone.
When it ends
A demo on your own data against those criteria, with the code, model files, and documentation in your repository.
Then you decide
Continue, change the plan, or stop. You pay per milestone, and if you stop, you keep everything delivered.
What comes with the code
- Data collection and filming assumptions
- Annotation tooling and label quality
- Model licences and commercial constraints
- Evaluation tied to product behavior
- Preprocessing and postprocessing correctness
- Latency, throughput, memory, and cloud cost
- Failure states and confidence communication
- APIs, integration contracts, and observability
- Web interface, accounts, and permissions
- Coach-, operator-, or customer-facing visuals
- Reproducible training and deployment
- Architecture records and runbooks
- Review, handoff, and adoption support
AIM: one intelligence layer across the full product.
For AIM, I built the connected path from football video and annotation through filming validation, player and ball perception, cone geometry, temporal phase and repetition models, biomechanics, scoring, optimized inference, APIs, quality controls, and the final visualization. The shipped product works because those components share one domain model and one product goal.
How we work together
You work with the builder
I handle technical discovery, architecture, implementation, measurement, and stakeholder communication. Decisions do not disappear through an account-management layer.
Your team keeps the system
Code, documentation, model artifacts, operating knowledge, and decision context are delivered for long-term ownership. The goal is a product capability, not permanent consultant dependence.
Before we start
Can you build the product around the AI, not only the model?
Yes. The interface, API, database, accounts, and integrations can be part of the same build, designed with the AI feature rather than bolted on afterward. When a build needs two engineers, I bring in Frusto Labs, the two-person studio I work with, and you still deal with me directly.
Can you join an existing product and engineering team?
Yes. I can own the intelligence layer while working with existing product, backend, frontend, mobile, or platform engineers. Responsibilities and interfaces are made explicit during scoping.
Do we need to know the exact architecture first?
No. The product outcome and constraints should be clear enough to scope discovery. Model and architecture choices are engineering outputs, not prerequisites the client has to provide.
How is a larger build controlled?
The work is split into milestones, each with acceptance criteria and its own price. You pay per milestone and can stop after any one, keeping everything delivered. The first milestone targets the highest technical risk, so the project can change direction before downstream work becomes expensive.
Can you continue after the initial launch?
Yes. A build can include a defined stabilization period, follow-on feature milestones, or support for the internal team. The preferred model is still explicit scope and ownership rather than indefinite ambiguity.
Start with a smaller engagement
What should the product be able to do for its users?
Send me the current product, data, team, constraints, and the capability you want to ship. I’ll reply personally within one business day with the questions that determine a sensible first scope.
Work directly with Jude Mingay, a freelance AI product engineer based in Freiburg, Germany. Remote projects worldwide; English, German, or Portuguese.