I work differently. The first implementation wraps up in four weeks, in one department, and ends with a working tool in the team's daily routine. Below, I break down what happens week by week, and why this particular scale.
Why four weeks, not six months
Four weeks isn't a shortcut or a sales pitch. It's a scale matched to how a mid-sized manufacturing company actually operates.
A longer project has one drawback that few people mention upfront: the longer it runs, the further away the moment when anyone sees a result. Six months is enough time for management priorities to shift, for the person who championed the project to leave, or for the team to conclude that "they're implementing something again and nothing will come of it." I've seen projects die not because the solution was bad, but because no one lived to see the result.
A short cycle reverses that logic. After four weeks, there's something people actually use. Not a presentation, not a report, not a prototype for further discussion. A tool that someone in the department opens on Monday morning and that saves them time. That changes the entire dynamic — the next decision gets made based on something that works, not a promise.
The second reason is practical. Four weeks is enough time to fully involve one department's team without pulling them off their current work. A longer engagement starts competing with the work those people still have to do. Anything shorter isn't enough to properly scope and build something meaningful. Four weeks hits the window where both fit.
Week one — discovery
The first week isn't about technology. It's about how the department actually works.
I sit down with the team and go through what they do every day. Where the time goes. What repeats. What everyone does even though nobody likes it. Where information gets stuck, gets lost, or lives only in someone's head because it exists nowhere else. Those are the places where AI makes sense. Not the ones that sound impressive. The ones that hurt every day.
I come in with a catalog of typical problems for the given department, because some things repeat across manufacturing companies regardless of industry. But the catalog is a starting point, not a ready-made answer. In the first week, I check which of these problems are actually real in this department today, and which need to be added because they're specific to this business.
By the end of week one there's a decision point. We choose exactly what we're building. If the picture doesn't add up at this stage, it's better to know after a week than after a month — and this checkpoint is built precisely for that.
The first week of the pilot overlaps with what the AI Readiness Audit delivers — identifying where implementation makes sense. If you want that map before deciding on a full pilot, the audit is step zero.
→ AI Readiness Audit
The middle weeks — building with the team, not next to it
This is where the tool gets built. More important than what gets built is how.
The app is built together with the people who'll use it. It doesn't disappear for two weeks to come back finished. The team sees each new version, says what doesn't fit, and we fix it on the spot. Sounds obvious, and it makes all the difference — a tool built apart from the people who'll use it almost always ends up out of step with how the work actually looks.
There's a second, less visible assumption in this. Over these weeks, the team learns how it works. Not to turn them into developers. The point is for them to understand what they're holding — where the tool's limits are, why it sometimes answers differently, when to trust it and when to check it. After an implementation where people just received a finished system, what's left is dependency. After one where they helped build it, what's left is competence. That's the difference that matters to me.
The last week — moving into daily work
The last week is the shift from "works in the demo" to "works on the floor."
The tool goes into real use. Things surface that you don't see in a demo — an edge case nobody predicted, a process step that in practice looks different from the workshop session. That gets resolved now, fresh, while I'm still in the department.
What's left is a working tool, a team that knows how to use it, and a picture of what comes next. Because the first pilot is rarely the end. More often it points to other places where the same approach would help — in the same department or next to it. What to do with that is a separate decision, made based on something you're holding, not something you're hoping for.
What this pilot is not
Three things, to keep it honest.
It's not a transformation of the whole company. It runs in one department, with one or two processes. That's deliberate. Big "everything at once" implementations are exactly the kind of project that dies within six months — I wrote about that separately in the context of microapps.
It's not a ready-made off-the-shelf product you just switch on. It's built for a specific department and a specific process, so it requires the team's involvement throughout those four weeks. Without that involvement, there's nothing to build from.
And it's not magic. AI won't fix a process that's broken at its core — at most, it'll show faster that it's broken. If the department's problem lies in how the work is organized, we organize the work first, and only then layer the tool on top. Sometimes the best outcome of week one is precisely that diagnosis.
What's next
If you're considering a first implementation, the order is simple. Pick a department with a repeatable process or a repeatable problem — that's where the return comes fastest. Check whether that process is organized enough to be supported by a tool. And start with discovery before anything gets built.
I keep the full mechanics of the package, six area-specific variants matched to departments, and answers to specific questions on a separate page.
→ See the Pilot Implementation and six variants
→ Book a 30-minute consultation
