Public Dagitali projects
Repositories, packages, releases, and checks can support specific technical claims that a visitor can inspect directly.
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.
Evidence boundaries
Different experience supports different claims.
Dagitali does not collapse company-owned projects, prior professional experience, and client outcomes into one category. Each has different ownership, disclosure, and verification limits.
Closed-source Dagitali projects
Capabilities and architecture may be described only where disclosure is appropriate; inaccessible source is not presented as public proof.
Prior professional experience
Experience gained while working for other companies can inform Dagitali’s methods, but it is not represented as Dagitali client delivery or disclosed through employer, client, or confidential project details without authorization.
Dagitali client case studies
No Dagitali client case studies are currently published. Future case studies require supportable outcomes and permission appropriate to every disclosed detail.
Reusable package
ETLPlus
A Python package and command-line interface for practical extraction, validation, transformation, and loading workflows.
Evidence reviewed · Snapshot 36527c8c712f
- 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.
Relevant services
Starter demonstration
dbt Demo: Jaffle Shop
A deliberately small dbt Core repository showing example models, dependencies, schema tests, seed data, and local checks.
Evidence reviewed · Snapshot 83992a456f36
- Status
- Starter project
- Current models
- Five 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
- Five deliberately limited SQL models
- Dependencies expressed with the dbt
reffunction - Fictional seed data keeps the demonstration self-contained
- 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 suitable dbt runtime, adapter, database, and profile before execution.
Current limitations
- Seeded fictional data substitutes for production sources
- No pinned runtime, adapter, or supported database combination
- No hosted continuous-integration workflow
- No production-oriented source integration or high-complexity project features
Relevant services
Production infrastructure example
dagitali.com
The production website and its AWS infrastructure, designed as a small but complete delivery and operations example.
Evidence reviewed
- 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.
Relevant services
Visitor delivery
- BrowserRequests the HTTPS website
- CloudFrontApplies delivery controls
- Private S3Stores static content
Deployment
- GitHub ActionsStarts a reviewed workflow
- AWS OIDC roleIssues short-lived access
- Python CDKDefines and updates AWS resources
This public view intentionally omits account identifiers, resource names, role claims, and other operational details. It explains the system boundary without presenting inaccessible source as public proof.
Apply the evidence