Production architecture
Distributed .NET systems designed around operability, evolution, and the realities of production.
- .NET
- Distributed systems
- Observability
Principal Software Engineer · Porto, Portugal
Building reliable systems where software meets the real world.
I'm Vitor Castro. I work across .NET, AI, identity, and connected devices — turning difficult engineering problems into software that teams can operate with confidence.
Hands-on Principal Engineer
Architecture is only finished when the system works in production.- BUILD
- .NET · AI · Identity
- OPERATE
- Delivery · Reliability
- TEACH
- Data · Architecture
VITOR / CASTRO
BUILD · OBSERVE · EVOLVE
8+years building production software
3AI-powered applications delivered
20+repositories coordinated
ISEPpostgraduate instructor
01 / Expertise
Systems that are built to last.
I work across the layers that determine whether complex software succeeds after launch — architecture, integration, delivery, and operation.
Identity & access
Identity flows and access boundaries that make security part of the system, not an afterthought.
- IAM
- System integration
- Security
Applied AI
AI capabilities moved beyond the demo: evaluated, integrated, deployed, and made useful in real workflows.
- AI systems
- Agents
- Evaluation
Platform engineering
Delivery foundations that help teams ship consistently across repositories, environments, and services.
- CI/CD
- Cloud architecture
- Developer experience
02 / Selected work
From architecture to production.
Public-safe case studies focused on the problem, engineering judgement, and outcomes — without client names or proprietary implementation detail.
Production AI Systems
Taking AI from a promising prototype to three applications that people could actually depend on.
- AI
- .NET
- CI/CD
- Observability
Production AI Systems
Taking AI from a promising prototype to three applications that people could actually depend on.
- AI
- .NET
- CI/CD
- Observability
Context
Three AI-powered applications needed to move into production without each team inventing its own delivery and operational model.
Engineering decisions
Standardised container foundations across 20+ repositories, introduced reusable CI/CD across 15+ repositories, and treated security and observability as delivery requirements rather than follow-up work.
Outcome
Three applications reached production and pipeline runtime fell by roughly 50%, while the shared foundations made future changes easier to ship consistently.
Production AI is mostly systems engineering: the model matters, but reliability is won in everything around it.
FlowCheck
A focused AI workflow audit that turns repetitive work into a practical automation plan.
- Applied AI
- Workflow audit
- Product
FlowCheck
A focused AI workflow audit that turns repetitive work into a practical automation plan.
- Applied AI
- Workflow audit
- Product
Context
Teams often know that repetitive work is costing them time, but not which workflows are worth automating or where AI would create genuine value.
Engineering decisions
Designed a narrow, productised audit around workflow mapping, feasibility, and prioritised recommendations instead of open-ended AI consulting.
Outcome
A clear, low-friction way to identify the strongest automation opportunities and leave with concrete next steps rather than a generic list of tools.
The useful AI opportunity is rarely “add AI everywhere” — it is finding the right bottleneck and removing it deliberately.Visit FlowCheck
Pi — Autonomous AI Agent
An ongoing experiment in useful autonomy, semantic memory, tool orchestration, and dependable control.
- Agents
- AI
- Architecture
Pi — Autonomous AI Agent
An ongoing experiment in useful autonomy, semantic memory, tool orchestration, and dependable control.
- Agents
- AI
- Architecture
Context
Agent demos look impressive until context grows, tools fail, or the system has to decide what should be remembered and what should be forgotten.
Engineering decisions
Separate memory from the immediate conversation, make tools explicit capabilities, and design control boundaries before adding more autonomy.
Outcome
A practical research system for testing long-lived context, tool use, and the trade-offs between initiative and predictability.
Useful autonomy comes from good constraints, not from removing them.
.NET Platform Modernization
Moving a live platform from .NET Framework and EF6 to modern .NET and EF Core without treating the rewrite as the product.
- .NET
- EF Core
- Modernization
.NET Platform Modernization
Moving a live platform from .NET Framework and EF6 to modern .NET and EF Core without treating the rewrite as the product.
- .NET
- EF Core
- Modernization
Context
A production platform needed a credible path away from ageing foundations while preserving continuity for users and the team operating it.
Engineering decisions
Modernise incrementally, keep behaviour observable during the transition, and use the migration to simplify delivery instead of reproducing every historical constraint.
Outcome
A maintainable platform foundation, a clearer route for future change, and less risk than a single high-stakes rewrite.
The best modernization plan is the one that keeps delivering value while it changes the foundations.
Data & Device Orchestration
Coordinating physical devices, real-time messaging, data processing, and downstream services under real operational constraints.
- Devices
- Messaging
- Reliability
Data & Device Orchestration
Coordinating physical devices, real-time messaging, data processing, and downstream services under real operational constraints.
- Devices
- Messaging
- Reliability
Context
Once software has to coordinate devices and physical processes, timing, partial failure, and imperfect data stop being edge cases.
Engineering decisions
Make state transitions explicit, isolate device behaviour behind stable contracts, and design recovery paths alongside the happy path.
Outcome
A more dependable orchestration model connecting device activity to real-time processing and downstream consumers.
The real world does not retry cleanly. Connected systems need to be designed around that fact.
03 / About
I like the bugs that live between layers.
I'm a Principal Software Engineer with roots in C# and .NET and a habit of following problems beyond the edge of a single codebase. That has taken me through distributed systems, authentication, production AI, infrastructure, real-time data, and the awkward boundary between software and physical devices.
Alongside industry work, I teach Big Data to postgraduate students at ISEP. Teaching keeps me honest: if I cannot explain a system clearly, I probably do not understand it well enough yet.
- 01Stay hands-on enough to know where the abstractions leak.
- 02Make production constraints part of the architecture conversation.
- 03Explain the system clearly — teaching is a useful test of understanding.
04 / Field notes
Thinking in public.
Practical notes from difficult engineering work — shared as decisions, trade-offs, and debugging trails rather than polished theory.
When SerialPort.Open() isn't the bug
A serial device opened through a raw Windows handle. The same device failed through .NET. The useful question was no longer “why can't the port open?” — it was “what does the abstraction do immediately after it opens?”
Isolating the Win32 calls showed that opening the handle and reading its DCB state both succeeded. The failure appeared when the stack tried to clear DTR, returning Windows error 31. That moved the investigation away from permissions and port ownership and toward an unsupported device-control operation.
A different serial implementation could open the same port because it did not make exactly the same assumptions. The lesson is broader than serial communication: when two abstractions disagree over the same resource, trace the smallest successful operation and then find the first extra thing the failing abstraction does.
Takeaway
The abstraction can fail after the resource is already open.
Next in the notebook
Production AI is systems engineeringModernizing .NET without betting the product05 / Contact
Have a hard systems problem?
I'm always interested in thoughtful conversations about architecture, applied AI, identity, integrations, and the work of getting software into production.