In brief
You’ll have a written, review-ready feasibility decision: what ML can do here, what the data supports today, what must change to make it work, and the engineering work to prove it before production.
You’re being asked to “add ML” to a line-of-business tool, but the data, joins, labels, and success metrics haven’t been checked end to end yet. We’ll answer what’s possible, what it will take, and how we’ll prove it before any build starts. If you’d like to go ahead, we’ll book a week-one intake and line up data access.
We treat feasibility like an audit: we start from the business decision the model would support, trace it back to labels and source systems, then design the smallest set of experiments that can fail fast. You’ll see assumptions written down, leakage checks called out, and a costed path from baseline to something you can run and monitor.
A bit about us
We’re a three-person Data & AI team that gets brought in when “we should use ML” has reached budget conversations. We’ve seen the same failure mode repeat: a model gets promised before anyone has checked label availability, joins across systems, or what metric the business will accept. Our work starts there, with the parts that decide whether the build is worth doing.
We’re useful when you need something that survives scrutiny. We write down assumptions and data dependencies, we test for leakage and proxy features early, and we separate “possible” from “provable” with an experiment plan you can run. If the right answer is “not with the current data”, you’ll get that answer with the specific blockers, not a vague recommendation.
Meet the team
You’ll work with the same three people from first intake through the final handover, so questions don’t get bounced between roles.
Team
Anna Leitner, ML lead. Anna leads the ML work: use-case framing, baseline approach, metric choice, and the checks that decide whether a model will validate.
Lukas Gruber, Data engineer. Lukas handles data access and the hard parts of “do we actually have this”: joins, timestamps, label construction, and a map of gaps to fix.
Miriam Hofer, Delivery lead. Miriam runs delivery: keeps decisions and assumptions written down, schedules working sessions, and turns findings into a document a committee can audit.
Recent work
Here are three recent ml technical feasibility engagements, showing the range from product features to operational forecasting and risk controls.
Portfolio
Support routing feasibility. Assessed whether tickets could be routed automatically using existing fields and text. Found label noise and missing resolution codes, designed a relabel pass, and produced a baseline plan that set an achievable precision target before build.
Demand forecast feasibility. Audited source-of-truth sales and inventory feeds, reconciled time zones and late-arriving data, and set an evaluation plan around horizon-specific error. The result was a build/no-build decision tied to measurable forecast lift.
Compliance triage feasibility. Checked whether model-driven triage was defensible under GDPR constraints. Mapped lawful basis, reviewed sensitive attributes and proxies, and defined explainability requirements alongside an offline validation plan.
“They gave us a straight answer and a plan our CFO could challenge.”
Product lead, a line-of-business software team
How this runs
We run this in short working sessions, with written notes after each one. You’ll always know what we checked, what we could not check yet, and what decision each piece of work supports.
1. Intake and constraints Days 1-2 We meet with the product and operational owners to pin down the decision the model would influence, what “good enough” means, and what constraints apply. We capture the target label candidate, the users affected, and the budget or timing constraints you already have to live with. 2. Data access and labels Days 3-6 We get read access to the relevant systems and confirm we can join records in time order. Lukas traces keys, timestamps, and retention limits, then we attempt label construction and document where it breaks. You’ll see a list of missing fields, unstable joins, and leakage risks. 3. Baseline plan and metrics Week 2 Anna proposes baseline approaches that match the label and data shape, then we set evaluation metrics that map to the business decision. We define holdout rules, what counts as a valid test, and what result would justify moving into a build. We also call out what cannot be measured yet. 4. Deployment and costed path Week 3 We outline how the model would run in production, what gets logged, how drift is detected, and what triggers retraining. We finish with assumptions, risks, and a costed plan that separates data work, model work, and integration work, so you can budget engineering time with fewer surprises.
Feasibility write-up
A single document that states the use case, the data findings, what is feasible now, what blocks feasibility, and a clear go or no-go recommendation with reasons.
DATA READINESS AUDIT NOTES
A structured inventory of sources, access method, join keys, timestamp fields, retention, and quality gaps, written so an engineer can fix what is fixable.
LABEL AND LEAKAGE ASSESSMENT
A definition of the target label we can test, what proxy features would leak the answer, and the checks we will use to keep offline results honest.
Baseline model plan
A plan covering candidate features, suitable model families, evaluation metrics, and the minimum baseline that can prove whether the idea has signal.
EXPERIMENT AND VALIDATION PLAN
An end-to-end test plan: offline holdout design, any A/B or shadow run approach if needed, decision thresholds, and what evidence is required before production work starts.
MLOPS AND GOVERNANCE OUTLINE
A practical outline for deployment, monitoring, retraining triggers, and model governance notes covering GDPR, bias concerns, and explainability expectations for this use case.
Pricing
Pick the tier that matches how many data sources and how much proof you need before you take this to finance.
Priced items
Get started
If you’re ready to start, we can book the work and line up access so week one is spent checking data, not chasing credentials.
1. Sign the proposal to confirm scope and start date. 2. Pay 25% to book the work; we’ll send the first invoice the same day. 3. Introduce us to your data and product owners so we can schedule intake and request access.
Signature
Fee summary
Payment
To book the work, we invoice 25% when you sign. We invoice the remaining 75% when we hand over the finished work. Each invoice is payable within 14 days of its date.
What we need from you. In week one we need stakeholder time for intake, plus access to the listed data sources and a point person who can answer data questions within one business day.
Data access and security. You provide access through your approved method. We work inside the access you grant and document any missing permissions that block joins, label discovery, or leakage checks.
Changes to scope. If the use case, data sources, or validation requirements change, we will write the change into the plan before we do the extra work, so cost and timeline stay tied to scope.
Assumptions and no go outcomes
Our write-up will state the assumptions the feasibility call depends on. If we find missing labels, unjoinable sources, or leakage that breaks validation, we will say so and stop short of promising a model.
Timeline and availability. We schedule work in the order it is booked. Dates in the plan depend on timely access to data and stakeholders. If access slips, we shift the schedule and keep the sequence of steps the same.
Handover and ownership. Once the final invoice is paid, you own the feasibility write-up and supporting notes we deliver. We keep our internal working files and reusable checklists, and we do not share your data.
Confidentiality. We treat your data, product plans, and internal documents as confidential. If you need a specific NDA or security addendum, send it before kickoff so we can review it with the access plan.
