System Logs

March 2021. I open Visual Studio.

A few seconds earlier I ran a VBA macro – the same kind I had been writing for years to automate Excel, Access, Outlook. Generating a text file is nothing new. Change the extension to .cs, point it at the repo folder, done.

But this time the file is a C# controller.

I open it. Usings are there. Structure looks right. A missing semicolon here, a curly brace to fix there, indentation needs work. But the backbone is correct. I look at it for a moment and think: this is going to work. We only have a few master data tables at this point, but I can already see what this becomes.

That was the first generated file. Today there are 1,622 of them.

—

A few months earlier, a conversation with the client-side developer had planted the seed. We were mapping out the architecture and he said something like: there are going to be a lot of schemas and properties here, maybe we should build an engine on the client side so we don’t have to write everything by hand. He was right. I agreed immediately. And then a second thought followed almost instantly: if we are generating the client config anyway, I can generate the backend CRUD from the same source. And if I do that, I can run code-first migrations to the database from the backend. Single source of truth. One Excel config file with macros. Everything else flows from it.

That chain of logic took maybe a few minutes to form. What it produced took five years to build out fully.

—

The numbers today: 843 schemas, 8,911 properties, 2,776 API endpoints. Only 108 of those endpoints are written by hand, the rest are generated. Every time the config changes in Excel, I regenerate, so the entire stack stays consistent – backend, database, client. No typos between layers. No field name that exists in the database but was spelled differently in the API response. No moment where someone has to manually cross-check three places to make sure they match. The Excel config is the truth, and everything else is a consequence of it.

In 2021 I did not have a word for what this was. If I were building it today I would probably compare it to working with an AI coding assistant – the repetitive, mechanical work disappears and what remains is the thinking that actually requires a human. Except in 2021 there was no Claude Code, no Cursor, no generative anything. So I built the generator myself, for my specific domain problem, and it did the same job.

—

Here is what a full regeneration cycle looks like today. Backend regeneration: 35 seconds. Schema and property config built and pushed to the database: 29 seconds. 2,746 buttons generated and loaded: 17 seconds. I18n – 12,268 rows collected from schemas, properties, buttons, and both client and backend custom strings, pushed to the database: 35 seconds. Then Visual Studio migration and database update, a few minutes depending on changes. Build: 57 seconds. Upload script pushing 230MB across 750 files to Google Cloud Storage,
network dependent. Server script stops the service, backs up production, swaps the backend from the bucket, restarts. Under a minute.

Adding a new table from scratch: 5 to 30 minutes.

That is one full cycle. From config change to live production.

This is not a two-week sprint system. On DEV, if something needs to move fast, I release three to five times in a day so the team can see it, react, and tell me what to adjust. If there is no urgency, one DEV release per day is the normal rhythm. On PROD, feature fine-tuning and bug fixes can go out daily. If a significant bug surfaces during the day, I push an update before lunch.

The cycle exists. It just runs at a different scale.
—

The client developer and I returned to this architecture many times over the following years. Not to change it – to look at it. There was a specific kind of conversation we kept having where one of us would point something out that is handled by this framework in a smart way and the other would say yes, I know, it’s really good isn’t it. Not pride exactly, but more like the quiet satisfaction of a decision that kept paying off in ways you did not fully anticipate when you made it. We created something that is extraordinary, that lasts, a tool you don’t want to replace by time, but you want to keep improving.

And then something unexpected started happening. The more features we added to the framework, the more generic it became. We had built it for a very specific domain – customs management, Hungarian tax authority integrations, regulatory compliance workflows. But the underlying logic did not care about any of that. It cared about schemas, properties, relationships, and rules. Add a new content type, configure it in Excel, regenerate, done. The UI builds from config. The API builds from config. The database builds from config. We started seeing use cases everywhere – any kind of content management, any process management system, anything CRUD-heavy where the shape of the data changes faster than you want to rewrite code. We had not planned for this. We had just solved our problem well enough that the solution outgrew the problem.

—

Every system has a moment like this somewhere in its history. Usually it does not look like a breakthrough when it happens. It looks like a .cs file with a few syntax errors that you open in Visual Studio and think: this is going to work.

The architecture does not reveal itself all at once. You see it in the files that start appearing in the repo folder. You see it when a new module takes days instead of weeks. You see it when someone asks how you handled some edge case and the answer is: I didn’t, the generator did.

That is what systems do. They keep working after you stop thinking about them.