How DynamicsPrint® got two products from one AI pilot
This is a follow-up to our post on Infinite Resources. That post argued that AI creates a new path for creating successful, valuable products. As the path both challenges and expands existing practices, we need to divide it into three phases: Apply, Reshape, and Innovate. This post is a case study of the first phase: Experience from a project with DynamicsPrint® from May to August 2026.
DynamicsPrint® is the leading provider of ERP solutions for the global print & packaging market. The company is experiencing rapid growth and hence a need to expand development capacity for both implementation and innovation.
Difficult to get going with new AI practices
Apply is a difficult phase, because we are overwhelmed with information about AI currently. and most examples are from new green-field projects. Everything is unclear. The importance of AI in the first place. Which tool to use. What about security. New lingo every week: Vibe, Harness, Loop…the list gets longer and longer. And everyone has existing commitments that needs to be prioritized.
So, you either need to spend months and dedicated staff on Apply……or you need someone experienced you trust to guide you.
Here is how we did it in partnership with DynamicsPrint®.
The pilot project setup
The pilot was deliberately modest and short: 130 CPC consultant hours over ten weeks, plus a bounded slice of the development team’s time. Each of the five developers put in roughly 24 hours during the training weeks, and the one developer who did the build worked about half time during the implementation phase. An internal ERP consultant was allocated to writing the requirements. Nobody worked on it full time. The budget was small enough that no one had to compromise on customer commitments or urgent deliverables…..and large enough that the result would be valuable for the business.
We picked a real deliverable: a full integration of a specialized third-party production tool with the DynamicsPrint’s ERP solution. This was a genuine item from the product backlog, with real complexity.
And then we made one rule: the developers were not allowed to write code.
They could review code. They could reject it, question it, demand changes. But the production loop had to run as requirements → development → test → review, with AI doing the writing at every step and developers steering. The internal ERP consultant on the project got the same instructions: responsible for the requirement specifications but required to produce them using Claude Cowork rather than writing them by hand.
The rule is an important design decision in the pilot project. We want to avoid AI becoming a fancy autocomplete, and at the end of ten weeks you have learned nothing about what the technology can carry. The ban is a forcing function: it converts “trying AI” into “depending on AI”, which is the only condition under which you discover where it breaks.
Weeks 1–3: Trust before building products
We spent the first three weeks not building anything work-related. All five developers went through training on Claude: the working loop and the skills ecosystem (e.g. SuperPowers) that turns a raw model into a working tool.
Just as important: we took the security concerns seriously instead of waving them away. We wrote a full AI security policy for the company and configured every account accordingly before the real work started. Rather than capacity and time, the top concern about AI is often about “am I allowed to put our code and customer data in there?” Answering that question, agreeing with management in writing up front, provides the foundation for learning.
The learning and setup phase was signed off with each developer creating their own implementation of choice. We had everything from a game over a pottery index app to a new interactive website for the company.
Weeks 4–7: One product builder, real work
The implementation phase ran about four weeks, part time. Here we made a second deliberate choice: all five developers were trained, but only one did the implementation. The internal ERP consultant fed the loop with Claude Cowork-written specifications, which meant the requirements themselves were versioned, structured, and precise enough for Claude to build from.
Alongside the product work, the same weeks were used to mature the Claude setup itself: the configuration, conventions, and harness.
Weeks 8–10: Report to distill learnings
The final two weeks were the CPC consultant’s alone. The developers were back on their regular work. The time went to evaluation and reporting to the management team. The Apply phase ends with a decision on how to proceed, and decisions need evidence presented to the people who allocate resources.
The results
The integration built in the pilot is now being included in the DynamicsPrint’s commercial product range. A pilot deliverable became a product feature. The management team saw the result and was amazed how far along it was.
The developer reports he works at least 2x the speed as before. He has used Claude for everything he has worked on since the pilot ended, not just integration. He also covered new ground in DynamicsPrint’s own ERP domain on his own, which is a learning process that normally requires interacting with the most experienced engineers and consultants.
We spent USD 800 on Claude licenses and tokens doing so.
But the more telling result is the one we did not plan. During the pilot, one of the developers built an internal dashboard for customer information in parallel, again using only AI to write the code. It went into production too. The company got two solutions from a pilot budgeted for one.
That unplanned second product is what the Infinite Resources thesis looks like when it lands in reality. When the marginal cost of building drops far enough, things that were never important enough to schedule simply get built. No steering committee approved the dashboard. It happened because building it became easy and the developer was motivated….and had fun doing it.
That is the change we are looking for in the team.
Five decisions for a successful project
Looking back, five decisions carried the pilot: 1) Pick a real production deliverable, 2) Go full commit on the tool, 3) Solve security first and in writing, because trust unlocks adoption, 4) Train everyone (to create the conversation and support) but limit the pilot implementation to a few people, so other commitments are respected, and 5) end with a report to management, because the end of the Apply phase is the beginning of Reshape.
The next Step: Moving from Apply to Reshape
The team is already transitioning into the Reshape phase: the discussions over lunch have moved from “can AI build our software?” to “how do we integrate AI into our processes and toolchain permanently?” That is a different kind of work: definition of done, review practices, CI/CD, the role of specifications as first-class artifacts. We will write a post about that next. The Apply phase does not require a transformation program, a task force, or a seven-figure budget. It requires someone experienced to guide the process, a bounded slice of the team’s calendar, one real deliverable, the “do not write code” rule, and a commitment from management to understand and support the process.
Thank you to DynamicsPrint® for letting us share their experiences.
At Copenhagen Product Collective, we work with companies to assess their product and technology leadership structures and build capabilities across both domains. If you’re wrestling with questions about how to structure your senior leadership and team topology, let’s talk.
