Technical work

Inspect the engineering, including its boundaries.

These profiles describe public Dagitali projects and this website’s production architecture. They are engineering examples, not client case studies, and each profile distinguishes demonstrated capability from planned or unsupported scope.

Reusable package

ETLPlus

A Python package and command-line interface for practical extraction, validation, transformation, and loading workflows.

Status
Stable public v1.x line
Primary interface
Python API and CLI
Supported Python
3.13 and 3.14

Challenge

Compose, check, document, and operate common extraction, transformation, validation, and loading work through a consistent library and command-line surface.

Design choices

  • Python package and CLI interfaces
  • Configuration validation and dependency-graph inspection
  • File and REST extraction and loading paths
  • External cron or systemd scheduling rather than a hidden scheduler

Verification

  • Automated continuous integration and pull-request gates
  • Coverage reporting
  • Documented stable contract and compatibility policy
  • Versioned release and maintainer guidance

Operations

  • Run history and reports
  • Local read-only history interface
  • Scheduling helpers for external operation
  • Explicit support and maintenance documentation

Current limitations

The repository identifies placeholder database execution paths and stubbed handlers rather than presenting them as supported behavior. Those paths are not part of the demonstrated capability.

Starter demonstration

dbt Demo: Jaffle Shop

A deliberately small dbt Core repository showing basic models, dependencies, schema tests, and local checks.

Status
Starter project
Current models
Two basic examples
Primary tool
dbt Core

Challenge

Show the smallest inspectable example of dbt model configuration, dependency references, schema tests, and local repository checks.

Design choices

  • Two deliberately basic SQL models
  • Dependencies expressed with the dbt ref function
  • Project configuration kept small enough to inspect directly
  • Starter scope labeled explicitly rather than implied to be production-ready

Verification

  • Unique and not-null schema tests
  • Pre-commit checks with dbt-aware hooks
  • Repository structure available for direct inspection

Operations

The repository requires the adopter to choose and configure a supported dbt runtime, adapter, database, profile, and dataset before execution.

Current limitations

  • No committed commerce dataset or seeds
  • No pinned runtime, adapter, or supported database combination
  • No hosted continuous-integration workflow
  • No production-oriented sources, snapshots, macros, or analyses

Production infrastructure example

dagitali.com

The production website and its AWS infrastructure, designed as a small but complete delivery and operations example.

Infrastructure
Python AWS CDK
Hosting
Private S3 and CloudFront
Deployment identity
GitHub OIDC to AWS

Challenge

Keep a low-traffic business website inexpensive while making its AWS architecture, deployment, security controls, and operating decisions reviewable.

Design choices

  • Private, encrypted, versioned S3 origin
  • CloudFront origin access control, TLS, compression, and explicit caching
  • ACM certificate with GoDaddy retained as the default DNS authority
  • Optional Route 53 mode for a deliberate future DNS migration

Verification

  • CDK assertions and website regression tests
  • Continuous integration before deployment
  • Post-deployment endpoint and stack-output checks
  • Security-header and deployment-readiness checks

Operations

  • GitHub Actions uses short-lived AWS credentials through OIDC
  • Deployment invalidation and rollback procedures are documented
  • Access logs and budget alerts are optional safeguards
  • Runbooks preserve repeatable administrator checks

Current limitations

The default architecture deliberately leaves authoritative DNS and email-related records at GoDaddy. It demonstrates website infrastructure and delivery—not client outcomes, generalized managed hosting, or automatic migration of external DNS services.

Apply the evidence

Bring a defined engineering problem, not a predetermined stack.

Start a conversation