Experience
  1. Jan 2025 – present

    UPLB — Digital Innovation Center · Contract · Los Baños

    Four enterprise systems built from scratch — central HR, SALN filing, asset management, and supply management — each a modular monolith talking to the others over Kafka rather than across a shared database, with HR as the system of record and every system able to run while the others are down. The two rough edges they all shared — COA form layouts and file attachments — came out as Filament plugins.

  2. Apr 2022 – Jun 2024

    Software Engineer

    UPLB — Digital Transformation Program · Contract · Los Baños

    AMIS — the university's academic and administrative records system, rebuilt as a Nuxt front-end on a Laravel REST API, including the Oracle-to-PostgreSQL migration of the legacy data and the Docker and GitHub Actions pipeline around it.

  3. Aug 2020 – Feb 2022

    Full Stack Developer

    Gleent, Inc. · Freelance · Cabuyao

    Sole developer and client contact across several engagements — an HRIS, a time-tracking system, an e-commerce platform and WordPress sites — plus a Python tool that renders ECG datasets as readable images.

  4. Nov 2019 – Jul 2020

    Junior Full Stack Developer

    Fasttrack Solution, Inc. · Makati

    Payfactor — an HR and payroll SaaS in Angular and PHP: shifts and schedules, DTR, BIR reporting and employee records, worked front to back under team code review.

System map

One writer, four readers

Five systems all needed the same answer to who someone is, what their appointment is, and which office they sit in. The easy fix is one shared personnel table everybody reads — and eventually writes to. Instead, uplb-personnel owns those records and publishes every change.

Source of truth

uplb-personnel

HR system of record

Person, appointment, position, office. Written once, here.

personnel.person.upserted personnel.appointment.changed personnel.office.changed

uplb-submission-portal

SalaryDocs+

payroll document submission

uplb-saln

SALN e-filing

annual statement filing

All four keep the same read model — person · appointment · office. None of them touches the HR database.

lead or sole author team app, integration layer mine
One writer
Personnel records get created and corrected in uplb-personnel and nowhere else. Nothing downstream owns a copy it can edit.
Events, not joins
No consumer touches the HR database. Each one subscribes and keeps its own read model, so the systems stay separately deployable.
Independent uptime
A consumer that goes down catches up from the log when it comes back. No backfill script, no outage spreading sideways.
Idempotent by key
Events are keyed by personnel id and consumers upsert, so a redelivery after a retry or rebalance is a no-op.
Technical Skills
  • JavaScript — Languages
  • TypeScript — Languages
  • PHP — Languages
  • Go — Languages
  • Python — Languages
  • React — Frontend
  • Next.js — Frontend
  • Nuxt — Frontend
  • Angular — Frontend
  • Laravel — Backend
  • Filament — Backend
  • Node.js — Backend
  • Django — Backend
  • PostgreSQL — Databases
  • MySQL — Databases
  • Redis — Databases
  • Supabase — Databases
  • REST — API & messaging
  • GraphQL — API & messaging
  • Kafka — API & messaging
  • RabbitMQ — API & messaging
  • Docker — Containers & cloud
  • Kubernetes — Containers & cloud
  • Terraform — Containers & cloud
  • Ansible — Containers & cloud
  • AWS — Containers & cloud
  • DigitalOcean — Containers & cloud
  • GitHub — CI/CD & source control
  • GitHub Actions — CI/CD & source control
  • Jenkins — CI/CD & source control
  • CircleCI — CI/CD & source control
  • Jest — Testing
  • Cypress — Testing
  • PHPUnit — Testing
  • Linux — Operating systems
  • Unix — Operating systems
  • Windows — Operating systems