Abandoned, late and still billing, failing in production, or a prototype that will not go live. A troubled application is diagnosed, not restarted. Five days to a written verdict.
You leave knowing whether this is stabilise, repair or replace, and what week one looks like.
Vishal stays close to a limited number of consequential engagements at a time. If the fit is not right, he will say so early.
Rescuing a software project starts with control, not with code. Take owner access to the repository, the cloud accounts, DNS and the deploy pipeline, inventory and rotate every credential, and prove you can restore a backup. Access is lost permanently. Code is not.
Time-boxed because your money is burning while you decide, and an open-ended audit bills for the deciding. A live system that is failing now gets a first read before day five.
A rewrite is only defensible when you understand the requirements better than you understand the code. Everything else is repair, wrapping, or incremental replacement.
Written to be used by somebody else. A verdict you cannot take elsewhere is not a verdict, it is a quote.
A separate decision, made after the first one is already in your hands. Repair and incremental replacement are continuous work inside a running system; a bounded stabilisation or a cutover has an end you can write down. If the verdict is replace and you want it built fresh, that is the Build page.
Monthly, per engineer · Rolling, starts with a trial week
A named engineer working your backlog inside your team, judged on real output before you commit to anything.
For continuous repair inside your team: Discuss an embedded engineer
Fixed scope, quoted · Defined outcome, defined end
A named deliverable built to an agreed definition of done, priced before it starts rather than billed as it runs.
For a bounded fix with an end date: Scope a delivery
It is the right suspicion, because a rebuild is the largest engagement I could sell you. A promise not to say it would be worth nothing. So the rule that decides it is published above instead, before you have paid anything, and the verdict is reasoned from evidence you can check rather than asserted.
The verdict is yours to take to any vendor, including one that is not me. It is written for an engineer who has never spoken to me. Delivery through ViitorCloud is a separate decision you make afterwards, and you can make it differently.
No project commitment. No predetermined technology. No pressure to proceed when the evidence says stop. And no figure quoted for work that has not been scoped.
Only if the evidence says so, and the evidence is written down where you or any other engineer can check it. This is the judgement you have most reason to distrust, because a rebuild is the largest engagement I could sell you. So the rule is published on this page rather than applied privately: a rewrite is only defensible when you understand the requirements better than you understand the code. The verdict is reasoned rather than asserted, so the argument can be attacked on its merits instead of taken on trust.
Then that is the first problem, ahead of the code itself, and it is why the checklist on this page comes before anything I sell. Secure everything you already have the right to access, and take legal advice before pressing for anything you do not. On the IP question specifically: absent an explicit written assignment, paying in full may only have bought you a licence rather than the copyright, and that varies by jurisdiction, so have your own lawyer read the contract. Where there is no repository at all, a diagnosis can still run against the running system, the deploy record and the contract. It is a weaker read and I will tell you it is weaker rather than dress it up.
No, and it is the wrong week to decide. The people who built it hold information that exists nowhere else, and they usually expect to be blamed for it, which is the fastest way to lose that information permanently. Establish the facts first. If a change of team is the right call it will still be the right call in week two, and by then you will be able to explain why in terms the team, the board and the next vendor can all follow. Working alongside the incumbent is often the cheaper path; what it needs is written boundaries before the first change, on merge rights, releases and escalation.
Five working days for the written verdict. A production system that is actively failing gets a first read sooner than that, because stabilising something that is losing money now does not wait for a document. The reason it is time-boxed at all is that your money is burning while you decide, and an open-ended audit bills for the deciding.
Bring whatever you have: a repository you cannot deploy, a vendor still invoicing, or a production system failing in front of customers. Five days, then a written verdict you own.
No project commitment. No predetermined technology. No pressure to proceed when the evidence says stop. And no figure quoted for work that has not been scoped.