Work out what a product is made of, then build something better.
You have a competitor whose product does something you cannot explain. We take it apart from the outside: what it must be doing to behave the way it does, what that costs to run, and what it would take you to match or beat.
This is done from observable behaviour. Latency under load, artefacts in the output, the shape of the update cycle, the pricing, the hiring, the funding. Those constraints narrow the possible implementations far more than people expect, and the remaining candidates can usually be tested.
We drive the product the way a difficult user would and record what it does. Where it breaks, where it stalls, where the quality falls off. Failure modes are the most honest description of an architecture you can get without the source.
A written account of what we believe the thing is built on and why, with the evidence for each claim and a confidence level against it. Where a claim can be settled by a test, we run the test and report the result.
What their approach costs per user, which parts are genuinely hard to copy, and which parts only look hard. Most moats turn out to be a data set, a distribution deal, or a single unusual engineering decision.
Knowing how something was built is worth little on its own. We finish with a route to a version that is faster, cheaper, or sound better, with the tradeoffs written down so you can pick.
No. The analysis is from observable behaviour and public information. That keeps the result clean to act on.
Usually two to four weeks for a single product, depending on how much of it we can exercise.
Yes, and it is often more useful. The same method applied to your product tells you what a competitor can already see.