Skip to content

A working prototype in weeks, wired into what you already run.

n8n, Make, Power Automate or Zapier for the wiring. Claude, Azure OpenAI or open-weight models for the reasoning. Guardrails from week one, real systems from day one. If the prototype earns its keep, it hardens into production; if it does not, you learn that for the price of a spike.

-45%
L1 ticket volume after one workflow
14h → 12s
MTTR on standard access requests
4
Orchestrators we wire into, yours first
EU / on-prem
Residency options down to Ollama

The first two figures are founder casework: a Jira Service Management + n8n build at a regulated Maltese operator (~100 staff). The full story, including the part where developers tried to hack it, is in the field notes below.

The problem

Everyone has an AI strategy. Few have a working flow.

The gap between the board deck and the daily workflow is where AI initiatives go to stall. Prototyping fast, inside the real stack, is how the gap closes.

Pilot purgatory

The AI initiative has been "in evaluation" for six months. Slides exist, a sandbox exists, a committee exists. A thing an employee can actually use on a Tuesday does not.

Tool-first shopping

A platform got bought before the use case was found. Now the licence renewal is coming up and the strongest argument for it is sunk cost.

Every choice feels irreversible

Which model, which vendor, which framework: teams freeze because each decision looks like a marriage. So the decision defaults to nothing, and the backlog keeps growing.

The mechanism

We plug in where you are. All of it swaps.

Every prototype is the same fabric: your systems on one side, outcomes on the other, and a core of orchestration, guardrails and a model in between. Pick a scenario and watch how the same pattern lands in three different stacks.

Loading the interactive console

Illustrative wiring. Real prototypes are scoped to one use case, one system and one measurable outcome, then judged on the numbers.

The automation rule

A senior engineer at €80k/year isn't a password-reset queue. Automation is.
- Michal Jatczak, founder · ITSailor
Field notes

The workflow that replaced half an L1 queue.

Before ITSailor, the founder ran this build at a regulated Maltese operator (~100 staff): an IT team drowning in Jira backlog, where a "give me access to folder X" ticket sat for three days waiting on three approval signatures.

Case: Jira Service Management + n8n

The build. Jira Service Management wired to n8n through webhooks and internal system APIs: a self-serve bot that grants simple permissions the moment a manager approves in Slack or Teams. The engineers went back to engineering.

-45%
L1 ticket volume
14h → 12s
MTTR for standard access requests

The part that went wrong

During testing, developers tried to game the bot by injecting malicious JQL payloads to grant themselves admin in production. The flows were rewritten with hard RBAC limits, and injection testing has been part of every build since.

What that attack changed

Guardrails go in during week one, while the prototype is still small enough to reason about. Permission boundaries, injection-hardening and the human approval step are part of the first wiring, because your own users will probe the system long before an outsider does.

From prototype to product

This practice built our own products. DECKLOG's retrieval core started as a zero-dependency local prototype on Ollama before graduating to hybrid retrieval on pgvector, and HOIST grew out of exactly the ticket-triage pattern shown above.

What a spike hands you

Two weeks in, you hold six artefacts.

All of it lives in your repository and your tenant, whichever way the go/no-go memo lands.

Feasibility verdict

The use case scored against GDPR Art. 22 and the EU AI Act risk classes before anything is built. Some ideas should stay ideas; we say which and why.

A working prototype in your tenant

Wired to real systems through n8n, Make, Power Automate or Zapier. Real tickets, real documents, real approvals, from the first week.

Prompt + tool pack, version-controlled

Prompts, tool definitions and system messages live in your repository, injection-hardened and reviewed like any other code.

Golden-question eval set

A regression harness of real cases with expected outcomes. Model swaps and prompt changes get tested against it, in CI, before they ship.

Cost model per outcome

What a resolved ticket, a processed invoice or a drafted follow-up actually costs in tokens and euros, measured on the prototype, projected to production volume.

Go / no-go memo

An honest verdict with the hardening plan if yes, and the documented reasons if no. Either way the eval set and the findings stay yours.

Productized engagements

Spike, integrate, then keep it healthy.

Fixed fee or retainer, agreed before work starts. No hourly billing at any tier.

AI Feasibility Spike

Two weeks. One use case. A working answer.

Scoped to youFixed fee · 2 weeks
  • Use-case scoping with GDPR Art. 22 + AI Act risk check
  • Prototype wired to one real system (ticketing, mailbox, CRM)
  • Model and orchestrator picked from what you already run
  • Golden-question eval set seeded from your real cases
  • Go / no-go memo with cost-per-outcome numbers

Outcome

You know if it works, what it costs and what breaks, for the price of a spike.

Scope the spike
Most popular

Production Integration

The prototype that earned its keep, hardened for daily use.

Scoped to youFixed scope · 4-6 weeks
  • Abstraction layer: model and vendor become configuration
  • Injection-hardening, rate limits and permission boundaries
  • Eval harness wired into CI: regressions fail the build
  • Langfuse observability, self-hosted: traces, costs, latency
  • Runbooks and Exit Kit in your repository

Outcome

AI in the daily workflow with the same discipline as the rest of your stack.

Scope the integration

Platform Retainer

We keep the AI layer healthy while your team uses it.

Scoped to youMonthly retainer · 6 months min.
  • Monthly eval runs with drift and quality reporting
  • Model swaps and price renegotiations as the market moves
  • Cost watch: per-outcome economics reviewed monthly
  • New use cases spiked against the existing fabric
  • Single Slack channel to the engineer who built it

Outcome

The AI layer keeps earning its keep as models, prices and your team change.

Talk about the retainer
The toolbox

What we actually build with.

Picked per engagement, starting from what you already pay for. Nothing here is exotic, and nothing here is mandatory.

n8n (self-hosted)

Default wiring when nothing is set: runs in your infrastructure, no per-task tax.

Make

Visual scenarios for SaaS-heavy teams that want to see the flow.

Power Automate

The native choice inside a Microsoft 365 tenant. No new platform to buy.

Zapier

Fastest wiring for simple SaaS-to-SaaS handoffs.

Anthropic Claude

Strong reasoning and tool use; the default for agent-shaped work.

Azure OpenAI (EU)

GPT-class models with EU data residency and tenant-level controls.

OpenAI

API-tier access where the workload and data classification allow it.

Open-weight via Ollama

Local and self-hosted models when the data must not leave the building.

Langfuse (self-hosted)

Traces, evals, token costs: the observability layer under every build.

pgvector / Qdrant

In-tenant vector stores when the prototype needs retrieval.

The rules we build under

Fast does not get to mean careless.

Prototypes move quickly because the compliance questions are answered before the build, in the feasibility verdict, where changing the answer is still cheap.

GDPRArt. 22

Decisions with legal or similarly significant effect keep a human in the loop. The approval step is designed in, and it is not removable by prompt.

EU AI ActRisk classes

Every use case is classified before the build. High-risk shapes get flagged in the feasibility verdict, with the obligations spelled out.

Data residencyEU / on-prem

Azure OpenAI EU endpoints, EU-hosted orchestration or fully self-hosted open-weight models. The data classification decides, and the fabric supports all three.

FAQ

Honest answers to the questions buyers actually ask.

Do we have to adopt a new automation platform for this?

+

No. The prototype goes into whatever you already run: Power Automate inside a Microsoft tenant, Make or Zapier for SaaS-heavy teams, self-hosted n8n when nothing is set or when per-task pricing stings. The orchestrator is a delivery detail, and the abstraction layer means it can change later.

Can this run EU-only, or fully on-prem?

+

Yes. Azure OpenAI EU endpoints cover most regulated cases; fully self-hosted open-weight models via Ollama cover the rest. Our own DECKLOG retrieval core started as a local Ollama prototype, so the on-prem path is one we actually use, in our own product work.

What happens if the prototype shows the idea does not work?

+

Then the spike did its job. You get the go/no-go memo with the documented reasons, the eval set, and the cost numbers, and you did not spend a platform budget finding out. A spike that can only ever say yes is a sales demo.

How do you handle GDPR Article 22 and the AI Act?

+

Feasibility scoring includes the AI Act risk classification and a GDPR Art. 22 check before anything is built. Where a decision has legal or similarly significant effect, a human approval step is part of the architecture, and DPIA support is available when your DPO needs it.

Who owns the prompts, flows and evals afterwards?

+

You do. Everything lives in your repository and your tenant: prompts, tool definitions, workflow exports, the eval set, the runbooks. The Exit Kit documents it well enough that another vendor could take over in 24 hours. That is the Sovereign Mastery rule.

Who actually does the work?

+

One senior engineer, the same one you meet on the discovery call. No account managers, no offshore hand-off, no junior rotation. You get a single Slack channel and a direct line to the person writing the prompts and the flows.

Put one use case in front of real users instead of another evaluation.

The workshop picks the case with the shortest path to a measurable result, and names the data, the owner and the kill criterion before any code is written.