Book an intro callIntro call
An AI project that ends up in daily work, without a data team in house.
Orders retyped from the inbox, a spreadsheet next to the ERP, a planning that lives in one head: that is where a bigger project starts. At a wholesaler, nobody retypes over 3,300 of 5,017 order emails anymore. We build it across the systems that are already there, and the team stays in control.
Rather talk right away? Book an intro call
- 2 out of 3Order emails at a wholesaler nobody retypes anymore
- FixedPrice per phase, after the Data Impact Scan
- 8-16 wksFrom first trial to daily use
- 1 yrRunning without us: the yardstick
A solution architect at the table.
No delivery manager and no discovery invoice. In 30 minutes we go through what is there, what stalled if anything did, and what daily use would actually demand. If the honest answer is that an earlier trial should be scrapped rather than scaled, that is said too.
Sound familiar?
It works when one person starts it by hand
A trial that needs someone to run it every Monday is not in daily use. Between something that works once and something that works every day sits most of the budget, and all of the value.
Nobody owns it afterwards
The people who built it are gone, the documentation is a slide deck, and the first time the figures drift nobody can say whether that is normal. Then it quietly stops being used. No data team in house makes this more likely, not less.
Legal asks about the AI Act
For most business applications the obligations are manageable, but somebody has to determine the risk category, write down what the system does, and keep a log. Left until the end, it blocks go-live.
The Data Impact Scan
Curious what this looks like on your data?
Book an intro call with the solution architect who also builds the work. You walk through your processes together and get an honest answer on where the numbers are for you, and where they are not.
30 minutes, no obligation, directly with the builder.
How it works, without risk
- 01
1. Implementation review
30 minutes on what exists, what stalled if anything did, and why. You get a straight read on whether this is a technical problem, a data problem or an organisational one, because the answer decides the whole plan.
- 02
2. Phased, fixed price per phase
Connecting, making it ready for daily use and handing it over are each priced separately, each with a working result. The company can stop after any phase and keep what has been delivered.
- 03
3. Handover that actually holds
Automatic checks that raise an alarm, a written manual, and the company's own people trained on it. The measure of success is that it keeps running for a year without us, not that we stay on retainer.
Why not a large IT firm or the own team?
| Large IT firm | Own team | Stratalytic | |
|---|---|---|---|
| Who does the work | Rotating consultants | People with a day job | The architect who scoped it |
| Time to daily use | Quarters, with change requests | Whenever there is room | 8-16 weeks, phased |
| After go-live | New statement of work | Depends on one person | Written manual plus training |
| When the figures drift | A new ticket | Nobody can tell if it is normal | An alert, and the team knows what to do |
Before the call
What makes this different from a first AI project?
Scale and stakes. A first project is one application in one process. This is an application that has to run daily across several systems, survive bad input, be checked automatically, and be handed to the company's own team. That is a different discipline, and pretending otherwise is why trials stall.
We have no data team. Is that a problem?
No, that is the usual situation. We build and run the first version, and write down how it works so the team can carry on without a specialist. If the team is not ready to take it, we would rather scope a lighter solution than leave the company dependent on us.
An earlier trial stalled. Can you take it over?
Usually yes, and often we keep more of it than expected. The calculation itself is rarely the problem; the data feeding it, the handling of bad input and the connection to the ERP are. We review what exists first and say plainly which parts survive and which are cheaper to rebuild than to repair.
What if it does not work?
Then we find out early and cheaply. The feasibility study runs on a share of the company's own data, free, before anything is invoiced. If there is nothing to gain, there is no proposal. After that each phase has a working result, so the company can stop at any point and keep what was delivered.
What does it cost us in time, and do we need a new system?
The call takes 30 minutes, after that we ask for two years of history of the process and handle the rest. No new system: this sits next to the ERP and the other software that is already there, and the team approves the exceptions.
Our data is messy. Does that stop this?
Usually not. The Data Impact Scan shows what is usable and what needs cleaning, and that goes into the price before anything is built. If the data is not ready, we say so.
What about the EU AI Act?
Most business applications, forecasting, document processing, classification, land in the limited or minimal risk category, where the obligations are transparency and documentation rather than a conformity assessment. We determine the category up front and build the documentation as we go, so it is not a blocker at the end. Where the application genuinely is high risk, we say so before the company commits.
Can this be funded?
Often, yes. Integration and making it ready for daily use regularly qualify as R&D under WBSO at 36-50% of the development labour, and MIT can cover 35% of the broader project. We can file both alongside the build and record the hours as the scheme requires.