I Reverse-Engineered a Restaurant ERP With No Documentation. Here's What It Taught Me About Being a Self-Taught Developer.

Luis Henrique Vasconcelos — Sat, 15 Aug 2026 00:19:56 +0000

There is no manual for TronSoft. No API reference, no schema diagram, no forum thread explaining why a comanda refuses to close. If you want to understand it, you open the database and start pulling threads until something makes sense.

That's exactly what I did — for months, on top of my actual job.

The problem nobody wrote down

I'm the Operations Manager at a restaurant in Itaúna, a mid-sized town in Minas Gerais, Brazil. I'm also the only person there who writes software. Not because I was hired to — because the restaurant runs on a Brazilian ERP called TronSoft, built on a Firebird database, and Firebird doesn't come with the kind of ecosystem you get around Postgres or MySQL. No Stack Overflow flood of answers. No official docs beyond a thin operator manual. Vendor support exists, but it's slow, and it doesn't scale to "I want to automate this specific internal workflow at 11pm on a Tuesday."

So when I needed to automate payment reconciliation, close out comandas without touching the vendor's fragile UI, and trigger fiscal document emission (NFC-e) reliably, I didn't have a spec to follow. I had a live production database and a lot of curiosity.

Learning a system by watching it think

I started the way you'd expect: opening tables, guessing at relationships, breaking things in a test environment until I understood why they broke. Over time that turned into something more systematic — I ended up documenting 390 tables and 514 foreign keys across roughly 40 functional modules, entirely from observation. No vendor documentation, no source code access. Just structure, inference, and a lot of trial and error.

Some of what I learned only reveals itself under pressure:

Firebird's SQL dialect has its own quirks — FIRST 1 instead of LIMIT, for one. Small thing, but it breaks every query you copy-paste from a Postgres tutorial.
Primary keys aren't auto-incrementing in the way you'd assume. They're driven by generators (GEN_ID), and if you write a record without syncing the generator correctly, you get silent, confusing collisions later.
Composite primary keys meant that inserting a row "correctly" by every visible rule could still conflict in ways that only showed up once real concurrent traffic hit the system.
Transactions don't behave the way you expect until you understand exactly how autocommit visibility works in this specific setup — I've had records that existed, technically, but weren't visible yet to the process that needed them.

The hardest part wasn't the SQL. It was reverse-engineering behavior — the exact sequence of writes that happens when a human closes a comanda through the official interface, so that my automation could replicate it precisely enough for the fiscal emission service to recognize it as legitimate. I ended up watching Firebird's internal monitoring tables (MON$) in real time, diffing snapshots before and after manual actions, essentially instrumenting a black box to learn its own rules.

Why this mattered more than "just automating a task"

The first version of my automation used screen automation — literally driving the mouse and keyboard through TronSoft's UI to close comandas, because that was the only interface I had confidence in. It worked, but it was fragile. A window in the wrong position, a dialog that opened a half-second late, and the whole thing broke.

The real turning point was when I stopped treating TronSoft as a UI to automate and started treating it as a database to understand. Once I could write directly and safely to COMANDA, ITEM_COMANDA, and the tables around fiscal emission — replicating the exact NULL patterns and field conventions the vendor's own software expected — the automation became something closer to a real integration than a hack. It's been running in production since, quietly closing out transactions and triggering fiscal documents without anyone touching a mouse.

What I'd tell another self-taught developer staring at an undocumented system

I don't have a computer science degree from a top university. I'm self-taught, with a technical background from mechatronics, and everything I know about Firebird internals I learned by doing exactly what I'm describing here — sitting with a black box until it stopped being one.

A few things I'd say to anyone in a similar spot:

The absence of documentation is not a wall — it's a dataset. A live system is telling you how it works every time it runs. Snapshot diffing, query logging, and careful observation will teach you more than most manuals would anyway.

Depth in a narrow, unglamorous system is a real asset. Nobody else at my company — and very few developers anywhere — have spent this much time inside TronSoft's internals. That's not a coincidence; most people avoid legacy systems like this because they're tedious. Tedious and rare is a good combination if you're willing to do the work.

Production is the real test. It's one thing to understand a schema. It's another to write to it in a way that a separate, closed-source fiscal service accepts without complaint. That gap — between "I understand this" and "this works reliably in production" — is where most of the actual learning happened.

I'm now taking that same instinct — sitting with a system until I understand its real behavior, not just its documented behavior — into evaluating AI coding agents, which turns out to be a surprisingly similar skill: watching a black box, forming hypotheses, and testing them against what actually happens.

If you've done something similar — reverse-engineered a legacy system nobody wanted to touch — I'd like to hear how you approached it.

DEV Community: Luis Henrique Vasconcelos

I Reverse-Engineered a Restaurant ERP With No Documentation. Here's What It Taught Me About Being a Self-Taught Developer.

The problem nobody wrote down

Learning a system by watching it think

Why this mattered more than "just automating a task"

What I'd tell another self-taught developer staring at an undocumented system