Technology due diligence with every risk priced

• Code and architecture

  structure, tests, dependencies and what is hard to change.

• Security posture

  access, data handling and known weaknesses.

• Delivery and team

  how releases happen, and who the system depends on.

• Cost and scale

  what running it costs now, and what growth will do to that.

• Licences and open-source terms

  anything in the code that limits how you may use it.

• Key-person risk

  knowledge held by one engineer or one contractor.

1. 01A technical assessment of the system as it stands.
2. 02A team and process review.
3. 03A priced risk register

   each red flag with the cost of fixing it.

4. 04A plan for the first hundred days after the deal closes.

You can set the register against the asking price or fold the fixes into your terms.

Each item in the risk register carries a cost to fix it. A buyer can put those costs against the price, ask the seller to repair the item before closing, or decide to walk away. A lender can attach conditions. Because the same report says what is sound, you are not asked to treat the whole system as a problem.

We need read access to the code and time with the people who built and run it. Without both, the report would describe only what the seller chose to show. The review is sized to the target and charged as a fixed fee. A principal architect leads it with a senior engineer.

• Can this system be run by a team other than the one that built it?
• Which parts would fail first if usage doubled?
• Is customer data stored and protected the way the seller says?
• What would a rewrite of the weakest part cost, and does it need to happen this year?
• Which people hold knowledge that is written nowhere?

Each answer comes with the evidence we looked at, so your own advisers can check it.

• An investor or lender with a technology question
• A company about to buy another one's software
• A board inheriting a system from a vendor or a departing founder
• A buyer comparing two products it cannot test itself

We read code in your environment or the seller's data room, and we speak with engineers on a call or in person, at the target's site or at our Noida office. Access is limited to what the review needs and is revoked when it ends.

A report that finds a rewrite is needed can lead into legacy modernisation. Ongoing oversight of a system you now own is covered by CTO as a service.