What this is about

I make processes faster. That is what I enjoy most about my job.

Almost everywhere you find the same spots. Someone waits three weeks for a report. Someone copies by hand what two systems could exchange themselves. And some positions exist only because one person can operate a particular program. I find those spots and put technology where it pays off.

What carries today and what is still a demo ↓

A typical waiting list

Marketing: A campaign to customers who bought a particular product and nothing in the last six months. Waiting for the query.
Sales: One additional field in the CRM, with an approval step. Three weeks, if nothing intervenes.
Controlling: A recurring report from the ERP, the shop and a spreadsheet. Stuck in the backlog.
HR: Onboarding across four systems. Today: the same data typed in four times.
Support: A new escalation rule in the ticketing system. Two sentences to describe, impossible to set up alone.

Examples, not client cases. The person knows exactly what they need. They just cannot execute it.

Starting point

How you can tell this page is about you

Size is not the point. I see the same pattern in a company of eighty and in a corporate division of three thousand.

Describe yes, execute no

Your people can say exactly what they need. Only IT or an external provider may implement it. Whoever queued twice stops proposing anything the third time.

A role built around one system

Some positions exist mainly because someone can operate a particular system safely. If that person is out, the process stops.

Bridged by hand

Between two systems sits a person who transfers and reconciles, because the connection never had a budget of its own.

AI stayed in the demo

Someone tried something, it looked good, then it stalled. In testing, in legal, in the security review. Not because the tool was bad, but because nobody would have recognised a wrong result.

Where this shows up day to day

If two of these four sound familiar, the rest of this page is worth your time. None of them ever appears on an invoice. They appear as waiting time in calendars, as cover nobody can provide, and as the initiative nobody raises after the third attempt.

About me

Portrait of Daniel Jurkovic — Daniel Jurkovic · Lübeck

I am a software developer from Lübeck. Over fifteen years I have worked on software projects for Bayer, Siemens, Telekom and NASA.

What I enjoy most is the moment when someone can suddenly do their own work instead of waiting for someone like me. Today I advise companies on where AI and automation actually change something in their processes, and I build it when that is wanted.

Where that comes from

I led a team of four developers: hired, reviewed code, onboarded. I introduced the tests and the review environment this product is still developed on today. That discipline is exactly what decides whether an AI-supported process holds up in daily operation or stays stuck in the demo.

My employer's clients came from chemicals, defence, telecommunications, industry and retail. Neither a production line nor a compliance catalogue nor a sales process surprises me. I still have to get up to speed, in your process.

The yardstick

What carries today comes in three states

The question is not whether an AI can do a task, but what happens when it gets it wrong.

Demos almost always succeed. The difference shows up in operation, when the result is allowed to be wrong and nobody is sitting next to it at seven in the morning. That is why I assess every proposal on three levels.

Carries: Runs in daily business without anyone watching. Errors are rare enough to absorb, or the system catches them itself.
Carries under supervision: Works reliably, but a person approves before the result reaches the outside. For many things that is the right design, and the saving remains, because checking is faster than creating.
Still a demo: Convincing in the demo and it does not survive daily use, usually because nobody can say how an error would be recognised.

The difference is rarely the model, it is the safeguards around it. You can turn this scale on any provider, including me.

How you know the result is correct

This is where most attempts fail right now. Not at the model and not at the wording of the instruction, but at the fact that nobody defined beforehand how a correct result differs from a plausible-looking wrong one. Four points decide which level a project falls into.

What may happen without asking

An assistant may read what the person may read. Anything that moves money, reaches customers or changes stock needs an approval that someone can actually check, because it shows in advance what is about to happen.

What it is checked against

Automated checks that close down at the expensive points instead of merely warning matter more than any prompting technique.

What ends up in the log

Who triggered what, with which data, with which result. Without a log, an incident cannot be reconstructed afterwards.

What happens when it goes wrong

Rollback, ownership, alerting. That should be settled before the first incident.

You can put these four questions to any provider without a technical background. The answer is either concrete or it evades.

What is changing right now

Three changes that dissolve this queue

None of this is science fiction and none of it runs by itself. Each change has its level and a condition.

Level · Carries under supervision

The department no longer waits for IT

AI assistants now operate software the way a person does. This is made possible by MCP, an open standard through which a program offers an assistant its functions as usable tools. The assistant works inside the real system instead of in a chat window next to it, under the same rules as a person.

What it means and what it takes

What that means for you

Whoever used to write a ticket and wait three weeks describes their intent and sees the result. The query for the campaign, the recurring report, the analysis across three systems: no longer a development task, but a question.

What it takes

The assistant may only do what the person may do in whose name it acts. Every writing action needs a log, and anything that moves money or reaches customers needs an approval.

Level · Carries — as long as someone reads and checks

Specialist knowledge becomes accessible

Access to a system used to depend on mastering its interface. Whoever knew the screens, shortcuts and special cases got to the answer. That barrier is falling, and the domain question counts again.

What it means and what it takes

What that means for you

Positions that existed mainly because someone could operate a complex system are relieved. The people there go back to their actual work. At the same time the risk disappears that a process stands or falls with a single person.

What it takes

Someone still has to be able to judge whether the answer is correct. The role shifts, it does not disappear. And those affected need to know early who will be responsible for what.

Level · Carries under supervision

Software takes weeks instead of months

Writing code is no longer the bottleneck. What used to be a six-month project now stands in weeks, and running rather than as a showpiece.

What it means and what it takes

What that means for you

Projects that used to fail on economics suddenly add up: the connection between two systems, the small tool for one department, replacing a spreadsheet that grew over years. That moves the line between „we live with it“ and „we solve it“.

What it takes

Proof that the result is correct. The bottleneck has moved from creation to verification.

The counter-test

I would not run an assistant unsupervised that decides for itself when a rule does not apply. Nor a process where nobody defined beforehand how a wrong result would be recognised.

Why your workflow decides this, not the technology

Which of the three levers falls into which level at your company is decided by your process, not by the technology: who approves, what an error costs, how clean the existing data is. That is why a survey comes first and not a tool selection.

My own operation

How I know the guardrails are the actual work

I can only judge what I have operated myself. That is why I keep my own infrastructure at the standard I would otherwise only recommend, and make the same mistakes on myself first.

And the mishap

The locks are not there out of caution. An agent once wiped a development database for me because nothing stopped it. Since then there is a rule that forbids destructive steps without my explicit consent, and a check that enforces it.

Way of working, delivery, operations

Way of working

For two years I have been building mostly agentically: I describe the required behaviour, the tools write most of it, I review, discard and take responsibility for every line. The effort sits in the guardrails: project-wide rules the tools must follow, a memory that carries across weeks, and locks where a mistake cannot be undone.

Delivery

The path from change to production runs without my involvement. Tests must pass, otherwise nothing goes live. Database changes run as a gate before startup: if one fails, the application does not start at all. For the build itself a server is created that lives about forty seconds and is then guaranteed to disappear.

Operations

I see an outage before anyone reports it: my own monitoring, my own alerting, dozens of services at two locations, not a single externally open port. I have also opened up a complete management system to assistants over MCP, including the uncomfortable question of what happens when the assistant gets it wrong.

How that looks in detail I would rather show you on screen in a conversation.

What follows from this

The real questions are not technical ones

Once a department can trigger results itself, the first question is not which tool to buy, but who may trigger what and who is answerable for it.

Who may trigger what — and what that means for IT

Who may trigger what, who approves, who carries responsibility, and how does someone notice in time that something is going wrong. No software answers these questions. They are decided or ignored, and then whoever tries something first decides them.

This also shifts what IT is for. It does not become superfluous. It becomes the place that provides access, permissions, logging and checks, instead of implementing every small domain request itself. For many IT departments that is relief, for some an insult.

Part of the return does not arise in the software at all. Some processes are simply cut differently. Some approval step exists only because nobody used to be able to trace what had happened. Where a log does that, the step can go. Those are management decisions, not development decisions.

The first format

The survey

In the building trades, a survey is what comes before the quote: someone measures up what is there and writes down what needs doing.

I look at your processes. Afterwards you have a prioritised list of levers, each with its level, with effort and return, and with what I advise against. One area is enough, it does not have to be the whole company.

The result is a basis for a decision, not a quote.

Two commitments for the survey, and only these two.

The survey is yours. You may have it implemented without me — your own team or any provider you choose can work from it.

For every lever on the list it states how you will recognise after implementation whether it held — and what to do if it did not.

After the survey you can stop. If you want to go further, I accompany the implementation, or I build it and operate it afterwards.

How a survey runs

01 · Listening
I have the processes explained to me by the people who carry them out every day, not only by management. Nobody technical needs to be present. I ask about frequency, participants and exceptions; the exceptions are almost always the real subject. Plus a look at the system landscape: what is there, what talks to what, what is bridged by hand.
02 · Assessing
Every lever found gets the same five entries: its level on the scale above, what the current state costs, roughly what an implementation requires, which guardrail it needs, and how you would recognise after implementation whether it held. What I cannot judge is on the list too. What does not hold up is cut.
03 · Handing over
You get the list prioritised, with a recommendation for the first two steps, in a form you can read out in a management meeting without translating it. To close, we go through it together once, in the order in which I would tackle it.

The list also says what I do not recommend: the process that happens too rarely. The place where a standard product fits better than something custom. The problem that is not software at all but an agreement between two departments. A lever that does not pay off does not belong on the list, not even when it would bring me work.

Accompanying — I stay with the implementation without doing it myself: concept, choice of tools and providers, guardrails, enabling your team, accepting the work of third parties.

Implementing — I build it myself and operate it afterwards. This is the exception, not the default.

That is why there is no service table here. Which continuation makes sense, and whether any does, follows from the survey. Most companies first need a solid list, and after that often someone other than me.

I deliberately name no prices here. Scope and effort arise from the concrete situation, and a price table would be guesswork.

Who is saying this

Why I trust myself with this judgement

A great deal is being written about AI and automation right now. The difference lies in whether someone has already been accountable for a system running in the morning. So no list of methods here, but the track record. It should answer one question: do I trust this person's judgement about my processes?

Specification: experience, scale, compliance

Experience: Fifteen years of enterprise software, seven of them with leadership responsibility.
Scale: Core API for more than 40 tenants. Interface for around 50,000 corporate users.
Responsibility: Five years alone on an order management system, including operations and support.
Compliance: Installations at US government organisations, hardened to official requirements.

Four pieces of work from those fifteen years, all done in employment.

A central system that stalled for the largest customers

Result: The timeouts on the largest customer data sets disappeared.

Starting point, intervention and transfer

Starting point

An enterprise application serving more than 40 tenants. With the largest data sets, requests ran into timeouts.

Intervention

A rebuild of the multi-tenant core API. The permission logic moved out of the application code into optimised database queries.

Transfer

Whether something holds at your actual data volume is a different question from whether it works. The same mistake in thinking happens today with AI demos. And the same root cause returns under AI access: who may see which data? If that is answered in application code instead of at the source, it survives no new kind of access, and an assistant is exactly that.

An interface for around 50,000 people in one corporation

Result: That interface became the basis of the client running today at eight or more Fortune 500 companies.

Starting point, intervention and transfer

Starting point

A corporate customer of my then employer needed its own interface for around 50,000 users: Bayer AG.

Intervention

I built that client on my own responsibility — the first of its kind in the product.

Transfer

Between a working solution and one that 50,000 people use daily lies a wide gap. The difference is rarely the technology. It lies in rollout, permissions, special cases and in who gets it explained. AI projects underestimate exactly that stretch today, which is why a single department is a perfectly normal starting point for me.

Software for organisations that make no exceptions

Result: The product ran in the data centres of US government organisations, NASA among them.

Starting point, intervention and transfer

Starting point

US government organisations, NASA among them, were to run the product themselves — to the requirements of a U.S. Air Force platform.

Intervention

I hardened those installations along that catalogue of requirements. Point by point.

Transfer

If data protection, a works council or a group policy have a say at your company, that does not trigger a discussion with me but a list. I work through it and write it into the assessment of a lever.

Five years the one system the business depended on

Result: For five years an order ran from intake to invoicing through one system. If something jammed in the morning, there was no second person.

Starting point, intervention and transfer

Starting point

A company sitting between artists, an international network of recording studios, staff in three to four countries and accounting. In between, 100 to 500 orders a month.

Intervention

I built the system connecting all of those parties on my own: requirements, implementation, operations and support in one pair of hands.

Transfer

For five years I carried what I had built myself, and saw how far the described process and the lived one can drift apart. Since then I ask differently in a survey and judge every proposal by how it feels in its third year of operation.

Objections

Four questions I would ask in your position

You show no client list. Why not?

Because I have none that belongs here. For fifteen years I built in employment; what came out of it is above, with scale and result. As a consultant I am looking for my first engagements right now. I could put a logo here or write „a client from industry“, and you could not verify it from outside. You can test me differently: describe a process you know well in our first conversation. Within twenty minutes you will notice whether I ask the right questions.

We do not want our data ending up in someone else's model.

A fair question, and it has different answers depending on the case. There are tasks a model can handle in-house. There are providers with contractually assured purpose limitation and processing in Europe. And there are processes in which the model never sees the protected data itself, but only calls the function that works with it. If your rule is that nothing leaves the house, that is a requirement and not a discussion. It then helps decide which levers make it onto the list at all.

We have an IT department. What do you want there?

Take nothing away from you. In most companies IT has long known what would be possible. It lacks the time to check it, and often a counterpart who discusses the domain side and the technical side in the same language. I come from outside, talk with them and not about them, and deliver an assessment that holds even when your IT implements it and not me. Your own people working through the list is the normal case and the best outcome.

And what if nothing worth mentioning comes out of it?

Then that is what the list says, and you have had your processes described from outside in an orderly way once. That is a result and not a failure, and it cost you a few meetings instead of a programme. I prefer that outcome to a recommendation that falls apart in month two. If the preliminary talk already shows that the effort does not pay off, I say so.

The first step

Tell me about the longest queue in your organisation

01 · Preliminary conversation
About forty minutes. You describe two or three workflows that jam; I ask about frequency, people involved and exceptions. At the end I tell you whether I see levers or not.
02 · Scoping
If we continue, we define which areas the survey covers and how long it takes. Before that, any number would be guesswork.
03 · Your decision
You carry on internally, you commission somebody, or we continue together. All three paths are provided for.

The shortest route: an email to daniel@jurkovic.io with two sentences about the workflow that costs you the most time.

If you prefer the phone, add a number and a time.