Engineering case study

How I built FieldOps:
from the problem to a
complete platform.

A full-stack project designed to showcase architecture, product thinking, quality and technical decisions in a real-world operations system.

Full StackProduct designSystem designSpec-driven development
FieldOps architecture: Angular applications (staff portal, technician experience and customer portal) connected to a .NET 10 API with Application (CQRS), Domain (DDD) and Infrastructure (EF Core) layers, persisting to PostgreSQL and file storage. CI/CD with GitHub Actions, Docker, auditing and role-based permissions.
Angular 22.1
Modern, reactive frontend
.NET 10
Robust, scalable API
PostgreSQL
Reliable relational data
50 domain entities
Complete domain model
3 user experiences
Staff, technicians and customers
The challenge

Model a complete operation,
not just an interface.

Manage requests, quotes, work orders, visits, technicians, invoices and payments in a single system, while keeping data isolated per organization (tenant) and permissions controlled by role.

Product

Complete, end-to-end flows.

Architecture

Clear separation between domain, application and infrastructure.

Experience

Portals tailored to staff, technicians and customers.

Architecture

A foundation built to grow.

A layered architecture that clearly separates responsibilities, eases maintenance and lets the system evolve without touching the business core.

  • Clean Architecture
    Well-defined layers with low coupling.
  • Tenant isolation
    Data isolated per organization.
  • Role-based access
    Access control by role and branch.
  • Auditable actions
    Key events are logged.
  • Versioned database migrations
    Versioned and reviewed migrations.
Technologies

Chosen for capability, not hype.

Frontend

  • Angular 22.1
  • TypeScript
  • Signals
  • RxJS
  • PrimeNG
  • SCSS

Backend

  • .NET 10
  • C#
  • CQRS
  • DDD
  • EF Core
  • REST APIs

Data & infrastructure

  • PostgreSQL
  • Docker Compose
  • GitHub Actions

Quality

  • ESLint
  • Prettier
  • Tests (unit and integration)
  • Code review
  • Audit trail
Spec-driven development

Every feature started with
explicit decisions.

Design, business rules and acceptance criteria before writing any code.

  1. Design
    Mockups and states
  2. SPEC
    Rules and scope
  3. Architecture
    Contracts and data
  4. Implementation
    Frontend and backend
  5. Audit
    QA, security and accessibility
Technical decisions

The challenges that shaped the project.

Multi-tenancy

Prevent data from leaking between organizations.

Problem decision outcome

States and transitions

Keep requests, quotes, jobs and visits consistent with each other.

Problem decision outcome

Role and branch permissions

Authorize both the interface and every server operation.

Problem decision outcome

Traceability

Log important changes without exposing sensitive information.

Problem decision outcome
Quality and delivery

Built as if it were going to production.

  • CI for frontend and backend
  • Migrations reviewed, never applied automatically
  • Per-organization isolation checks
  • Tests for permissions and critical flows
  • Visual, responsive and accessibility review
Decisions and limitations are documented too.
My contribution

I designed the product and
also built its foundations.

I defined the flows, designed the experience, modeled the domain and built the full-stack architecture, using an AI-assisted iterative process validated through technical reviews.

Want to see it in action?
Explore FieldOps live or browse the source code.
Demo project
with fictional data.