01
Automation Systems
The job that comes back every week, handed to something that does it the same way every time, whether anyone remembered or not.
2–5 weeksFixed scope
The engineers whobuild efficiencyfor you.
Every workflow mapped before we touch it. Every plan agreed in writing before we begin. AI and non-AI automation, built around how your business already runs.
Scoped in writing before anything is builtRules first, AI only where it earns itWatched after launch
24/7Runs without being asked
Scroll to look around
Automation systemsAI where it earns its placeCustom internal softwareSystems that talk to each otherMonitored after launchScoped in writing firstNo vendor lock-inBuilt around how you already workIT, when it is in the way
How JD Works runs
0%Scoped in writingNothing gets built before what it does is agreed on paper.
0/7Runs unattendedThe work happens whether anyone remembered to start it or not.
0Person accountableYou deal with whoever built it. No account layer in between.
0Vendor lock-inWhat gets built is yours, documented, and portable out.
What we do
Six things, done properly.
We are deliberately not a shop that does everything. What sits in the path of repetitive work, we do a great deal of. For anything that doesn’t, we will point you at someone who does.
02
AI Where It Earns Its Place
Used for the judgement calls a rule cannot make, and kept well away from the parts that were never broken.
2–6 weeksFixed scope
03
Custom Software
Internal tools shaped around how the work is actually done, instead of the work being reshaped around a subscription.
4–10 weeksFixed scope
04
Systems That Talk
The quiet plumbing between the tools you already pay for, so the same information stops being typed in twice.
1–4 weeksFixed scope
05
Maintenance & Monitoring
Shipping is not the end of the job. Things get watched, and problems get found here before they get found there.
OngoingMonthly
06
IT, When It Is In The Way
Not a helpdesk. The general technical problems that sit between a business and getting on with its day.
As neededHourly
The difference
Read the fine print. We’ll wait.
Most of what separates one build from another never makes it onto the website. Here is ours, in the plainest language we can manage.
| Criterion | JD Works | Typical agency |
|---|---|---|
| Scope | Agreed in writing before a line is written | Discovery phase billed before you know the shape |
| Who builds it | The person you spoke to is the person building it | Sold by one team, passed to another, staffed by a third |
| Ownership | Source, docs, and infrastructure in your name | Runs on their platform, priced per seat, forever |
| After launch | Stabilisation window included, then watched | Support ticket queue, billed by the hour |
| AI | Only where a rule genuinely cannot do the job | On the proposal because it is on every proposal |
| Saying no | Told plainly when automating it is not worth it | Scoped anyway, because it is billable either way |
Fig. 04 · On the benchDrawn, not photographed
“I have told people not to automate something more than once. It costs a project and it keeps the relationship.”
Plenty of processes are not worth automating, and some are about to change so much that building now would be waste. Saying so out loud is the whole basis of this working. Nobody here is paid on what they can talk you into.
01
Map it before touching it
The process gets written down in full, branches, exceptions and the workaround nobody mentions, before anything is built. Most of the cost of automation is discovered here, not in the code.
02
Agree it in writing first
What gets built, what it will not do, and what counts as finished, on paper before it exists. If the shape changes mid-build, we stop and re-agree rather than quietly absorbing it.
03
Rules before models
Deterministic work stays deterministic, because it is cheaper, faster, and it does not surprise you. AI goes in where judgement is genuinely needed, with a fallback and a human check on anything that matters.
04
Tell you when not to
Some processes are not worth automating, and some are about to change so much that building now would be waste. Saying so costs a project and keeps the relationship, which is the better trade.
Where it starts
How it usually begins.
4 situations described almost word for word in first conversations. These are written as illustrations of the problem, not quoted from clients.
Every enquiry came into one inbox and got answered by whoever saw it first. The ones that came in on a Friday afternoon often did not get answered at all, and nobody could tell me how many that was.
Representative situation
01 / 04
Common questions
Answered plainly.
Still not sure?The first conversation is about whether any of this is worth doing at all. If the honest answer is no, that is the answer you get, and it costs you nothing to find out.Start a conversation
It depends on what it has to do and how much has to be true before it can run. A narrow job touching one system is a different piece of work to one that has to hold up across a whole process. You get a straight answer on timing in the planning conversation, before you commit to anything, rather than a number pulled off a website.
It depends on the work, and anyone who gives you a figure before understanding it is guessing. The cost comes out of the plan once the plan is real, and it is agreed in writing before anything is built. If what you want built is not worth what it would take to build it, you will be told that instead.
No. You need to be able to describe what eats your time now and what you would rather happen instead. The rest is the job. You will get plain-language documentation at the end, written for whoever runs the business rather than for another developer.
There is a stabilisation window straight after launch where anything that surfaces gets fixed quickly. That is planned for, not an admission that something went wrong. After that, ongoing upkeep means monitoring usually catches problems on this side before they reach you.
No, and most of it is deliberately not AI at all. Rules are cheaper, faster, and they behave the same way every time, so deterministic work stays deterministic. A model goes in where the input genuinely varies and judgement is needed, with a defined fallback, a log of what it decided, and a person approving anything that leaves the building.
All of it. Source, documentation, and infrastructure in your name, with access handed over as standard. Nothing runs on a platform you have to keep renting, and there is no per-seat charge on a tool you paid to have built. If you want to hand it to another developer later, it is documented well enough for that to be straightforward.
Let’s find the first one.
The first conversation is about one process: what it costs you now, what it would take to hand it over, and whether that trade is worth making. You leave with a map either way.
Where
Remote · in the systems you already run
The shape of it
Scope · One conversationPlan · Agreed in writingBuild · Tested before liveAfter · Maintained
Before anything is built
Scoped in writing before anything is builtTested against real cases before it goes liveWatched after launch, not handed over and forgotten