AI workflow sprint: take one useful process from idea to practice.

We choose a specific task that people currently do manually, slowly, or with errors. Then we work out what AI should handle, what needs a person, and whether the result holds up on representative examples.

Discuss your workflow

We start with a process someone in your business actually owns.

I build my own products and work with automation, data, and human oversight. That is why I start with the work itself: who does it, what goes into it, where errors happen, and who needs to approve the result.

Product experience: from the first idea through a prototype to a real workflow
People stay involved: AI drafts and processes; responsibility stays clear

The same AI idea has to work for the business, operations, and technology.

The sprint keeps all three perspectives together. Otherwise, it is easy to end up with a demo no one will take into production.

Owner / CEO I need to know whether this use case is worth funding.
We test the value, complexity, and cost of failure before a small idea becomes another never-ending project.
COO / process owner I need to save work without moving the errors somewhere else.
We map the current process, exceptions, and human checks, then measure what actually improves with AI.
CTO / product team I need to test integration, quality, and security without building a whole platform.
We focus the test on the biggest risk: inputs, the model, evaluation, permissions, cost, or human involvement.

We break down the process before adding a model.

An AI workflow is more than a prompt. It connects inputs, rules, a model, checks, exceptions, and the people who act on the result.

Choose the right use case

We compare value, frequency, available inputs, the cost of mistakes, and the owner’s willingness to change the current process.

Decide before building

Design the whole workflow

We describe the input, transformation, checks, exceptions, output, and the point where a person needs to make a decision.

Process before prompts

Test the hardest part

We build or simulate a narrow pilot and measure where it works, where it fails, and what it would take to move forward safely.

Evidence before rollout

You should leave ready to say yes, no, or not yet.

The sprint is not there to rubber-stamp the original idea. Finding that the benefit does not justify the complexity or risk is a useful result too.

A workflow map: Roles, inputs, decisions, exceptions, human checks, and systems in one view.
Results from a focused test: What we actually tested, which examples we used, and the limits of the findings.
A decision on what comes next: The conditions for an operational pilot, further investment, or stopping the idea.

HeyRup’s workflow for processing invoices from email

Experience from my own product

I work through similar questions with HeyRup.

With HeyRup, I work on turning email chaos into a reliable process for finding invoices, sorting them, handling exceptions, and handing them off to an accountant. The automation has to work across the entire workflow, beyond a single demo.

Explore HeyRup

We test the biggest risk before it becomes a big project.

We start by choosing the process. I propose the sprint’s scope based on what we need to test and what we can safely use.

01

Choose

The process, owner, expected benefit, and examples we can work with.
02

Design and test

The workflow, quality requirements, and a focused test of the riskiest part.
03

Decide

Results, limitations, and a specific recommendation to run an operational pilot or stop.

A good fit if

The process has an owner and you can show how it works today.
We have safe access to representative examples.
We can evaluate the result by quality, time, cost, or risk.

Not a good fit if

The entire brief is “do something with AI.”
You expect to automate the whole company in one step.
No one can approve a process change or own the outcome.

What the sprint covers, and where it ends.

The goal is to reduce uncertainty before a larger investment. The scope needs to reflect that.

What will we agree on before starting?

The goal and scope, the people involved, the materials or access needed, the deliverable, timing, price, and any follow-up work that would be a separate engagement. We start only when we have a shared understanding of all of these.

How will we handle nonpublic data?

Before working with nonpublic data, we will agree in writing on which sources may be used, where they may be processed, who has access, and whether external AI tools are allowed. I do not work with nonpublic data without that agreement.

Will we get a production-ready solution?

Not necessarily. You get a workflow map, a focused test, and the conditions for making a decision. Production integration, monitoring, and long-term maintenance are later phases, if the test supports moving forward.

What do you need from our team?

The process owner, someone who knows the current exceptions, and representative examples shared safely. Without their time, we would be testing an assumption rather than the actual work.

How do you determine scope and price?

They depend on the process, available inputs, the biggest risk, and what your business already has in place. Before we start, you will receive a clear proposal covering the test, deliverables, timing, and price.

Ready to move a process beyond the idea stage?

Tell me who does the work today, what makes it difficult, and how often it happens. I will tell you whether it is a good fit for a sprint and what I would need to see first.

Prefer email? jsem@radekduha.cz