GregoriDalzotto
Systems, from code to strategy.
Engineering, architecture, product and technology leadership as a single practice, for two decades.
03Evolution of scope
Two decades of accumulated scope.
No layer replaced the one before it. Each one widened those beneath, and building software never left the centre.
01
Build
Code that has to work outside the demo. The base of everything that came after, and a practice never abandoned.
02
Systems
Understanding how the parts behave together: data, integrations, APIs, failures. Software stops being files and becomes behaviour.
03
Architecture
Deciding boundaries, contracts and what can change without breaking the rest. Architecture as the reduction of ambiguity.
04
Platforms
Infrastructure, cloud, CI/CD, security and operations. The system has to exist, be observable and stay up.
05
Teams
Leading the people who build: roles, authority, cadence, review. Productivity as a property of the system, not of the individual.
06
Product
Turning technical capability into something people use. Prioritisation, scope and outcomes that are measured, not merely shipped.
07
Strategy
Technology producing capability for the business: what to build, what to buy, what to integrate and when to stop.
08
AI
The most recent layer, built on all the others: agents, RAG, engineering workflows and automated verification, applied with the context the other layers provide.
04Experience
Experience measured in responsibility, not in titles.
What remained from each context was capability: walking into a system that already exists, understanding what is at stake, deciding, and driving the execution.
Enterprise systems and integration
- Context
- Environments where ERP, CRM and legacy systems coexist with new services, and every integration carries business rules, sensitive data and history.
- Responsibility
- Designing and building the layer that makes those systems talk: APIs, contracts, automations and the handling of failures between them.
- Decisions
- Where each system's boundary sits, what integrates in real time and what reconciles later, and what should not be automated at all.
Infrastructure, cloud and operations
- Context
- Systems that have to exist in production with cost, security and availability under control, across more than one cloud provider.
- Responsibility
- Containers, CI/CD, observability, security and the operational routine that keeps everything up when nobody is watching.
- Decisions
- What to automate in the pipeline, what requires a human gate, and how much platform the team actually needs at that moment.
Digital transformation
- Context
- Processes and business areas that had to become software, with the organisational change that demands.
- Responsibility
- Leading the transition: platform choice, delivery sequence, integration with what already existed and adoption by people.
- Decisions
- Build, buy or integrate; what changes first; and how to tell whether the transformation produced capability rather than just new systems.
Digital products
- Context
- Web and mobile products taken from problem to real use, with architecture, construction and continuous evolution.
- Responsibility
- Conception, architecture and construction, with scope defined by what users need and what the business can sustain.
- Decisions
- What goes into the first version, what waits, and which technical trade-offs are acceptable at each stage.
Technology leadership
- Context
- Technology organisations and multidisciplinary teams, with competing priorities and complex technical environments.
- Responsibility
- Roles, standards, delivery cadence, hiring and the relationship between technology and the rest of the organisation.
- Decisions
- How much autonomy each front receives, what is a standard and what is the team's call, and where technical leadership sets the defaults.
Applied artificial intelligence
- Context
- Products and engineering processes where LLMs, RAG and agents became part of the system, with the risks that brings.
- Responsibility
- Applying AI with context, limits and verification: inside products, and inside the software delivery flow itself.
- Decisions
- What level of autonomy each task deserves, what needs evidence before it counts, and where architecture bounds what agents may do.
05Engineering cases
Engineering cases.
Systems presented through the decisions that shaped them, not through screenshots. Open one to see its parts.
Context
A product used every day by professionals working in loyalty and travel programmes, on the web and in the iOS and Android apps, all served from one codebase. Accounts, catalogue, invoices and targets were already there. AI came in to answer in a single sentence what used to take several screens and manual arithmetic.
Challenge
The right answer was already in the database, spread across domains that never spoke to each other. People ask however they like, and the system only understood a fixed list of phrases. Every answer also carried a cost per call and had to arrive fast enough not to interrupt the person working.
Decision
The model understands, the code executes. It reads the question and fills in an internal form; dates, sums and queries stay in code, where the result is always the same and can be checked. Who is asking comes from the session, never from the message, so nothing typed into a conversation reaches someone else's data. When the model fails, the answer comes back incomplete rather than wrong.
Architecture
Understand the question, fetch in parallel only what it needs, connect the domains through rules added one at a time, assemble the context inside a cost limit, and only then write the text. What comes back is text plus action: the text from the model, the action from the code. One source of style dresses the web and both apps, so a fix lands everywhere.
Build
Delivery came in phases, each useful on its own: the base without AI first, then question understanding, then the links across domains. The older path was not deleted when the model took over, it stayed as a safety net. One extra interpretation step was dropped, because it doubled the cost and the wait without improving the answer.
Outcome
Questions that used to mean walking through several modules are now answered in one sentence, the same way on the web and in the app. A misunderstanding no longer becomes a silently wrong answer: it comes back flagged and logged, and how often it happens can be measured. Judging answer quality without a human reading it stays hard.
In contextNext.jsTypeScriptPostgresRedisvector databaseLLMsRAGiOS and Android
Context
A multinational in the fashion industry, where global ERP, CRM and helpdesk systems lived alongside a manufacturing system and banking and tax extensions written for local rules. The remit was the whole of technology: cloud, development, data, business intelligence and support. Each system owned one slice of the process and none of them saw the whole.
Challenge
The same customer, the same part and the same document existed under different codes in each system. Much of the business logic had never been written down; it lived in the old system's behaviour and in the memory of the people running it. Add statutory deadlines, maintenance windows and the expensive risk of billing something twice.
Decision
One declared owner per record: master data in the ERP, relationships in the CRM, tickets in the helpdesk, the shop floor in manufacturing. What blocks production or billing integrates at once; what closes the month reconciles later. Tax sign-off stayed with a person on purpose: that error costs outside the company. Trade-offs like these need all five fronts in view at once, and that view is technical.
Architecture
An explicit contract per integration, with a version and a map between the codes each system uses. One system's code never becomes a key inside another, or replacing that system turns into rewriting the process. A queue sits between source and target, and every write carries a mark that stops the same entry being posted twice when a message comes back. Failures land in a visible queue, with an owner and a deadline.
Build
The integration went in process by process, never all at once. It started in observation mode: it computed what it would do and compared that with what the operation actually did, writing nothing. That is how the rule nobody had written down surfaced. Only then did it start writing, beginning with the documents carrying the least financial weight.
Outcome
Orders, production, billing and support stopped requiring the same data to be typed into every system. Master data mismatches left the month-end scramble and became exceptions with an owner and a deadline. What stays open is the logic still locked inside the old system: it is mapped, it is not solved.
In contextERPCRMhelpdeskmanufacturingqueuesreconciliation
Context
Two platforms in production, continuous delivery and a small team, with implementation assisted by specialised AI agents. The volume of change per week outgrew what manual review could follow. This site was built through the same flow, from the first line of copy to what is published here.
Challenge
Once execution gets cheap, the bottleneck moves: writing is no longer the limit, and deciding, reviewing and proving something is done become it. Code produced fast also fails fast. A mistake that slips past review comes back later, when it costs more.
Decision
Every agent has a written role and written authority: who drafts, who validates, who implements, who reviews and who ships. Shipping belongs to one role only. A specialist advises; the agent in charge decides and records that decision item by item. When a restriction has to hold, it stops being an instruction and becomes a missing tool: the reviewer has no way to write.
Architecture
The flow is made of artefacts, not conversation: a request with acceptance criteria, decisions recorded next to the option turned down, a repository memory holding what is not obvious. The gates run on their own and do not care who did the work, from code style to a sweep for exposed secrets across the whole history. The boundary that matters most is checked by machine before anything lands.
Build
The flow arrived in pieces, and every rule has a stated reason. A gate sitting on the critical path is a gate the team learns to skip, so secret scanning runs on its own pipeline, with nothing filtered out. Timeouts are sized so an overrun shows up readable, because a gate that cancels without a record erases the diagnosis.
Outcome
What used to be knowledge held by whoever was in the room became an artefact the next reader, human or agent, can pick up. Changes without evidence stopped getting in. The effort moved from typing to defining what counts as acceptable, and that part is still human. The same holds for teams of people: quality rests on the written standard.
In contextAI agentsCI/CDGitHub ActionsTypeScriptautomated gates
06Technology
Tools chosen by the problem.
None of them is the point. The point is knowing how to combine what each layer asks for, and what it does not.
Build
What becomes product.
- TypeScript
- Node.js
- React
- React Native
- Next.js
- Python
- FastAPI
- NestJS
Systems
What makes the parts talk.
- APIs
- Microservices
- Redis
- Relational databases
- Vector databases
- Queues and events
Platform
What keeps everything up.
- Docker
- CI/CD
- GitHub Actions
- AWS
- Azure
- GCP
- Security
- Observability
Enterprise
What already exists in the company.
- ERP
- CRM
- Integrations
- Process automation
AI
The most recent layer.
- LLMs
- RAG
- Agents
- Orchestration
- Context engineering
- Workflow automation
07AI and engineering
AI as a layer, not a starting point.
In recent years the work came to include artificial intelligence applied to products and to the engineering process itself.
It is not where the journey began. It is where the base accumulated in systems, architecture, operations and leadership starts to matter: it provides the context to apply AI responsibly.
AI in products
LLMs, RAG and intelligent systems inside real products, with context, cost, latency and failure treated as requirements rather than surprises.
AI-assisted engineering
Specialised agents, context engineering, engineering workflows and orchestration, with architecture defining how far autonomy goes.
Verification and evidence
Automated validation, gates proportional to risk and project memory. Abundant execution calls for more verification, not less.
AI amplifies what is already there. On a solid base it accelerates; without one, it accelerates the mistake.
08Principles
How I think about technology.
A set of positions worth more than any tool, because it outlives all of them.
Software has to work outside the demo.
The happy path does not define readiness. Production is part of development.
Architecture reduces ambiguity.
Clear boundaries say where to change and what cannot change without a conversation.
Speed without quality only brings problems forward.
What is gained in delivery is paid back in review, integration and incidents.
Automation needs limits.
Autonomy is earned through risk and verifiability. It is not declared.
Systems need to be observable.
What is not measured is not operated, and what is not operated is not done.
Technology has to produce capability for the business.
A stack is not an outcome. Capability is.
AI amplifies good and bad engineering practice alike.
On a solid base it accelerates. Without one, it accelerates the mistake.
10About
At the intersection, by choice.
Gregori Dalzotto works at the intersection of software engineering, architecture, product, technology leadership and applied artificial intelligence.
Around two decades building and evolving systems: from code to infrastructure, from enterprise systems to digital products, from the team to the strategy. Along the way, building software never stopped being practised, even as responsibility widened to architecture, operations, product and people.
In recent years, a central part of the work has been artificial intelligence applied to engineering and to product building: agents, RAG, workflows and automated verification, always from the accumulated base and never as a starting point.
11Contact
A conversation is usually the best start.
Systems, architecture, product, leadership or applied AI. If that is the subject, any of these channels will do.