Free proof of concept
You don't need to know which process to automate, or whether automating it is even possible. We find the one task worth attacking on a 30-minute call, spend two developer-days building it for real on your own files, then show you it running and tell you what it saves. If it isn't worth automating, we say so.
What you get
Not a slide deck, and not a demo built on somebody else's tidy sample files. We build the hard part of your process for real, running on files you send us, and mock only the scaffolding around it.
We walk you through it on a screen-shared call, so you can watch it handle your own awkward cases — the crooked scan, the supplier who formats everything differently, the exception nobody ever documented.
What we found in your systems and what they can talk to, how many hours a week the process costs you today, and a rough range for building it properly. You get it before the call, so you can read it first.
Timeline
We walk through your week and find the one task worth attacking. Nothing to prepare, no files to dig out first, and you don't need to know which process it is — working that out is the part most owners can't do alone, and it's the part we're good at. No pitch on this call.
You send one real data sample — that is the only thing we need from you before we start. We build the part the whole idea hinges on — the part most likely to fail — and mock the screens, logins, and tidy edges around it. You end up with proof of the part you actually doubt, not the parts you already believe.
The one-pager lands in your inbox first — what we found in your systems, what the process is costing you per week, and a range for building it properly — so you can read it before we talk. Then we get on a call and show the thing running. We don't turn that range into a fixed price yet: quoting a number before you have used the thing is how scope creep starts.
We host the prototype for 30 days so your team can use it and show it around internally. Once you have had it in your hands and we both know what you actually want built, we turn the range into a fixed price. After that the prototype goes dark unless we move on to a build — but the source code is yours permanently, and any developer can pick it up and host it.
The worst case
Sometimes the honest answer is that a process isn't worth automating — the volume is too low, the payback is too thin, or the process is about to change anyway. When that happens we tell you, and we show you the code we wrote finding out.
That outcome costs you one 30-minute call and a folder of files you already have. The expensive way to learn the same thing is six months into a paid build.
Why we give it away
This isn't a loss leader we hope you'll feel guilty about. Two developer-days is genuinely what it costs us, and we spend it for what it buys on our side: once we've seen your real data and your real systems, we can commit to a fixed price and a fixed deadline instead of padding an estimate to cover everything we don't know yet.
Scope
What comes next
Once you have used the prototype and we both know what you actually want built, the range in the report becomes a fixed price. The proof of concept and what we learned about your systems are the specification — which is exactly why we can commit to one number and a fixed deadline rather than an hourly estimate. Most clients keep going from there, and every one of our case studies started this way.
The prototype becomes a real product, quoted as one number before we start.
New features for your live product, each scoped and priced individually before we build.
A developer allocated to your project every month: support, maintenance, and continuous development.
FAQ
No catch — the scope is capped, not the quality. One process, one data sample, two developer-days of build after a 30-minute call. We do it because a working prototype is the best specification money can't buy, and because it is how we can quote fixed prices later. You keep the code whether or not we ever work together.
No — that's our job, and it's the part most owners can't do alone. You know something is slow; you usually don't know whether it's worth fixing. On the call we walk through your week and find it. Turning up with nothing but a vague sense that too much time goes into admin is a perfectly normal starting point.
It rarely is, because we never try to build the whole thing. We pick the one part the whole idea hinges on, build that for real, and mock everything around it — the screens, the logins, the tidy edges. If the worry is whether AI can read your supplier's crooked scans, that's what gets built properly; the rest is scaffolding so you can see it in context. You end up proving the part you actually doubt instead of the parts you already believe.
We host it for you for 30 days so your team can actually use it and show it around. After that it goes dark unless we move on to a build — but the source code is yours permanently either way, and any developer can pick it up and host it.
Your data is processed in the EU and handled GDPR-compliantly by default. When we use AI on your documents, the models see only the data needed for the task, your documents are never used to train anyone's models, and nothing is retained beyond your project. We put all of this in writing before you send us anything.
They're two different services, not two sizes of the same one. The proof of concept goes deep on a single process: on the call we find the most painful task in your week, then build it for real so you can see whether it actually works. The software audit goes wide: we walk through every process in your company and hand you a report that ranks them by payback — what to automate, what an off-the-shelf tool already solves, what is worth building, and what to leave alone. Neither one asks you to know where the problem is beforehand. Take the proof of concept if you want proof that one thing can be done; take the audit if you want the map of everything.
We'll find the one task worth attacking, build it, and tell you what it is worth — or tell you it isn't worth building. Either way, you keep the code.
azurevibesWe remove manual work from your back office — internal apps, system integrations, and AI document processing for SMBs.