Core: from AWS to on-prem
The same Medallion pattern from the cloud framework was ported to on-prem (Windmill + DuckLake). One agnostic pattern, two paradigms.
03 · Method
Method
I build software rails: frameworks that optimize my work and the team’s. A new source is configuration, not new code. I don’t work with open technical debt.
The 3-level leverage chain
I build the platform
The Core framework: the stable Medallion engine with its extension contract. The base everything else rests on.
I build the CLI that operates it
tf-admin: a single interface to administer the whole infrastructure, with guardrails on destructive actions.
I build the agents that drive it
AI agents that operate the CLI safely. The team delivered an entire airline’s BI with this chain.
Reusable cross-sector assets
cortex-ai: from product to this portfolio
The AI engine that decides inside a real product is the same one answering in this page’s chat. One brain, two uses.
The same pattern across three domains
The same verb —declare the intent, detect the drift, reconcile— applied across three domains:
| Domain | Tool | The same verb, applied |
|---|---|---|
| Infrastructure | tf-admin | plan / apply over Terraform — the obvious case |
| BI operation | bi-ai-tool | A custom REST client that operates Superset and Grafana programmatically, not by clicking the UI |
| Project management | azure-devops (Tools) | import / diff / apply --dry-run over Azure DevOps sprints, work items and wiki — local spec as the source of truth, Azure as the runtime |
Automating infrastructure is expected. Applying the same model to how a project is managed is not.
I optimize to the limit, and I write down where the limit is
One of my principles: cut costs by optimizing resources to the limit before scaling. That doesn’t mean I never have to scale, or that it can’t be done — it means the decision to scale is made with data, not out of habit. Six decisions: five where the discipline was not to overspend, and one where it was the opposite — to scale, because the numbers called for it.
| Context | The decision | The ceiling, said out loud |
|---|---|---|
| Aviation BI | PostgreSQL Data Mart, not Redshift | The scale ceiling is explicit and accepted in the case study itself |
| Aviation BI | Orchestration on Lambdas, not Glue | Sized against real volume, not speculative |
| Distribution Data Lake | On servers the company already had | Chosen for implementation time, with the structure ready to migrate when needed |
| Own agent platform | The whole platform on a single, deliberately small host | Documented as a single point of failure, with a remediation plan — not hidden |
| That same platform, on AWS | Written rule: Lambda by default, because you don’t pay for idle time | With its exception also written down: when Fargate is in fact justified |
| SQL Server / Siesa | Migrate to NVMe disk — scale, not cut | Measured before deciding: 25x on sequential operations, but only 1.4x on the latency that hurts billing — I didn’t oversell the full improvement |
The rule: never «cheap» without saying how far, and never «we have to scale» without saying how much was measured first.
I lead by building and teaching
I train the team in applied AI and in the fundamentals of data modeling; it’s in my project tracking reports. In June, two people on the team made their first production deployment autonomously. One of them is now training the next person with the same model.