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 1instead ofLIMIT, 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.
