Systems shaped by operational constraints

I describe each system through its context, my responsibility, architecture decisions, constraints, and current verified state.

01 · Architecture decisions

Businext ERP

An ERP platform bringing finance, sales, inventory, human resources, dashboards, and accounting workflows into one operational model.

Current verified state

The platform provides a maintainable foundation for continuing enterprise-system evolution across the documented operational domains.

Context

Businext originated inside a real business operation that initially relied on a legacy POS system developed in C# and running on physical servers. That system presented technological limitations, vendor dependency, and difficulties evolving toward new operational requirements. A first web version was later developed using Web2py focused on sales and inventory. Although this version still operates certain processes such as point-of-sale and stock control, its functional evolution stopped. Based on that experience, Businext ERP was created as a new platform designed to progressively replace previous systems and centralize the company's operational infrastructure.

What it solves

Businext ERP is an ERP platform bringing finance, sales, inventory, human resources, dashboards, and accounting workflows into one operational model.

Current verified state

Reduced process fragmentation by consolidating administrative workflows in one operational model.
Made finance, sales, inventory, and HR changes easier to reason about through explicit service boundaries.
Created a maintainable internal ERP foundation that can absorb new modules without reworking the whole platform.

My responsibility

I design and lead backend and systems evolution around the business rules, service boundaries, and operational constraints that the platform must preserve.

Architecture decisions

Domain boundaries defined for finance, inventory, HR, sales, and accounting.
API-first architecture that enables explicit workflows and independent module evolution.
Modular FastAPI backend with clear service layers for business rules.
Infrastructure organized around AWS, Linux, and Nginx with clear operational boundaries.

Constraints

Cross-domain workflows must remain coherent while the ERP evolves without making every change a platform-wide regression.

Technical challenges

Keeping accounting and inventory rules isolated while still supporting cross-domain workflows.
Evolving a multi-domain ERP without turning every new feature into a platform-wide regression.
Designing APIs and modules that match the business process instead of mirroring database tables.

Technology context

Python · FastAPI · React · MySQL / MariaDB · REST APIs · AWS · Linux · Nginx

02 · Architecture decisions

TR0V1 Credit Platform

A credit platform organized around installments, interest, payments, reconciliation, and account statements.

Current verified state

The platform is organized around traceable financial workflows and explicit rules for credit lifecycle operations.

Context

TR0V1 was created to support a credit-management operation. The platform needed to manage credit lines, installments, interest, payments, and account statements while maintaining financial consistency. The system evolved from an earlier Web2py implementation toward a modern architecture using FastAPI and React, with the domain rules and migration constraints made explicit.

What it solves

TR0V1 is a credit platform organized around installments, interest, payments, reconciliation, and account statements.

Current verified state

Made credit lifecycle rules explicit across charges, billing periods, payments, and statements.
Improved operational control by detecting reconciliation differences early.
Delivered a backend platform supporting both internal operations and client visibility.

My responsibility

I work on the architecture and backend evolution that turns financial rules and state transitions into explicit services and APIs.

Architecture decisions

Backend focused on financial business rules and state transitions.
Domain modeling for credit accounts, payment flows, and interest calculations.
APIs consumed by both internal administrative tools and client interfaces.
Architecture designed to preserve financial consistency in critical operations.

Constraints

Retries, partial payments, interest calculations, and reconciliation create failure modes that simple CRUD cannot represent safely.

Technical challenges

Preventing duplicate financial events during retries and asynchronous flows.
Maintaining balance consistency over time with partial payments and interest calculations.
Designing services that represent financial workflows instead of simple CRUD operations.

Technology context

Python · FastAPI · SQLAlchemy · React · REST APIs

03 · Architecture decisions

Workforce

An independent workforce-management product in active development.

Current verified state

Workforce is an independent workforce-management product in active local development.

Context

Its current local implementation covers a secure multi-organization foundation, People and Employee management, and configuration of organizational structure and work schedules.

What it solves

Workforce uses FastAPI, React and PostgreSQL with server-derived organization context, tenant isolation, audited mutations, idempotency, and versioned schedule and policy configuration.

Current verified state

The local implementation covers Foundation, People / Employees, and Structure / Scheduling.
Workforce remains separate from the Businext and TR0V1 system narratives.
Workforce is not production software.

My responsibility

I shape the system design and implementation direction around organization context, authorization, data integrity, and auditable operational workflows.

Architecture decisions

Modular-monolith direction with an API-first backend and a separate web frontend.
PostgreSQL is the transactional core; organization context is derived on the server and RLS provides defense in depth.
User, Membership, and Employee responsibilities remain separate in the system model.
Audited mutations, idempotency, optimistic concurrency, and versioned organizational and scheduling configuration support reliable workflows.
Foundation covers BFF/Cognito integration, an HttpOnly session, CSRF, organization selection, AuthenticationContext to TenantContext, PostgreSQL roles, and RLS.
People / Employees covers employee lifecycle operations, User / Employee separation, auditability, idempotency, ETag-based optimistic concurrency, and employment periods.
Structure / Scheduling covers worksites, departments, positions, effective assignments, versioned timezones, policies, schedules, schedule segments, lifecycle operations, date/timezone-aware resolution, and administrative UI.

Constraints

The architecture is designed for local development scope; Workforce is not production software.

Technical challenges

Keeping organization context explicit across authorization and workflow operations.
Designing people and scheduling workflows that remain auditable as responsibilities evolve.
Keeping current local implementation scope distinct from future product capabilities.

Technology context

FastAPI · React · PostgreSQL