[IDENTITY_VERIFIED]

// source: [/* latency_sensitive: true */]

[ENTRY_POINT: HOME]

[REAL WORLD BACKEND][USED IN PRODUCTION][FULL STACK WHEN NEEDED]

Kevin Martínez — Software Engineer

I design systems for when things stop being simple.

"Scaling isn't the problem. Uncontrolled complexity is."

Software Engineer primarily focused on backend, systems design, tooling, and architecture on top of .NET.

I build software that has to survive real constraints: production traffic, integrations, legacy decisions, data consistency, and operational maintenance. My primary focus is backend, systems, and architecture, but I also cover React frontend work, tooling, CI/CD, and Python services when the problem calls for it.

CASE_STUDIES INITIATE_CONTACT DOWNLOAD_CV

/* latency_sensitive: true */

[FILE: IDENTITY_LOG]

PRACTICAL ARCHITECTURE

[STANCE: ANTI_HYPE]

[MODE: OPINIONATED]

[WHAT_I_AVOID]

ARCH

- RESUME-DRIVEN DEVELOPMENT
- DISTRIBUTED MONOLITHS
- BLINDLY FOLLOWING MANIFESTOS
- OVER-ENGINEERED ABSTRACTIONS

// source: [file: identity_log]

Backend, Architecture, and decision making under constraints. I don't build for hypothetical scale; I build for predictable evolution.

I work on systems that are already running in production or will be. That means dealing with constraints, legacy decisions, real business impact, and covering multiple layers when needed: backend, data, delivery, tooling, and React UI.

Architecture is not about drawing boxes, it is about controlling how complexity evolves over time.

[MODE: OPINIONATED]

[STANCE: ANTI_HYPE]

// principles under constraints

[CORE_MANIFESTO]

[OVERVIEW_BLOCK: ACTIVE]

// source: [manifest_registry]

// foundational principles

Domain over Framework

Frameworks are implementation details. Business logic should not depend on them. If changing a framework breaks your system, the system was never properly designed.

[PRIORITY: MEDIUM]/* domain leads */

02_CRITICAL

// core principles (high priority)

Boundaries over Coupling

Shared databases are the original sin of system design. Without clear ownership and contracts, modularity is just an illusion.

[PRIORITY: HIGH]/* explicit > implicit */

// foundational principles

Simplicity before Complexity

Microservices are not a solution, they are a cost. If a monolith is not modular, distributing it will only amplify the problem.

[PRIORITY: MEDIUM]/* fewer pieces, more control */

04_CRITICAL

// core principles (high priority)

Clarity over Over-Abstraction

Not every abstraction improves a system. When it only hides explicit code, it usually adds layers, indirection, and cognitive cost without solving a real problem.

[PRIORITY: HIGH]/* less magic, more control */

// REAL SYSTEMS, REAL DECISIONS

CASE STUDIES

[SYSTEM_RECORDS: LIVE]

// source: [expandable_archive]

[CS-001]

[PRODUCTION SYSTEM]// record: summary

From Clean Architecture to a modular monolith in a multi-tenant CRM

Architectural evolution of a business backend that stopped being simple.

expand case

PROBLEM

The CRM backend had to support customer management, companies, operations, and integration with a retail ecosystem. The initial base worked, but domain growth and new integrations started to strain navigation, coupling, and maintainability.

DECISION

Evolve from a classic Clean Architecture baseline into a modular backend with explicit module contracts, CQRS, and domain events, prioritizing controlled growth over premature distribution.

C#.NET 8.NET 10MODULAR_MONOLITHCQRSDOMAIN_EVENTSMULTI_TENANT

[CS-002]

[PRODUCTION SYSTEM]// record: summary

Company onboarding orchestration with distributed consistency

Reliable company creation flow coordinating multiple systems with compensating actions.

expand case

PROBLEM

Creating a company was not a simple database operation. The flow had to generate credentials, create the user in AWS Cognito, persist the local user, create the company, and trigger credential delivery. If any step failed, the platform could end up in an inconsistent state, such as a Cognito user with no associated company.

DECISION

An orchestrated saga was implemented to execute each step in order, persist workflow state, and apply compensating actions on failure. The operation was protected against duplicate retries, and credential delivery was decoupled from the main flow through asynchronous processing.

SAGAORCHESTRATIONAWS_COGNITOOUTBOXEVENT_DRIVENCONSISTENCYIDEMPOTENCY

[CS-003]

[REAL WORLD DESKTOP]// record: summary

Mandatory updates for a production WinForms plugin

Controlled version delivery with integrity validation and release automation.

expand case

PROBLEM

Clients running outdated versions created operational inconsistencies and increased support cost. The system needed an update strategy that was reliable, automated, and hard to bypass.

DECISION

Build an automatic mandatory update system with background downloads, hash validation, and GitHub Actions / releases support, preserving operational continuity and version control.

WINFORMSAUTO_UPDATESGITHUB_ACTIONSDEVOPSDESKTOP

[CS-004]

[ARCHITECTURE MISALIGNMENT]// record: summary

Forced microservices rewrite without real context

A case where architecture was defined before the problem was understood.

expand case

PROBLEM

A legacy PHP system had to be replaced entirely with a new .NET solution. The initial decision was to move directly into a microservices architecture without validating whether the system context actually required it.

DECISION

A full rewrite based on microservices was chosen from the start, introducing multiple services, distributed communication, and higher operational complexity without a stable functional base.

MICROSERVICESLEGACYARCHITECTUREANTI_PATTERNREAL_WORLD

/* expand() to inspect constraints, decisions, and outcomes */

// PROJECTS, LIBRARIES, AND TOOLING

ARTIFACTS

[INVENTORY_MODE: ACTIVE]

// source: [build_log]

INVENTORYSYSTEM COMPONENTS// COMPONENTS I'VE BUILT

TRACK: CORE

[PRJ-001]TYPE: LIBRERIA_BACKENDSTATUS: PUBLISHED

Html2Pdf

.NET library for turning HTML into PDF when a backend needs repeatable document generation without duplicating rendering logic per project.

TECHNICAL_DETAILS

Solves document generation from HTML templates without rebuilding rendering pipelines in every system.
Uses RazorLight and PuppeteerSharp to keep output consistent for reports, receipts, and operational documents.
Fits service flows, jobs, or batch processes where PDF is a cross-cutting capability instead of an isolated feature.

STACK

.NET 8 · C# · RazorLight · PuppeteerSharp

DISTRIBUTION

OPEN_NUGET

REPO

Html2Pdf

INTENT

Turn PDF generation into reusable backend infrastructure for systems that produce documents under business rules.

[PRJ-002]TYPE: LIBRERIA_BACKENDSTATUS: PUBLISHED

SimpleMediator

Lightweight Mediator/CQRS implementation for .NET for systems that need command/query separation without paying for ornamental complexity.

TECHNICAL_DETAILS

Solves common boilerplate in .NET applications built around handlers, requests, and simple composition.
Exists to keep write/read boundaries explicit without depending on heavier packages when the problem does not justify them.
Used in modular backends, business APIs, and internal libraries where structural clarity matters more than endless extension points.

STACK

.NET 8 · C# · CQRS · Mediator

DISTRIBUTION

OPEN_NUGET

REPO

SimpleMediator

INTENT

Reduce accidental overhead in small and medium CQRS implementations while keeping the structure explicit.

[PRJ-003]TYPE: HERRAMIENTA_CLISTATUS: PUBLISHED

Flask Forge CLI

CLI for bootstrapping Flask projects when Python is the right runtime for a service or developer tool and the starting point must stay consistent.

TECHNICAL_DETAILS

Solves repetitive project setup by generating structure, conventions, and baseline configuration ready to evolve.
Exists to avoid inconsistent manual setup and to shorten the path from idea to working service.
Used for small APIs, internal utilities, or tools where Python/Flask fits the problem better than forcing the primary stack everywhere.

STACK

Python · Flask · Typer · Jinja2 · SQLAlchemy · Alembic

DISTRIBUTION

OPEN_PYPI

REPO

Flask Forge CLI

INTENT

Standardize the starting point of Flask projects and make setup a repeatable operation.

[PRJ-004]TYPE: FRONTEND_LIBRARYSTATUS: PUBLISHED

light-query

React hooks library for remote data flows with a small API and a deliberate focus on reducing integration noise.

TECHNICAL_DETAILS

Wraps fetch, loading states, and basic synchronization so components do not repeat transport plumbing.
Keeps the surface area intentionally small for teams that want control without adopting a heavier caching runtime.
Fits React frontends where clarity of integration matters more than maximizing abstraction coverage.

STACK

React · TypeScript · NPM

DISTRIBUTION

OPEN_NPM

REPO

light-query

INTENT

Simplify API consumption in React without hiding the actual data flow or adding accidental complexity.

[PRJ-005]TYPE: FRONTEND_TEMPLATESTATUS: PUBLISHED

react-clean-architecture-template

Opinionated template for creating Clean Architecture React SPAs with Vite, TypeScript, and production-minded defaults through a scaffolding CLI.

TECHNICAL_DETAILS

Generates a feature-first structure with app, features, shared, unit tests, integration tests, and E2E tests from the start.
Includes React 19, TanStack Query, Zod-based environment parsing, Result/Error primitives, OpenTelemetry-ready observability, and in-memory repositories for local development.
Ships feature scaffolding commands, Storybook for shared UI, and contract tests to protect architecture rules.

STACK

React 19 · TypeScript · Vite · TanStack Query · Zod · Vitest · Playwright · Storybook

DISTRIBUTION

CLI / npm create @nastmz/clean-react

REPO

react-clean-architecture-template

INTENT

Turn React SPA bootstrap into a repeatable foundation with clear boundaries, layered testing, and fewer accidental decisions per project.

[PRJ-006]TYPE: BACKEND_TEMPLATESTATUS: PUBLISHED

dotnet-clean-template

Native .NET template pack that bootstraps Clean Architecture projects through `dotnet new`, avoiding repeated base structure, cross-cutting decisions, and setup work in every backend.

TECHNICAL_DETAILS

Generates an opinionated foundation with Application, Domain, Infrastructure, SharedKernel, Web.Api, and ArchitectureTests ready to evolve.
Includes JWT authentication, PBKDF2 hashing, EF Core with PostgreSQL, Problem Details, health checks, and validation/logging decorators without depending on MediatR.
Provides two starting points: one oriented to Docker Compose for local infrastructure and another based on .NET Aspire for orchestration and service defaults.

STACK

.NET 10 · C# · Clean Architecture · EF Core · PostgreSQL · JWT · Docker Compose · .NET Aspire

DISTRIBUTION

OPEN_NUGET

REPO

dotnet-clean-template

INTENT

Turn .NET API bootstrap into a repeatable operation with consistent architectural standards and less accidental boilerplate.

TRACK: EXPERIMENTAL

[PRJ-007]TYPE: FRONTEND_FRAMEWORKSTATUS: PUBLIC_EXPLORATION

Vanilla SPA

Dependency-free SPA architecture used to test routing, state, and UI composition on top of browser-native APIs.

TECHNICAL_DETAILS

Measures how much runtime a framework is actually buying compared with an organized native baseline.
Implements routing, a reactive store, and component composition with ES Modules and minimal tooling.
Has a public deployment, but the main role is frontend architecture exploration rather than general production adoption.

STACK

JavaScript · HTML · CSS · Vite · ES Modules

DISTRIBUTION

OPEN_DEMO

REPO

Vanilla SPA

INTENT

Explore how far a real SPA can be pushed with native primitives before introducing a framework.

[PRJ-008]TYPE: BACKEND_FRAMEWORKSTATUS: PUBLIC_EXPLORATION

mini-php-framework

PHP micro-framework for exploring a minimal core with routing, middleware, and SQLite persistence under PSR conventions.

TECHNICAL_DETAILS

Isolates the basics of a request pipeline without starting from a full framework stack.
Uses PSR standards to preserve interoperability while testing a deliberately small and explicit base.
Has Packagist distribution, but its role is to investigate lightweight framework decisions rather than package a closed platform.

STACK

PHP 8.4+ · PSR-4/12/15 · SQLite

DISTRIBUTION

OPEN_PACKAGIST

REPO

mini-php-framework

INTENT

Test the minimum viable set of backend framework decisions to understand the real cost of abstraction in PHP.

// ARCHITECTURAL DECISIONS

DECISION LOG

[LOG_STORE: HOT]

// source: [log_store: permanent]

[DL-001]

[STATUS: ACCEPTED]

[CONTEXT: ARCHITECTURE]

Modular monolith before premature microservices

As the system grew, the real need was to control boundaries and internal navigation, not to distribute problems across the network. Explicit modularity was prioritized before physical extraction.

[TRADE-OFF]

IMMEDIATE_DISTRIBUTION ↓ / COMPLEXITY_CONTROL ↑

[DL-002]

[STATUS: ACCEPTED]

[CONTEXT: DOMAIN_MODEL]

CQRS to isolate domain evolution

The same model no longer served equally well for business rule writes and operational reads. Separating reads and writes made domain changes safer.

[TRADE-OFF]

STRUCTURAL_COMPLEXITY ↑ / DOMAIN_CLARITY ↑

[DL-003]

[STATUS: DEPRECATED]

[CONTEXT: DATA_ACCESS]

Shared data access across modules

Sharing tables or bypassing module boundaries looked practical, but it hid dependencies and made local changes unsafe.

[TRADE-OFF]

LOCAL_SPEED ↓ / SYSTEM_SAFETY ↑

[DL-004]

[STATUS: ACCEPTED]

[CONTEXT: DISTRIBUTED_FLOW]

Orchestrated saga for onboarding with multiple side effects

When creating a company touches identity, database state, and notifications, a local transaction is no longer enough. Explicit orchestration, compensations, and idempotency were prioritized over accidental consistency.

[TRADE-OFF]

ORCHESTRATION_COMPLEXITY ↑ / BUSINESS_CONSISTENCY ↑

[DL-005]

[STATUS: EVALUATING]

[CONTEXT: OBSERVABILITY]

OpenTelemetry as a common observability language

When each component explains failures differently, diagnostics under pressure become expensive. Unifying traces and metrics improves system readability.

[TRADE-OFF]

SETUP_COST ↑ / DIAGNOSTIC_TIME ↓

/* explicit decisions beat implicit complexity */

// TECHNOLOGIES & TOOLS

STACK PROTOCOLS

[STACK_AUDIT: CURRENT]

// source: [stack: evolving]

[CORE_RUNTIME]

C# / .NET

Primary environment for backend, APIs, and system design with focus on structural clarity and controlled evolution.

[DATA]

SQL Server / PostgreSQL / MySQL

Relational modeling, query optimization, and support for production systems across different operational contexts.

[ACCESS_LAYER]

EF Core / Dapper

A balance between productivity and control depending on the access pattern and the level of precision the system needs.

[CLOUD]

AWS

Use of SNS, Cognito, S3, and SES for messaging, authentication, and infrastructure support in distributed flows.

[CLOUD]

Azure

Use of Azure DevOps, Application Insights, SQL Server, PostgreSQL, Cosmos DB, Virtual Machines, App Service, and API Management in enterprise environments and real delivery cycles.

[DELIVERY]

GitHub Actions / Azure DevOps / Docker

Automation of builds, deployments, and version control in production, with focus on repeatability and operational continuity.

[OBSERVABILITY]

OpenTelemetry / Application Insights

Tracing and monitoring for technical diagnosis in distributed systems and environments with multiple integrations.

[FRONTEND]

React / Next.js

Real frontend and full stack experience for building complete solutions when the context requires going all the way to the interface layer.

[ALTERNATIVE_RUNTIME]

Python / Django / Flask

Used in tooling, APIs, and scenarios where the problem or team requires going beyond the main stack without losing technical consistency.

/* the stack follows the problem, not the vendor */

// observations under load

BUFFER OVERFLOW

[FIELD_NOTES: OPEN]

// source: [opinions]

[N-001]

"Microservices do not fix a poorly designed system."

They only distribute the cost of bad decisions.

If a team still does not control boundaries, data, and dependencies inside a monolith, splitting it into services adds coordination, network overhead, and more failure points.

[N-002]

"Architecture is not drawing boxes."

It is deciding which complexity is worth paying for.

A lot of diagrams look fine until production happens. Useful architecture shows up when changes are still possible months later.

[N-003]

"Clean Architecture alone will not save you."

Neat folders do not replace real boundaries.

You can have very clean layers and still be trapped in a fragile system if everything ends up knowing too much about everything else.

[N-004]

"Most systems do not die in a crash."

They die when every change becomes slow and expensive.

Software can stay online for months while losing maintainability, clarity, and speed of evolution. That deterioration is also failure.

[N-005]

"The stack matters less than the ability to use it with judgment."

Technology without judgment only changes the type of problem.

I am not interested in defending tools like a religion. I care about choosing them according to constraints, costs, and system shape.

[N-006]

"Knowing a language is not the same as solving problems."

Technology ≠ judgment.

You can master a framework and still not understand how to build a system. Tools change; modeling, boundaries, and evolution problems do not. If your value depends on one specific technology, it is fragile. Judgment is what actually scales across contexts.

// initiate terminal handshake

READY TO SCALE WITHOUT THE DRAMA?

// source: [initiate_handshake]

[CONTACT_PROTOCOL]

If you need systems that remain maintainable as they grow, we should talk.

terminal://contact-protocol

[boot] contact terminal ready :: secure handshake available

fill identity and endpoint to launch your mail client with the payload preloaded