Can I fix the due diligence findings myself, with my own coding agent?

Yes. The due diligence is free and the report is yours; take it to whoever you like. Handing the findings to the same agent that built the app, one prompt at a time, is the continuation of how the gaps were made: no acceptance criteria, no independent review, no record of what changed, and nobody rerunning the score. The prodready SDLC runs the same findings through refined stories, gates, three independent reviewers, a sprint audit and a rerun of the due diligence until the app scores 4 out of 5.

When is fixing it yourself the right call?

When it is a weekend project, when there are no customers yet, when you are the only user, or when you simply enjoy doing it. Then fix it yourself. The free report stays free and you can rerun it whenever you like.

When is fixing it yourself not the right call?

When you have paying customers, when the app holds personal data, when a client asks for proof, when procurement sends a questionnaire, when a second developer is about to join, or when an investor's technical due diligence is coming. In each case someone will ask what changed, who checked it and how you know, and a chat history is not an answer.

What if I fix it myself?

What you get for free

118 read-only checks across five areas, run by your agent on your machine.
The 18-dimension technical review — architecture, security, data, code quality, testing, compliance and twelve more — each scored 1–5.
Every gap with its file and line, and what it costs you if it stays.
A risk heatmap and the top risks, in order.
No remedies. The report names what is wrong, not how to fix it.

It is yours. Take it to whoever you like — your agent, a freelancer, a friend who codes, us.

Path A: you fix it with your own agent

What usually happens, from your side of the screen. Nobody here is careless; the method is.

Your agent · your prompts

Day 1
You paste the findings.Twelve gaps, the report as the prompt. The agent says it understands and gets to work.
Day 1, an hour later
It fixes six of the twelve.It also rewrites two things nobody asked it to touch. The summary says “all issues addressed”.
Day 2
The tests still pass.The tests that exist still pass, because there are almost none. Nothing new was written to prove a fix.
Day 2
Nobody reviews it.The same agent that left the tenant check out now says the tenant check is in. You have its word, and that is all you have.
Day 3
You ship.What changed and why lives in a chat history. Nobody checked whether a fix broke something else.
Week 3
The next feature reopens two of the gaps.Nothing stood in the way, so nothing noticed.
Month 1
You rerun the report.2.4 → 2.6The score moved. Not much.

The point

The method that produced the gaps cannot be the method that closes them.

Path B: the same findings, through the SDLC

The same report, the same repository, the opposite method. Each step has to pass before the next one opens.

prodready SDLC · specialised agents and gates

Stories
The findings become stories.Each one with acceptance criteria that pass or fail. What “done” means is written down before anyone starts.
Gate · refine
A story cannot start until it is refined.An unrefined story is refused, not queued. Scope is settled before code is written.
Build · verify
The agent builds; verify runs.Specialised agents build to the criteria. Verify runs the tests and records the result before the change can go further.
Gate · review
Three independent reviewers.Each with its own one-time nonce, none of whom built the change. They approve or reject; a rejection goes back.
After the sprint
An audit, then the due diligence and the load test again.The score is rechecked every sprint, not once a month when someone remembers.
Throughout
Decisions are recorded, not guessed.Anything a person has to decide goes into a register with who decides it. A ledger says who did what, at which gate.
Until done
Iterate until 4 out of 5.→ 4 / 5The loop stops when the due diligence says so, not when the chat does.

Side by side

Question	Your agent, your prompts	prodready SDLC
Who decides what done means	The agent, in its summary	Acceptance criteria written before the work, pass or fail
Who checks the fix	The agent that made it, or you, when you have time	Verify, then three independent reviewers who did not build it
When a step is skipped	Nothing happens. Nobody knows it was skipped	The next step is refused until the gate passes
What you can show afterwards	A chat history and a commit log	The ledger, the reviews, the audits, the decision register and the rerun due diligence
What the score does over time	Moves a little, then drifts back as features land	Rechecked every sprint, iterated until 4 out of 5
What it costs you in attention	Every prompt, every check, every “is this really fixed?”	The decisions only a person can make; the process holds the rest

When fixing it yourself is the right call

Plainly: often. If one of these is you, do it yourself.

It is a weekend project. The stakes are yours alone.
There are no customers yet. Nobody is relying on it today.
You are the only user. A broken tenant check cannot leak anyone else’s data.
You enjoy it. That is a good enough reason.

The free report stays free. Rerun it whenever you like and see where the score went.

When it is not

In each of these, someone will ask what changed, who checked it and how you know. A chat history is not an answer.

You have paying customers. A regression is now their problem, then yours.
The app holds personal data. “The agent said it was fixed” is not a record.
A client asks for proof. They want evidence, not a promise.
Procurement sends a questionnaire. It asks about review, audit and change control by name.
A second developer is joining. They need to know what was decided, and why.
An investor’s technical due diligence is coming. They will run something like our report, and read the history behind it.

Run the free due diligence. Then decide.

Either way, you start with the same report. What you do with it is up to you.

Pricing

Run the free due diligence What the SDLC does