Regulated filing and reporting
VAT submissions, e-invoicing under KSeF or the EU mandates, statutory returns. If the job reported success and the filing never landed, nobody finds out until the penalty does.
Unattended systems
Most broken systems still report healthy.
Somewhere in your business a scheduled job, a filing submission or a data pipeline is reporting success and doing nothing. Your monitoring won't tell you, because it watches for errors, and a process that never starts doesn't produce one.
Built by a technical founder with 25 years in .NET and Azure, around 10 of them leading the teams that build these systems.
Five days, fixed fee. You get a written findings document.
If everything is running, that's what the report will say.
scheduler · last nighthealthy
03:04VATmtd-vat-submit · completed
02:41KSEFinvoice-batch-pl · completed
02:15PURGEretention-purge-nightly · completed
01:52ERASEgdpr-erasure-queue · completed
01:30EXPORTaudit-log-export · completed
01:07FILINGct600-accrual-sync · completed
Expected-output check
0 records deleted
41 nights. Every one reported success.
Processes I check:
- Scheduled jobs
- Filing submissions
- Data pipelines
- Integrations and webhooks
- Retention and erasure
- Automated reporting
Who this is for
Businesses where a process that quietly stops is a problem with a price tag.
Data obligations that run on a schedule
Retention and erasure jobs, access-request pipelines, audit logging. The classic failure: the deletion job runs green every night and deletes nothing.
Estates that have outgrown their design
Ten years of .NET and Azure, several generations of integration, and nobody left who can say with confidence what still runs and what only appears to.
Why nobody catches it
The failure doesn't announce itself.
Monitoring watches for errors. A job that never starts doesn't produce one.
Every alerting stack in the world is built the same way: something goes wrong, it throws, you get paged. That catches the loud failures. It is structurally blind to the quiet one, where the process simply doesn't run, doesn't throw, and doesn't appear anywhere as a problem.
So the dashboard stays green. The status page stays green. The only signal is a number further downstream that looks slightly wrong, months later, and by then nobody connects it back.
Failure mode 01
Green means 'no errors', not 'it worked'
Absence of an error is not evidence of execution. Those are different measurements, and almost nobody takes the second one.
Failure mode 02
Nothing checks the output exists
A pipeline can complete cleanly and produce an empty file. Unless something asserts the output is there and plausible, that passes.
Failure mode 03
The seam is where it hides
This is rarely one broken component. It's the handover between two systems that each believe the other did the work.
Failure mode 04
It compounds silently
A loud failure gets fixed on the day. A silent one accrues for as long as it takes someone to notice, which is why the bill is so much bigger.
Why teams pick me
I build the system, not the slide deck.
Knowing a process has quietly stopped means knowing how it was wired in the first place: where the handovers are, what it should have emitted, and what a plausible number looks like. That's where 25 years of building these systems matters.
I test for execution, not for errors
Every unattended process gets two checks it probably doesn't have: did it run when it was supposed to, and did it produce the output it was supposed to. Error monitoring answers neither.
Five days, fixed fee, written findings
Not a discovery phase, not a strategy deck. A list of every unattended process, whether it ran, whether it produced anything, and what it exposes you to where it didn't.
I tell you if it's fine
There's no incentive here to manufacture a problem. If your processes are running and producing what they should, the report says so and you have that in writing.
Services
Start with the audit.
One fixed-fee engagement that tells you what is actually running. Everything else follows from what it finds.
How the check works
The two questions almost nothing in your stack is asking:
- did it run
- did it produce output
- was the output plausible
- who would know if not
Applied to a process, that looks like this:
Error monitoring tells you when something broke. These checks tell you when something quietly didn't happen, which is the failure nobody is watching for.
Approach
How I work.
Same shape every time. Small scope, working system, clear handover.
1
Step 1
Scoping call
2
Step 2
Read access
3
Step 3
Inventory
4
Step 4
The two checks
5
Step 5
Findings and walkthrough
1
Step 1
Scoping call
2
Step 2
Read access
3
Step 3
Inventory
4
Step 4
The two checks
5
Step 5
Findings and walkthrough
Where this comes from
Systems I own and operate, not just ones I advised on.
Products I built and run myself, which is where the unattended-process problem stops being theoretical.
Invoicing and e-invoicing compliance, Polish marketLive
doFaktur.pl
An invoicing product built against Poland's KSeF e-invoicing regime. Filing under a national mandate is exactly the case where a submission that reports success and never lands becomes a compliance problem rather than a bug.
KSeF · Regulated filing · Azuredofaktur.pl
HMRC and Companies House APIsOngoing
Government filing integrations
Integration work against UK statutory filing endpoints: Making Tax Digital, corporation tax returns, and Companies House. The same class of process, the same failure mode, and a deadline attached to every one of them.
MTD · CT600 · ECCTA—
Scheduled multi-stage automationLive
Unattended agent pipelines
Multi-stage pipelines running on a schedule with no operator watching, built with explicit approval gates, CI and monitoring. Running these is how I found the failure mode this practice is built around.
n8n · Supabase · Human approval gates—
Common questions
The questions I hear most.
- What does the first engagement look like?
- The Silent Failure Audit: five working days, fixed fee, covering every unattended process I can reach. You get a written findings document listing what should have run, what actually did, what produced output, and the exposure attached to anything that didn't.
- We already have monitoring and alerting.
- Almost everyone does, and it's usually good at what it's built for. But alerting is triggered by something going wrong. A process that never starts doesn't go wrong, it just doesn't happen, so it raises nothing and appears nowhere. That's the specific gap this looks at, and it's a design characteristic of the tooling rather than a failure to configure it properly.
- What if you don't find anything?
- Then the report says so and you have that in writing, which is worth something on its own if you're heading into an audit or a sale. I'd rather tell you it's fine than manufacture a finding. The fee is the same either way, which is deliberate.
- How much access do you need?
- Read access to scheduler and execution history, logs, and enough of the output side to check that things landed. No write access, and no production changes during an audit. If access takes time to arrange I'll scope around what's available.
- Is this only for regulated businesses?
- No, but that's where it pays for itself fastest, because the cost of a process that silently stopped is a penalty or a failed audit rather than an internal annoyance. If nothing you run unattended carries that weight, this is probably not urgent for you and I'll say so.
Start with the audit
How would you know if it stopped?
Pick the process you'd least like to have quietly failed. If you can't say how you'd find out, that's the one to check first.
Currently working with a small number of clients.
Show me what isn't running
Five days, fixed fee. You get a written findings document.