About
An independent AI implementation partner that builds what it recommends
We're the engineering team owner-managed firms bring in to step out of the loops that still run through them. We build on the tools you already pay for, and the business owns the result.
Our story
Built for the work that waits for the owner
Most firms we speak to don't lack software or AI. They lack the joins between them, so the enquiry, the invoice, the "how are we doing?" and the record all route back to one person. That's where the owner's week goes, and a chatbot on its own doesn't give it back.
So we work as engineers, not advisers who hand over a deck. We map one loop, decide what should be a rule, what AI should do and what a person must approve, then build it, test it against the messy cases and hand it over. We work with owner-managed firms in the UK and Romania, in English and Romanian.
By the numbers
Every project documented, every claim checkable
delivered projects documented as case studies
solution blueprints, labelled as such
markets served, the UK and Romania, in English and Romanian
Principles
Six rules we work by
They shape every proposal, and they're the reason we sometimes recommend building nothing.
Rules, AI, people
Rules for what must be exact, AI for reading and judgement, a person for anything expensive to get wrong.Ship in weeks
The first paid build ends with a loop running in production, not a report about one.The business owns it
Code, prompts, data and accounts are handed over in writing, so the system belongs to the company.Return before novelty
A loop earns automation when the time or risk it removes is clear, not because a new model shipped.Handed over, documented
Your team gets the runbook, the access and the criteria for expanding, so the system doesn't depend on us, or on you.We say no
If a standard tool, a setting you haven't switched on or the AI seat you already pay for solves it, that's what we'll recommend.
How we work
Method
The same six steps in every project, what we build, the evidence rules we hold ourselves to, and when we say no.
Our method starts with the operational workflow, not a tool or an AI model. It separates repeatable steps from interpretation work, keeps consequential decisions with people, and defines failure states, ownership and recovery before launch. The result is a system the operating team can understand, check and own, not an isolated demonstration.
1. Map the current workflow
We document inputs, people, source systems, state changes, decisions, waiting time, exceptions and the accepted outcome. The output is a map precise enough for the team to correct misunderstandings before anything is built.
2. Draw responsibility boundaries
Every activity gets one type of owner:
- Deterministic rule
- Bounded AI
- Human decision
Data and permissions are reviewed before any AI model gets access. The system of record for each field stays explicit.
3. Design the system and its exceptions
For every consequential step we answer: what validates the input, who owns the state, what happens on a duplicate, delay or outage, what the AI may and may not do, where the workflow pauses for review, and how an operator corrects or resumes the case.
4. Build a narrow first release
Implementation begins with one valuable, repeatable path. Integrations, rules and interface are built together, so the team never receives an invisible automation without a place to control it. A prototype can test the interaction, but it is not production until security, failure states, monitoring and operating responsibilities are defined.
5. Test real scenarios
Testing covers the normal path, missing inputs, duplicates, slow responses, unavailable integrations, uncertain AI output, corrections and retries. For AI steps, representative examples check both output quality and behaviour outside known cases.
6. Release with control and hand over
Rollout can be limited to one group, request type or service line. Alerts, exceptions, accounts, infrastructure, data and later changes each get an owner. Handover includes documentation, access, recovery procedures, known limitations and the criteria for expanding the system.
Who owns each type of step: the full table
Swipe or scroll to compare the columns.
| Type | Examples | Required control |
|---|---|---|
| Deterministic rule | validation, deduplication, routing, synchronisation, calculations | tests, idempotency, logs and retries |
| Bounded AI | extraction, classification, summarisation, research, drafting | approved sources, thresholds, evaluation examples and authority limits |
| Human decision | exceptions, approvals, important messages, commercial changes | visible context, a named owner and a deadline |
What we build
We build four kinds of thing, usually in combination.
Integrations and automations between the tools a firm already pays for: CRM, inbox, calendar, accounts and job software. PaxBespoke's sales flow joins seven tools through n8n, from consultation booking to deposit invoice, with no generative AI at all because every step follows written rules.
Bounded AI agents for messages and documents, with written limits and a person on the hard cases. The WhatsApp order agent we built for a wall-art business answers routine order questions and hands complex chats to staff with the history intact.
Bespoke operational software where no tool fits: a custom CRM, an agent workspace, a records app. AngajatAI's workspace and the WhatsApp order CRM are examples, and DANOVA NEXT is a public, accessible web app we built for an Interreg Danube Region project.
Connections that let the AI seat a firm already pays for answer questions from its own systems, instead of selling it another seat. saved.md, a publishing product we built, connects to AI assistants such as Claude and ChatGPT through MCP, an open standard for connecting AI tools to other software.
When we say no
We turn work down, or recommend something smaller, when:
- You want an AI to act on anything consequential with no human check.
- A standard tool, a setting you haven't switched on, or a clearer process would do the job.
- Nobody will own the process after launch.
- The data can't lawfully be used for the purpose.
- The process changes every week.
- You want us to promise a sale price or a multiple.
- The system we'd need to connect has no usable API or export, and a workaround would be fragile.
When we recommend building
A workflow is a strong candidate when it has meaningful volume or coordination cost, identifiable rules and exceptions, an active owner, accessible data and an outcome that can be checked. If the problem is rare, unstable or safely solved through configuration, we recommend not building custom software.
Evidence and claims
A solution blueprint shows how a system could be built; it does not prove a client outcome. A claim about savings, speed, accuracy or revenue is published only when its definition, period, source, client approval and limits are recorded. Today our case studies document what was built; none publishes an outcome metric yet. Third-party figures carry their source and are never shown as our results.
Credentials
EU project delivery
We developed the accessible web application for DANOVA NEXT, an Interreg Danube Region project co-funded by the European Union, and coordinated the technical work with partner teams.
See our EU project work
Partnerships
Your clients ask for software. We can build it with you.
Agencies bring us in when a client needs automation, AI agents or an internal app they'd rather not deliver alone. Some expert firms have a method their clients keep asking to buy, such as an assessment, a model or a way of running a job; if you have no engineering team, we can build that product with you. We agree the model, roles and client contact in writing first.
No standard commission or revenue share is promised here; any terms are negotiated and signed per project.
Talk about a partnershipReferral
You make the introduction. We run discovery, proposal and delivery if every party agrees.
Delivery partner
You keep the client relationship. We deliver a defined technical scope, co-branded only with written approval.
White-label delivery
We work under your brand, only when identity, contact and support are agreed explicitly.
Building your method into a product
A fixed-fee diagnostic and prototype, then a fixed-scope build and support. You keep your content, brand and client data.
How collaborations are agreed
Some expert firms have a method their clients keep asking to buy: an assessment, a model or a way of running a job. If the firm has no engineering team, AutomateFlow can build that method into a software product with it, starting with a fixed-fee diagnostic and prototype.
Collaboration models
The model is chosen before any proposal, because it decides who speaks with the client, who delivers and who supports the system.
- Referral. The partner makes an agreed introduction and AutomateFlow handles discovery, proposal and delivery if every party accepts that path. A referral does not by itself transfer the client relationship, exclusivity or any right to payment.
- Delivery partner. The partner keeps the client relationship and AutomateFlow delivers a defined technical scope, such as an integration, an automation, an AI agent or an operational app. The work is co-branded only with written approval of logos, screenshots, client names or any case study.
- White-label delivery. AutomateFlow works behind the partner's brand only when identity, client contact, documentation, support and permitted use are agreed explicitly.
- Building a method into a product. For a firm whose clients ask to buy its method, AutomateFlow runs a fixed-fee diagnostic and prototype, then a fixed-scope build and support. The firm keeps its content, brand and client data.
What has to be agreed
Before work starts, the parties agree who owns the commercial relationship, who approves scope and accepts deliverables, how access and client data are handled, who supports the system after launch, and how proof such as names, quotes or metrics may be used. Compensation, commissions and revenue sharing are not public promises; they exist only when negotiated and signed for a specific project.
This section describes possible collaboration paths. It does not announce existing partners, shared clients, revenue or results.
To discuss a collaboration, book a discovery call with a short summary of the client type, the workflow, the role you want to keep and the model you have in mind. Do not send client data, credentials or internal documents.
Company
Who you're contracting with
Brand
AutomateFlow
Website: www.automate-flow.co.uk
Delivery
Remote, from Romania
UK projects run on a written scope, acceptance and handover.
Scope, price and acceptance criteria are agreed in writing before any work starts.
