Hey there,I'm Alejandro Arias.

01 · Problem

Laboratorio de Inyección Castro Solís, a real diesel and gasoline fuel-injector lab, was running on a legacy FoxPro/DBF system — tables named INVEN01 through INVEN08 — with no dedicated IT staff and unreliable internet. They hired me directly, as freelance work, to replace it with something a non-technical operator could run fully offline, trust for audit purposes, and restore themselves if something broke.

02 · Process

• Movement-sourced inventory. Stock is never stored as a column — it's always derived from an append-only movement history. Cancelling a sale doesn't delete or edit a record; it creates a linked reversal movement, so the audit trail is permanent.
• Concurrency-safe by design. Every confirm/cancel operation row-locks with select_for_update() inside an atomic transaction and re-validates the state machine before touching stock — no race conditions on double-confirm or double-cancel.
• Backups that prove themselves. A dump → restore-and-validate → checksum pipeline discards any backup that fails a step. The rule the system enforces: a backup only counts once it has been restored and verified, not just written to disk.
• Shipped on real Windows hardware. Packaged with WSL2 and a real Docker Engine inside an Electron shell. Debugging this in production surfaced an intermittent failure where WSL2 silently powered off the whole distro — traced through system logs to a missing keep-alive process, fixed, then hardened again after a recurrence.
• A real legacy migration, not a data dump. DBF records move through staging, validation, normalization, import and stock reconciliation, tracked in dedicated migration-audit tables so legacy identifiers never leak into the production schema.

03 · Solution

Django 5.2 + DRF on PostgreSQL 17, split into service and selector layers per domain (inventory, sales, purchasing, service tracking). 372+ automated backend tests, 16+ internal docs covering architecture, security and disaster recovery, and real barcode label printing. It's the lab's day-to-day system today — a paid deliverable running their actual operations offline, not a demo.

01 · Problem

Cuero&Perla, a jewelry retailer in Grecia, Costa Rica, needed to run in-store sales, credit sales to regular customers and a public online catalog off of what was effectively paper receipts and a notebook of IOUs. They commissioned this as paid freelance work — I designed, built and still maintain it.

02 · Process

• Mixed-payment reconciliation. A single sale can split across cash, card and transfer — the backend tracks each amount separately and reconciles all three tender types plus credit payments and misc income into one daily total.
• Two-phase cash closing. Sales land in a same-day staging table first; closing the register atomically migrates only the cash sales into the permanent ledger, locks the day's credit payments, and writes an immutable closing snapshot — a real point-of-no-return, the way a physical cash drawer closes.
• Accounts receivable that doesn't conflate a payment with a return. A real payment and a credit-note return touch the balance differently, so they're kept as separate, audited operations instead of one generic "reduce balance" function.
• Composite products with cycle protection. Jewelry "sets" compute availability as the minimum ratio across their components and run a recursive check so a set can never reference itself through another set.
• Thermal receipt printing over WebUSB. Talks directly to the store's receipt printer with raw ESC/POS byte sequences, falling back to browser printing when WebUSB isn't available.

03 · Solution

19 backend models, cookie-session auth with role-based permissions, Cloudinary images, transactional email and web push, Excel exports. Separate unit, integration and performance test suites. 810 commits over 9 months, deployed on Railway and Vercel — sold, shipped and in daily use, not a portfolio demo.

01 · Problem

Beauty salons scheduling by phone, paper and WhatsApp run into the same three failures every time: double-booked stylists, no-show losses from forgotten reminders, and no single source of truth when more than one person manages the calendar. I designed EsteticaPro as a SaaS-shaped platform from day one, architected so it could be commercialized later.

02 · Process

• Conflict prevention lives in the model, not a form check. The appointment's end time is computed from the service duration and an overlap query runs on every save, scoped to that stylist — enforced at the model layer, so no code path can create a double-booking.
• The "available slots" endpoint reuses the same overlap logic. Instead of a separate rules engine, it walks the workday in 30-minute increments and asks the identical conflict query — one source of truth for both blocking and suggesting.
• A real notification queue, not fire-and-forget. Reminders carry explicit pending/sent/failed states, and a scheduled worker polls every minute to dispatch and retry across email and WhatsApp — durable, not a best-effort background task.
• Row-level access control. Admins and receptionists see everything; an esthetician's queryset is hard-scoped to their own appointments — permission logic that filters data, not just gates endpoints.
• WhatsApp behind a swappable service class. Notifications go out through a self-hosted gateway today, isolated behind one interface so switching providers later doesn't touch the scheduling code.

03 · Solution

JWT-authenticated Django REST API with a role-based React/TypeScript frontend, Celery + Redis background processing wired to a live WhatsApp gateway, and a revenue-aware dashboard. The README is candid that WhatsApp Business API approval — not the engineering — is the one blocker left before this could be sold, which matters more to a hiring manager or client than pretending it's already launched.

01 · Problem

University course management fragments across email, spreadsheets and paper — professors juggling deadlines and grading across courses, students losing track of what's due where, and no record of who changed what. I built NexoAcadémico to centralize it with real role-based workflows and an actual audit trail.

02 · Process

• RBAC enforced at the queryset level, not just the endpoint. Every viewset filters by ownership before returning data — professors only ever see their own courses, students only their enrollments — and mutations re-check permission before writing, so ownership is a write gate, not just a filter.
• Soft delete with a real history, not framework magic. Deleting a task flips status flags instead of removing the row, and every create, update and delete writes a history record exposed through its own endpoint — "who did what when" is an actual answer, not a guess.
• Submission and grading modeled with distinct actor rules. A student can create exactly one submission per task; only that course's professor can grade it, and the server — not the client — forces the status to reviewed and stamps the time.
• A hand-rolled WebGL shader for the UI, not a CSS blur. The "liquid glass" interface effect is a real GLSL fragment shader — signed-distance-field rounding, noise, refraction — registered per component against actual DOM positions.
• Documented its own rough edges. The database docs flag which stored procedures are stale from an earlier schema — the kind of honesty about technical debt most solo projects don't bother writing down.

03 · Solution

Token-authenticated Django REST API with a full Next.js 16 App Router frontend — courses, enrollment, weighted/graded tasks, file submissions, grading and feedback, plus dashboard and statistics endpoints doing real server-side aggregation. Same engineer designed the data model and built the UI that consumes it, including its own custom animation-token system.