You already paid for this software. Find out what you actually own

Because a free audit is a sales pitch with a report attached, and the recommendation is decided before the work starts: it is always a rebuild, always with the firm doing the audit. Charging a fixed fee removes that incentive. You own the report whatever it concludes, you can hand it to any other team, and we can afford to tell you the honest answer, including that your code is fine and you only need maintenance.

Then we show the arithmetic rather than asserting it. A rebuild is justified when the cost of repair plus the cost of continuing to work in the existing code exceeds the cost of replacement, and that is a calculation, not an opinion. It is also rarer than the industry suggests: most software fails in specific places, and replacing a whole product because one subsystem is bad is the most expensive mistake available. Where a rebuild is genuinely cheaper we will say so and show why.

It helps and it is often not available, which is usually why you are calling. We need read access to the repository, the infrastructure and the store accounts. Where source code has genuinely been lost we can still assess the running application, its behaviour, its data and its security posture, and tell you what recovery would involve. Establishing what you actually control is part of the audit, and it is where unwelcome surprises tend to surface.

Most inspections run one to two weeks depending on the size of the codebase and how many platforms are involved. The fee is fixed and quoted after a free scoping call, so you know the number before committing. If you then ask us to do the corrections, the assessment fee comes off the first invoice.

Usually, and it is a common reason people call. Rejections cluster in predictable places: missing account deletion, subscriptions not using the platform's billing where required, privacy labels that do not match what the app collects, permission prompts without justification, and missing required sign-in options. A related failure is an app left untouched so long that it targets an SDK the stores no longer accept, which needs bringing forward before anything can ship at all.

Yes, and we do it regularly. We normally start with an inspection so we are not agreeing to maintain something whose condition we cannot see, then take on dependency and OS updates, monitoring, incident response and new features. Where the audit finds a subsystem that makes safe maintenance impossible, we say so and price fixing it before taking responsibility for uptime.

Only if it is true, and we try to be fair about it. Plenty of code that looks alarming was a reasonable response to a deadline, a budget or a requirement that changed underneath it. The report describes the condition of the software and what it will cost you going forward, not a verdict on whoever wrote it. What we will not do is soften a genuine security or data problem to spare anyone's feelings.

A written report you keep: a plain-language summary for whoever makes the decision, a prioritised fix list ordered by cost and risk, a repair-or-rebuild recommendation with the reasoning, an inventory of what you own and what you do not, and a technical appendix for whichever team does the work. Plus a call to walk through it. It is yours regardless of whether you hire us for anything afterwards.

Often the problem is not the code. Sometimes it is scope that never got agreed, a process that produces impossible requirements, or a vendor relationship where nobody has written anything down. The scoping call is free and we will tell you if what you need is not an audit. Advising you to fix the contract rather than the codebase costs us a project and saves you considerably more.