1
Copy the surface
One request to the login page and its list of assets. No session, no cookies, exactly what any visitor receives.
↓ 133 JS files · 3.5 MB · 1 CDN
Reverse engineering · case study
A SaaS product only shows the part it chooses to show. Before building anything on top of it, I wanted to know what is really inside and where my right to look ends. This is the method, the numbers and the limits of an exercise carried out solely on the public surface of a product in production.
0 credentials · 0 backend access · 0 third-party data
A vertical SaaS presents itself with a simple promise and a handful of marketing screens. But the question that really matters —what does this do inside, and what doesn't it do?— isn't answered by looking at the landing page. And without that answer, every product decision is made on instinct: either you rebuild the whole thing, or you commit to the tool without knowing how far it goes.
Reverse engineering solves exactly that: reading what the product already hands to any visitor and turning it into a map. It isn't an end in itself; it's an instrument for making better decisions.
Before the first line of code, a written boundary. It isn't a formality: the whole method depends on respecting it, because what makes the exercise useful is precisely what it leaves out.
One request to the login page and its list of assets. No session, no cookies, exactly what any visitor receives.
A search for hosts, routes, service names and domain vocabulary. The code is minified, but the text isn't: it survives intact.
A parser turns the bundle into a graph of functions, calls and literals. It's narrowed down to two files: the entry and a domain chunk.
A headless browser opens the login page and records the network. The 401 response isn't an error: it's the boundary of the system, confirmed.
The translation files are public and work as an inventory: every module, every screen and every feature has its name there.
Each step narrows the target of the next. Downloading everything first and analyzing it afterwards would have been unworkable: the full graph of 133 files runs to hundreds of megabytes.
The marketing sells one feature. The dictionaries describe 53 modules: purchasing, recipe costing, inventory, sales, treasury, payroll, group consolidation, bank reconciliation, accounting. What is presented as a single-purpose tool is, inside, a complete vertical ERP.
That gap between the message and the product is the most valuable finding of the exercise: it defines the real gap in the market and, at the same time, warns you what makes no sense to rebuild.
A case study that only tells what went well teaches nothing. These are the walls I ran into, and why the result is still useful in spite of them.
The result wasn't a finding, it was a decision
Knowing that the product already covers 53 modules changes the strategy completely. Rebuilding what already exists at a low subscription price is the worst possible investment. The gap is in what the product doesn't do —forecasting, reputation, team training, a unified dashboard— and in the layer that connects it all.
The outcome of the exercise isn't code: it's a perimeter. And with a clear perimeter, the work that's left is the work nobody else is doing.