Skip to main content

Open to software engineering roles and product work

Software Engineer building systems that reach production.

Backend systems, cloud applications, artificial intelligence and product development. Creator of monetised SaaS and commerce products, with nearly three years of experience evaluating and improving AI-generated technical solutions.

Explore selected workAll case studies
Focus
Building production software across SaaS, commerce, and AI
Location
Guatemala City, Guatemala

System map

Conceptual

UsersClientMobileAPIIdentityInferenceDatastoreEventsPayments
Conceptual system map. Verified architecture for each product is documented in its case study.

Beyond prototypes

Software that shipped, and kept running.

Selected work includes products that are publicly deployed, used in real business workflows, and generating revenue.

  • 2

    Monetised personal products

    SpendSync and The Rollecito — both publicly deployed and taking payments through Stripe.

  • ~3 yrs

    AI training and technical evaluation

    Reviewing AI-generated engineering work across backend, databases, concurrency and architecture.

  • 4 domains

    Production deployments

    SaaS, commerce, cloud infrastructure and machine learning — deployed, not demonstrated.

Featured products

Two products in production, paid for by the people who use them.

Both are publicly deployed, take payments through Stripe, and are maintained by the person who built them. Each case study documents the architecture and the decisions behind it.

app.spend-sync.com
SpendSync landing page on desktop, headline reading 'Split bills effortlessly with friends' with Get Started and Learn more actions.
app.spend-sync.com — public landing page
Live · Subscription productRevenue-generating

SpendSync

Monetized SaaS · Shared Expense Management

A subscription SaaS for shared households: recurring bills, split expenses, invitations and settlement, running in production on AWS.

  • Two parallel billing systems: recurring service bills and one-off split transactions
  • Invitation and response flow — a participant is added to a bill only after accepting
  • Monthly cycle payments, partial settlement and reopening of finalised bills
  • Stripe Checkout for subscription purchase plus a Stripe billing portal for self-service management

Stages

  • Idea
  • Build
  • Deploy
  • Operate
  • Monetise
  • React
  • Redux Toolkit
  • Express
  • MySQL
  • Socket.IO
  • Amazon Cognito
  • +2
Read the case studyOpen live productView source
app.therollecito.com
The Rollecito storefront on desktop, headline reading 'Freshly Baked Happiness in Every Roll' with Order Now and View Menu actions.
app.therollecito.com — customer storefront
Live · Commerce productRevenue-generating

The Rollecito

Revenue-Generating Commerce Product

A multi-location ordering platform for a working bakery: online catalogue, Stripe checkout, live order tracking and a real-time kitchen display.

  • Location-scoped catalogue: menus, availability and pricing resolve per branch
  • Configurable products with option groups and option values, not flat SKUs
  • Stripe payment intents with webhook confirmation and idempotent payment tracking
  • Guest checkout alongside Firebase-authenticated accounts

Stages

  • Architecture
  • Build
  • Deploy
  • Operate
  • Monetise
  • React
  • Node.js
  • Express
  • MySQL
  • Stripe
  • Socket.IO
  • +3
Read the case studyOpen live productView source

Selected engineering work

Machine learning, computer vision, concurrency and architecture.

All case studies

Academic and study projects, labelled as such. Included for the engineering reasoning rather than the deployment status — each one documents a decision that was genuinely difficult.

  • Academic · Deployed on AWS

    Medical Condition Classification Platform

    Machine Learning · Health Technology · Cloud Deployment

    A Random Forest classifier over institutional healthcare data, served through a Flask API on AWS, evaluated honestly as a top-N ranking problem rather than a single-answer one.

    Key decision

    Evaluate as a top-N ranking task rather than single-label classification

    • Architecture
    • Build
    • Deploy
    • Python
    • scikit-learn
    • Flask
    • MySQL
    • AWS EC2
    • +2

    Read the case study

  • Academic · Working prototype

    Real-Time Hand-Sign Recognition Backend

    Computer Vision · Real-Time Inference · Backend Engineering

    A modular computer-vision backend that detects a hand through a webcam and classifies numerical signs from 1 to 10, stabilising per-frame predictions with a mode window.

    Key decision

    Stabilise output with a mode-based smoothing window

    • Build
    • Operate
    • Python 3.11
    • OpenCV
    • MediaPipe
    • scikit-learn
    • Flask
    • +1

    Read the case study

  • Academic · Reference implementation

    Secure Authentication System

    Full Stack · Security · Identity

    A full-stack JWT authentication system with short-lived access tokens, refresh tokens in HttpOnly cookies, and role-based route protection on both sides of the trust boundary.

    Key decision

    Keep the access token in memory and the refresh token in an HttpOnly cookie

    • Architecture
    • Build
    • TypeScript
    • Node.js
    • Express
    • React
    • Vite
    • +3

    Read the case study

  • Engineering study

    Rust and Dart FFI Database Initialisation Refactor

    Systems Engineering · Rust · Concurrency

    A database-initialisation refactor that stops a cancelled Dart FFI call from abandoning SQLite migrations mid-flight and leaving locks behind.

    Key decision

    Move migrations onto a blocking task instead of running them on the async executor

    • Architecture
    • Build
    • Rust
    • Tokio
    • SQLite
    • Dart FFI

    Read the case study

  • Architecture study · Not deployed commercially

    Resilient Edge Toll-System Architecture

    Edge Computing · Distributed Systems · Architecture

    An architecture for toll lanes that must decide in under 200 milliseconds and keep operating when the link to the cloud is gone.

    Key decision

    Make the lane authoritative and treat the cloud as a consumer

    • Idea
    • Architecture
    • .NET Core
    • SQLite
    • MQTT
    • OCR
    • RFID
    • +1

    Read the case study

Approach

How a system gets from idea to revenue

Six stages, in the order they actually happen. The rail beside this page tracks them as you read.

  1. 01Idea

    A problem someone actually has, stated precisely enough to be wrong about.

    Start from the operational problem, not the feature

    The bakery's problem was not that it lacked a website — it was that orders arrived as handwritten notes and the kitchen had no queue. Naming the operational failure first is what decides which system to build.

  2. 02Architecture

    Deciding where the decisions live, and what each layer is allowed to assume.

    Put invariants at the last layer everyone passes through

    If three callers can write the same row, a rule in one of them holds for one of them. Order state transitions belong in the database; consent belongs in the schema. Rules enforced by convention are rules until someone is in a hurry.

  3. 03Build

    The implementation, including the parts that are only interesting when they fail.

    Delegate the parts that are worst to get wrong

    Identity, card handling and mail deliverability are unforgiving and undifferentiated. A single maintainer gets more out of integrating them well than out of reimplementing them adequately.

  4. 04Deploy

    Getting it in front of people, reproducibly.

    Make deployment boring, then put a brake on it

    Containerised builds and a pipeline that runs the same way every time — with a manual approval in front of the system that takes real payments. Speed is worth less than knowing exactly what is about to happen.

  5. 05Operate

    What happens on day two hundred, with real data and no supervision.

    Design for the second year

    Late payments, duplicate webhooks, cancelled calls, a cycle that has to reopen. Most of the engineering that matters is about states the happy path does not contain.

  6. 06Monetise

    Charging for it, which is the only test that says whether it was worth building.

    Pricing is a design constraint

    Deciding what belongs in a free tier forces a clear answer about which part of the product is genuinely valuable — and where it costs money to run. It is a product decision that lands squarely on the schema.

Experience

Engineering experience

Nearly three years reading other people's engineering work closely enough to say precisely why it is right or wrong.

AI Training and Technical Evaluation

~3 years

Confidential engagement

Evaluating AI-generated technical work across software engineering, backend systems, databases, concurrency, architecture and advanced implementation tasks.

  • Assess AI-generated software solutions for technical correctness, not just plausibility
  • Compare competing implementation strategies and articulate why one is preferable
  • Identify incomplete, inconsistent or subtly wrong solutions that read as convincing
  • Judge code quality and engineering depth beyond whether the code runs
  • Analyse multi-turn problem-solving behaviour across an extended technical exchange
  • Write detailed technical feedback that explains the reasoning, not only the verdict

Domains

  • Rust
  • CUDA
  • Distributed systems
  • Databases
  • Backend architecture
  • Concurrency
  • Artificial intelligence

Independent Product Engineer

2025 — present

SpendSync · The Rollecito

Building and operating two products end to end: product definition, architecture, implementation, deployment, payments and ongoing operation.

  • Own the full path from problem statement to a deployed system taking real payments
  • Design relational schemas and the authorisation rules that protect them
  • Integrate managed identity and payment providers rather than rebuilding them
  • Provision and operate production infrastructure on AWS
  • Maintain systems after launch, including the parts that only fail under real usage

Domains

  • Node.js
  • React
  • MySQL
  • Stripe
  • AWS
  • Docker
  • Real-time systems

Both roles come down to the same habit: separating work that looks correct from work that is correct.

Capabilities

Technical capabilities

Grouped by what they are used for. Every area below appears in at least one project on this site.

  • Backend and APIs

    Where most of the work lives: request handling, authorisation and the rules that protect data.

    • Python
    • Flask
    • Node.js
    • Express
    • TypeScript
    • C#
    • .NET Core
    • REST APIs

  • Artificial intelligence

    Training, evaluating and — as often — deciding that a model is not good enough for the job as framed.

    • scikit-learn
    • Random Forest
    • AI training and evaluation
    • Model evaluation
    • Feature engineering

  • Computer vision

    Real-time pipelines where the engineering problem is stability over frames, not accuracy on one.

    • OpenCV
    • MediaPipe
    • Real-time inference
    • Landmark extraction
    • Prediction smoothing

  • Cloud and infrastructure

    Provisioning and operating the environments the products above actually run in.

    • AWS EC2
    • AWS RDS
    • Amazon S3
    • Application Load Balancer
    • Route 53
    • ACM
    • Docker
    • Linux

  • Databases

    Relational modelling, and putting invariants at the layer that every caller has to pass through.

    • MySQL
    • PostgreSQL
    • SQLite
    • Relational modelling
    • Migrations
    • Query design

  • Systems and architecture

    Concurrency, message transports and deciding where a system's decision boundary belongs.

    • Rust
    • Tokio
    • MQTT
    • NATS
    • Distributed systems
    • Edge computing
    • Event-driven architecture
    • FFI
    • Concurrency

  • Frontend

    Enough to build and ship the interfaces these products need, on the devices customers use.

    • React
    • Vite
    • TypeScript
    • Responsive interfaces

About

Engineering that outlives the launch.

Software Engineer and Computer Science and Systems Engineering graduate from Universidad de San Carlos de Guatemala. My work combines product development, backend engineering, cloud infrastructure, artificial intelligence, computer vision and distributed systems.

What I care about is the part most portfolios skip: what a system does on its second year, when the data is messy, the payment webhook arrives twice, and the person maintaining it is the same person who wrote it. Two of the products here are ones I still operate — which is a very different relationship with your own code than shipping it and moving on.

I am especially interested in building reliable systems that solve real operational problems and continue creating value after deployment.

Education

  • Computer Science and Systems Engineering

    Universidad de San Carlos de Guatemala

    Coursework completed

    Official university degree currently in process.

Contact

Have a product, system, or engineering problem worth solving?

Open to software engineering opportunities, technical collaborations, and product-focused development.

Send a message and I will reply from the address you provide.

No submission backend is configured, so this opens your email client with the message prepared.