Consulting · technical due diligence and architecture audits
Technical due diligence. A written report before you sign
Technical due diligence is a review of a software product before money changes hands: an investment, an acquisition, or taking a system over from another supplier. We read the code, the infrastructure, the security and the way releases are made, and we write down what we found. Amazing Soft, a software company in Bucharest since 2016, does this work at a fixed price. You receive a written report and a blueprint: what to keep, what to change, and in what order. The same review, done on your own product, is an architecture audit.
The problem. A demo hides the code
A demo shows what the product does today. It does not show whether the product can carry more customers, how much of it depends on one developer, or what it costs to run. The people who can answer are the ones selling. After the contract is signed, every surprise in the code is yours.
What we review. Six areas
Code and architecture.
How the system is put together, what is tested, and which parts will be hard to change.
Infrastructure and running costs.
Where it runs, what the monthly bill is made of, and whether the servers can be rebuilt from code.
Security and data protection.
Access, secrets, backups and how personal data is handled, compared with what the contracts promise.
Delivery.
How a change gets from a developer’s laptop to production: reviews, automated tests, CI/CD, rollbacks.
Dependencies and licenses.
Third-party libraries and services, their licenses, and what is out of support.
People and knowledge.
What is documented and what only one person knows.
What you receive. A report and a blueprint
- A summary for people who do not read code: the findings that affect the price or the decision.
- The findings in detail, ranked by risk, each with the evidence behind it.
- The blueprint: what to keep, what to change, and in what order.
- The order of magnitude of the work behind each change.
- A conversation in which we present the report and answer questions.
Which review you need. Three situations
Technical due diligence.
It fits when you invest in a software company, buy one, or buy a product from one. You decide with the report in hand.
It does not fit when you need a legal or financial review; those are done by lawyers and accountants.
Architecture audit.
It fits when the product is yours and you want to know what will hold as you grow, before the next large piece of work.
It does not fit when the product changes direction every month; the report would be out of date before you used it.
Takeover assessment.
It fits when another supplier built the system and you want someone to take it into monthly support.
It does not fit when nobody can give access to the code, the servers and the accounts.
This review is not a penetration test. It reads how security is built; it does not attack the running system.
Say you are about to invest. What the review would tell you
Say you are an investor about to fund a software company. The founders show a working product and a growth chart. The review would tell you whether the product can carry more customers than it has today, and how much of it depends on one developer. It would show what the hosting would cost as usage grows and whether customer data is handled the way the contracts say. You would read the summary before the term sheet, and the founders would receive the list of changes, in order.
How it runs. Four steps
The free 30-minute consultation.
We agree what is being reviewed and what decision the report has to support.
Access.
Read-only access to the code, the infrastructure and the documentation, under a confidentiality agreement.
Review and interviews.
We read the system and talk to the developers who built it. They know where the weak points are.
Report and discussion.
You receive the written report and we go through it together. A review of this kind usually takes two to three weeks; the exact term is agreed after the first conversation.
Who this suits. Investors, buyers and founders
Investors and companies in the UK, the EU, the US and Canada that are about to fund, buy or take over a software product. Founders who want to know what an investor’s reviewer will find before the round. Companies that received a system from a supplier who is no longer available.
Proof. Systems we assessed and took over
Retail store software for an international retailer, moved to Linux
We moved the software the stores run on onto new equipment and onto Linux, in phases, and added self-scan for shoppers. See this work →
Alcedo
The catalogue app has been in production since 2016. We designed its database, rewrote the app in Flutter and merged two apps into one. See this work →
Before we take over software built by someone else, we assess the code, the infrastructure, the accounts, the dependencies and the risks, and we put the findings in writing. The review is led by our CTO, who holds an M.Sc. in Computer Science and the PECB Chief Information Security Officer certification; see Leadership.
Questions. Short answers
What is technical due diligence?
Technical due diligence is a review of a software product and of how it is built and run, done before an investment, an acquisition or a takeover. It covers the code, the infrastructure, security, delivery, dependencies and the people who know the system. The result is a written report.
What does a technical due diligence report include?
A summary for people who do not read code, the detailed findings ranked by risk, and a blueprint: what to keep, what to change, and in what order. Each change comes with the order of magnitude of the work behind it.
How long does technical due diligence take?
Usually two to three weeks from the day we have access. The exact term is agreed after the first conversation, because it depends on the size of the system and on how quickly access is given.
How much does technical due diligence cost?
We do not publish prices. The work is done at a fixed price, which depends on the size of the system and on how many areas the review covers. The cost is agreed after the consultation, in the written proposal.
Is an architecture audit the same as technical due diligence?
The work is the same and the reader is different. Technical due diligence is written for someone deciding whether to invest or buy. An architecture audit is written for the company that owns the product and wants to know what to change before it grows.
Do you need access to the source code?
Yes. We ask for read-only access to the code, the infrastructure and the documentation, under a confidentiality agreement. Without the code, the review covers only what can be seen from the running system and is marked as such in the report.
Does the review include a penetration test?
No. The review reads how security is built: access, secrets, backups, dependencies and data handling. A penetration test attacks the running system and is separate work.
Who we are. A software company in Bucharest
Amazing Soft SRL is a software company in Bucharest, Romania, founded in 2016. We work remotely with companies in the UK, the EU, the US and Canada, in English. Our data processing agreement is published on our legal page. The price is set after the free 30-minute consultation, in the written proposal with a fixed price.
Tell us what you are buying. We read it first
In the free 30-minute consultation we agree what is reviewed and what the report has to answer. We reply on the channel you wrote on.