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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
05Technology
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
- In-memory storage
- Relational databases
- Vector databases
- Queues and events
Platform
What keeps everything up.
- Docker
- CI/CD
- Kubernetes
- AWS
- Azure
- GCP
- Security
- Observability
Enterprise
What already exists in the company.
- ERP
- CRM
- Integrations
- Process automation
- Business Intelligence
AI
The most recent layer.
- LLMs
- RAG
- Agents
- Orchestration
- Context engineering
- Workflow automation
- MCP
- Fine-tuning
06AI 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.
07Principles
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.
09About
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.
10Contact
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.