Alan Salomon
Production AI and data systems.Built to survive contact with reality.
I build systems, applications, and solutions for German and European teams.
Based in Germany · Remote · Available for selected fixed-scope projects
Work
View allSystems built to be checked.
Full applications rather than demos: a schema, a database, an API, an interface somebody works in all day, and a test suite that says what the thing is actually worth. Each one is written up with its architecture, the decisions that hold it together, the code that enforces them, and the defects that got through anyway.
One click in Salesforce, and the document becomes data
A document extraction service that is one click inside Salesforce and a FastAPI application on Kubernetes underneath. It identifies the document type, parses it, extracts against a schema written for that type, computes the derived columns the business needs, and writes the result back to the record that triggered it. Input is whatever arrives, including scans and photographs. The model runs inside the client's own Azure tenancy.
One number for what an ad is actually worth
Salesforce, Google Ads, LinkedIn Ads, Facebook Ads and website activity extracted into Snowflake, transformed in dbt through staging, marts and a semantic layer, and served to Tableau on a fifteen-minute cycle. Built for a German financial services company serving doctors and healthcare professionals.
Invoice extraction, built to be measured
Anyone can build an invoice extractor that works on a clean PDF. This one was built to answer the harder question: how accurate per field, how consistent across repeated runs, and where does it break. It ships as a working review application with the measurement harness underneath it.
The AI Museum
Forty-three pages generated from three data files: five era rooms with their own walls, a guided tour, view transitions between gallery and exhibit, and a chart whose subject is the fifteen models that never published a parameter count. Every colour in it was computed rather than judged.
Ways to work together
Four ways this usually starts.
Every one of these is something already on this site, done for somebody else first. The link under each is the work it comes from.
AI and automation assessment
Architecture, risks and an implementation plan you own
A short engagement that ends in a document rather than a system: what to build, what it will cost to run, where it will break, and which parts are not worth automating at all. Useful when a workflow is an obvious candidate for automation and nobody can yet say what the finished thing looks like.
Fixed-scope implementation
One operational workflow, delivered end to end
One workflow taken from wherever the data starts to the interface somebody uses, including the parts that are nobody's favourite: the failure paths, the retries, the place a person checks the result. Fixed scope because an open-ended build is how these become expensive without becoming finished.
Data platform work
Extraction, warehouse, modelling and the dashboards on top
Building a reporting stack, or repairing one that reports numbers the business does not believe. Sources into a warehouse, transformation in layers, access granted per role, and the refresh cycle stated rather than assumed. Most of the value is in the modelling, which is the part usually skipped.
Production AI review
An evaluation harness and a written reliability account
For a system that already works in a demo and is about to meet real users. What it gets wrong, how often, and how you would know: a harness that measures it, the failure modes named, and the cases where a confident answer is a wrong one. The output is a number you can defend, or the reason there is not one yet.
Or read the case studies first. They are written to be checked, not skimmed.
Salomon Labs
Tools that connect to each other.
Each one does a single job and hands its result to the next. Published as Apify Actors, callable over API or MCP, priced per run. Every claim on these pages is something you can go and check.
YouTube Creator Finder
Find YouTube creators by niche, filter them by subscriber count and country, and get their profile, links and public contact email - each one validated with a plain-English send recommendation.
Bulk Email Validator
Remove invalid, dead-domain, disposable and role addresses from any email list, and get a 0-100 send-risk score with a plain-English reason for every row.
Website Email & Phone Finder
Give it a company website and get every published email and phone number, each with the page it was found on and a 0-100 send-risk score with a plain-English reason.
YouTube Channel Analyzer
Analyze YouTube channels for sponsorship: expected views from recent uploads, audience language inferred from real comments, upload cadence, engagement, whether they already take brand deals, and an estimated price from your own CPM.
Company Enrichment
Give it a company website and get what that company sells - product categories, brand and product names, whether there is a checkout and on which platform - each fact with the page it came from.
What can feed what
- YouTube Creator Findercan passemail addressestoBulk Email Validator
- YouTube Creator Findercan passwebsite URLstoWebsite Email & Phone Finder
- YouTube Creator Findercan passwebsite URLstoCompany Enrichment
Each tool is independent and none of them calls another. The validator accepts the dataset of any previous run, so anything upstream that produces addresses can be wired into it, by you or by an agent, without an export step in between.
Callable by an agent
All of these run as Apify Actors, which means an MCP client reaches them through Apify's hosted server at mcp.apify.com. Nothing extra was built for that. An agent can find them by search, or be pointed at them by name.
Which is where the composition above stops being theoretical: an agent that can call both can find creators and qualify their addresses in one instruction, without anyone assembling a pipeline first.
The AI Museum Experiment
Nine years of AI. Drag through it.
Every milestone that mattered — from the Transformer to today. Watch it play on its own, or take control.
Playing automatically — or drag to explore →
Earlier
Writing
Insights & Articles
About me
Alan Salomon
I'm an AI engineer, and I run my own development practice. I build systems that automate real operational processes: document extraction, decision pipelines, reporting infrastructure, and the applications people work in day to day. Some are built for companies, some I publish under my own name. I care about whether things work in production, not just in demos.
I also write. I'm interested in what AI systems mean for humans — how they change the nature of work, shift where decisions live, and reshape what organizations look like. Engineering and writing, for me, are the same investigation from two angles.
I work at the intersection of building these systems and understanding their consequences. Most of what I explore is still open-ended. That's the point.
Feel free to reach out — hello@alansalomon.ai
