byASB Ankiit Singh Send the evidence
← Hire/Rescue
TAKING WORKTwo projects at a time

Software project rescue for systems failing in the field.

It worked on the bench. It doesn't work in the field. I take production systems that are slow, unreliable or stuck — review the code, hardware and field evidence, and put the cause and next step in writing.

Send the evidence → How it works
Does this sound familiar
It fails at night, or in rain, or only on one site.Conditions you can't reproduce at a desk are where most field failures live. The lab is not a smaller version of the world.
It both misses things and fires on nothing.Failing in two directions at once means the threshold isn't your problem. Tuning it further just chooses which way to fail.
The proposed fix is "retrain it" or "lower the threshold".Sometimes right. Often an expensive way to avoid finding the actual cause, and weeks gone either way.
It got slower and nobody knows when.Gradual degradation hides in changes that each looked harmless. It's findable, but not by reading the last commit.
The hardware is blamed, and the vendor blames the software.Someone has to be able to read both. That standoff is usually resolvable in days, not quarters.
The person who built it has left.Undocumented decisions that looked like inefficiencies get optimised away by the next engineer. Then things break for reasons nobody can trace.

If two or more of those are true, the diagnostic week is probably worth your money. If none are, it probably isn't — and I'll say so.

How I work a rescue
01

Evidence before code

Frames, logs, scores, field reports, the hardware spec. On the EV charging job I identified the camera, the runtime and the loop rate from screenshots alone before reading a line of source — because those facts set the constraints any fix has to live inside. Proposing something the hardware can't run wastes the week.

02

Separate the symptom from the decision

A bug report names a symptom. Behind it is almost always a design decision that was defensible when it was made — OR-logic where AND was needed, per-frame normalisation that destroyed the comparison, a training set that quietly taught the model the wrong thing. That decision is the thing worth finding.

03

Find the fix that ships this week

There is usually a correct answer that takes a quarter and a correct answer that takes a night. I look for the second one first. The FOD detector was rebuilt without retraining specifically because retraining was weeks the client didn't have.

04

Written findings, and an honest quote

You get what's actually wrong in writing — including the parts I couldn't determine and what it would take to determine them. If the fix is something your own team should do, I'll tell you that and hand it over.

It has worked before
98% ▲ · same night

A safety detector scoring a hand below a bolt

An EV wireless-charging pad fired false alarms all night and missed a human hand in daylight. The team wanted to lower the threshold. Six architectural causes, one of them a model that had learned large bright shapes were normal because the pad was glossy. Rebuilt as a two-tier detector — deployable the same night, no retraining.

Read the full teardown ↗
3 faults · before the bench

Firmware written against a faulty schematic

A three-phase energy meter, reviewed on paper before the firmware was written. Found a reversed isolator channel that would have killed an output, an oscillator marking off by a transposed digit, and a boot-strap conflict on a shared pin — each traced to its consequence and given a remedy.

See the project ↗

Sixteen years of this across computer vision, embedded hardware, regulated healthcare and field-deployed mobile — the full archive is here.

The diagnostic week
What it isOne week, fixed fee, paid. I review your code, your hardware and your field evidence.
What you getWhat is actually wrong, in writing — with the reasoning, so your team can check it rather than take my word.
And thenA fixed quote for the fix, if the fix is mine to do. Fixed price, milestone-paid, one pass to a written definition of done.
If it's not meIf your own team should do it, or the answer is simpler than hiring anyone, I'll say that. It has happened and it will happen again.
CapacityTwo projects at a time. Not scarcity theatre — that's the number where I stay hands-on.
Free consultationsNone. The scoping week is paid, or it doesn't happen. What is free is the paragraph below.

What this is not

  • Not staff augmentation. I'm not an extra pair of hands on your backlog for six months.
  • Not ongoing operations. I diagnose and fix, then hand it back. A system that needs me permanently is one I built badly.
  • Not a second opinion to settle an argument. If the decision is already made and you want validation, that's a poor use of your money.
  • Not urgent-at-any-hour incident response. This is deep diagnosis, not a pager rotation.
Start here
Free, and genuinely useful

Send me the screenshot of it failing.

Frames, logs, scores, an error, a graph that went the wrong way — whatever you have. I'll reply with whether the problem is where you think it is, and whether a diagnostic week is worth your money. No charge for that paragraph, and no pitch if the answer is no.

Enquiry details and source context are sent to the enquiry mailbox. Contact data and privacy.

Or email ankit@utenx.com directly. Everything is read by me, not a CRM rule.

Recovery decisions

Establish the failure before choosing the remedy.

Use the refactor versus rewrite decision guide to compare a bounded repair, gradual replacement and a rebuild. The architecture review checklist lists the evidence a diagnostic week may need.