What are you still doing by hand?
We build the automation that takes it off your desk. And we’ll tell you when you don’t need AI to do it.
Most businesses have work that eats hours and produces nothing. Chasing people for replies. Retyping the same data from one system into another. Following up, again. Usually there are two ways out: hire someone to do it, or buy an expensive system that handles part of the problem and then charges you extra for the module that handles the rest.
There’s a third. That’s what we do.
Too small to interest the enterprise vendors. Too big to keep running on spreadsheets and someone’s memory.
What we build
Six shapes of problem. Most businesses have at least two.
01Paper that has to be read by a person
Invoices, packing lists, statements, quotes. Someone opens the file, reads it, and types what it says into something else. We build the step that reads it instead, in two languages at once where that is what you have. It keeps a link from every value back to the exact place on the page it came from, so a disagreement gets settled in seconds instead of argued about.
02Phone calls that have to become records
A call comes in, and what happens next depends on someone hearing it correctly and writing it down fast. We build systems that turn the live call into a structured job while it is still happening. A person still makes the final call. The typing is what goes away.
03Reconciliation and classification nobody wants to do
Matching lines to accounts, transactions to categories, deliveries to orders. The work is easy and endless, which is exactly why it gets deferred. We build it to run automatically, with an audit trail for every decision. The part that matters is that it declines to guess. Anything it isn’t sure about goes to a queue for a person instead of being answered confidently and wrongly.
04Systems that don’t talk to each other
Some of the most useful work we do is the least glamorous: getting data out of one system and into another where it can actually be used. A real client build. A SaaS product with no API, and a customer who needed their own data out of it.
05Follow-up that never happens
Every business runs on promises made in conversation and then lost. You said you’d send the quote. They said they’d get back to you. Nobody is tracking either. We build systems that notice the open loop, keep count of how long it has been open, and draft the chase. A human reads it and sends it.
06Prediction over operational data at scale
When there is enough history, the question stops being “what happened” and becomes “where should we be tomorrow.” Routing, timing, where to send the truck, which account to work first. This is the one that needs real volume to be worth doing, and we’ll say so if you don’t have it yet.
How we work
Three steps. You can stop after any of them.
We go through the work your people actually do by hand, cost it, and rank it by what it would be worth to stop doing. You get the map whether or not you build anything with us. Several people have taken it and done the work themselves, which is a fine outcome.
Handover is part of the build, not a phase we sell you afterwards: the repository, the deployment, the documentation, and a walk through it with whoever will be looking after it.
We keep it running, watch what it costs, and change it when your process changes. Some clients want the opposite arrangement. We run engineering for a product their own team is building. We do that too.
Proof, since we can’t show you a logo wall
Client work is confidential and stays that way. Yours will be too. So here is a system we built for ourselves, running every day, described honestly.
chaser does work nobody should be doing
It reads our own mail. It works out what we asked people for and what people asked of us, matches the replies that come back, decides which loops are still open, and writes the follow-up.
We didn’t build this to sell it. We built it because we needed it, which is the same reason you’d hire us.
It drafts. It does not send. Auto-send is off by default and stays off unless someone turns it on.
Ask it why it did something and it prints the reasoning, step by step, for that specific decision.
It is scored against a set of known-correct examples. When it stops being right, we find out before you do.
Where this work has been done
Energy. Auto lending. Logistics and field service. Wholesale import and distribution. Retail operations. Accounting. The creator economy. Education procurement. Platform infrastructure.
Two decades of this work inside other people’s operations, under other people’s contracts, before we started building it for the mid-market.
We run it, not just build it
We run our own production infrastructure. It is a multi-node, self-hosted platform with single sign-on, TLS everywhere, centralized observability, automated backups and a build-and-deploy pipeline we wrote ourselves. Client applications ship onto it through the same pipeline. Every architectural decision is written down, every incident gets a root-cause writeup.
Who you’re hiring
Amin Elnaggar
Founder. Building automation systems for nearly two decades.
Dallas–Fort Worth, Texas.
You work with the person who writes the code. No bench, no handoff. Nobody junior is learning the job on your project.
That is a limit as well as a promise. We take on few engagements at a time, and we will tell you when something isn’t worth starting.
Speaking
Virtual Employees: Automating the Work Nobody Should Be Doing
ITKAN Rabta, Plano, Texas. 20 September 2026, free and open to the community. form.jotform.com/262429013945054
Private LLMs: Use AI Without Giving Away Your Data
June 2026.
From Idea to Reality
June 2026. Live-built a working application with the room; it shipped.
He doesn’t bring slides. He brings something built.
How engagements run
The fear with a firm like ours is the open-ended bill. Here is how we answer it.
- Fixed scope. Fixed fee. Agreed before we start.
- You keep the map either way.
- You own the code. No lock-in, no seat licence, no module we sell you later.
- We don’t do six-month discovery.
- We don’t bill by the seat.
- If we can’t finish a build inside the quoted scope, we don’t start it.
Pricing depends on what the audit finds, and we’d rather quote a real scope than a range that means nothing. Ask us and you’ll get a number in the conversation.
The ones people actually ask.
Who owns the code?
You do. All of it, down to the parts it would suit us to keep. The deployment scripts, the prompts, the test set, the documentation we wrote for ourselves. It lands in a repository you control, and if you never speak to us again it still runs.
What if the person building this gets hit by a bus?
Reasonable question, and the honest answer is that at a studio this size it is a live risk. We manage it the only way that works. You hold the code and the credentials from the first week. The decisions are written down in plain English inside your repository, and nothing sits behind a login only we have. The test we build against is whether an engineer who has never met us could pick it up cold.
What if the model changes, or gets more expensive?
We assume it will. Model access sits behind one interface, so moving providers is a configuration change. Every step that involves judgement has a scored test set, so when the model underneath changes you can see whether the quality moved before you ship it. And the cheapest protection is the one two questions down: the less of your system that depends on a model at all, the less of it is exposed to somebody else’s price list.
Why not just hire a contractor?
Sometimes you should. If you already know exactly what you want built and can write the spec, a good contractor will do it for less than we will. What contractors are usually not set up to do is the part before the spec. Working out which of your manual work is worth automating, in what order, and which of it shouldn’t be software at all. The other difference is management: hire a contractor and you have hired a person to supervise.
How do I know it’s actually working?
Because it’s measured. Anything with judgement in it gets scored against known-correct examples on every change, so “is it still right?” has a number instead of a shrug. The systems show their working. Pick any decision it made and ask why. And where confidence is low the design answer is to stop and hand it to a person, which is the behaviour you want and almost nobody builds.
What if we don’t need AI?
A good part of this shouldn’t involve a model at all.
Then we’ll say so, and it happens more than you would expect. Plenty of what arrives described as an AI problem is a scheduling problem, a data-entry problem, or two systems that were never introduced to each other. Those are cheaper to fix and they fail in ways you can predict. They also cost nothing per run. We would rather build the dull version that works than the impressive one somebody has to supervise.
How fast?
An audit runs one to two weeks. A build is usually four to eight, and the audit is what tells you which. We don’t do six-month discovery. If the first useful thing is more than a couple of months away, the scope is wrong and cutting it beats stretching the calendar.
What’s off the table?
We don’t rebuild your ERP. We don’t take on work where nobody on your side owns the process being automated, because those builds ship and then quietly stop being used. We don’t sell licences to software you can’t take with you. And we don’t take an engagement we think you’d be better off not doing. It’s a small enough business that one unhappy client is expensive.
Tell us what’s eating the hours.
A short call, and we’ll tell you whether there’s anything here worth doing. If there isn’t, that’s a useful answer too.
Central time. We answer our own mail.