AI Automation Engineer · Full Stack Developer
I build production software that removes complexity instead of adding more.

I design and ship systems end to end — architecture, backend, frontend, deployment, and the documentation that makes them maintainable by someone who isn't me.

My work sits at the intersection of AI automation, full stack engineering, and browser/desktop tooling. The common thread is reducing moving parts: a shipped system with two runtime dependencies beats an unshipped one with forty.

Most of what I build is operated by real people, in production, without a developer in the loop.

Build software that removes complexity instead of adding more.

I don't use AI to autocomplete lines — I use it as a build system. Agent loops and rendering pipelines that run unattended. This is the real usage behind the projects below — the card is regenerated from my local Claude Code transcripts by scripts/build_stats.py and pushed automatically, so it is never stale.

Guests scan the QR card on their table, get a fixed handful of shots, and shoot the night from where they are sitting. No app to download, no account, no retakes, no preview screen. Every photo lands in one album that stays sealed until the host opens it. Built for weddings, debuts, birthdays, christenings and reunions, with Taglish copy and GCash-first payments.

Why it exists: the official photographer sees one angle. Everyone else in the room is already holding a different one, and those photos end up scattered across fifty camera rolls. Limiting each guest to a few shots is the point, not a missing feature. When every frame counts, people stop posing and start noticing the room.

One decision worth reading: payment creates the event, not the browser. The QR only exists once PayMongo's webhook says the money arrived. The signature is checked against the raw request body before anything runs, and anything unrecognised is refused. I tested it by attacking it: unsigned, garbage-signed and wrong-secret webhooks get 401, a retried webhook is recognised and not processed twice, and paying ₱1 for a ₱2,499 package gets 409. A redirect back from a checkout page proves nothing, so the product never trusts one.

Proven on real phones, not asserted. A Galaxy S25 FE on Chrome and an iPhone on Safari both ran the whole guest flow against a live event. iOS Safari gave a real in-browser viewfinder, which was the biggest risk in the "no guest app" decision. With Wi-Fi off, four photos queued and all arrived. A whole guest session used about 340 KB. The guest page loads in 0.93 s cold in production.

flowchart LR
    G["Guest phone<br/>scan QR · browser camera"] -->|shots, offline queue| API
    H["Host<br/>magic-link sign-in"] -->|reveal · download all| API
    P["PayMongo"] -->|signed webhook| API
    API["Next.js route handlers<br/>on Vercel"] --> DB[("Supabase<br/>Postgres")]
    API --> R2[("Cloudflare R2<br/>sealed photos")]

Live site · Repository (private)

Also shipped: a host Android app (a verified Trusted Web Activity), a founder console with staff accounts and an append-only audit log, and a ledger. The console sits behind a secret path and answers 404 to anyone who isn't signed in.

A Chromium/Electron browser that optimizes for work rather than consumption. Not a Chrome clone, and deliberately not an AI browser — the browser layer must be excellent with the AI turned entirely off.

Why it exists: every browser is built for reading the web. None are built for building things — holding projects, context, and tools in one keyboard-first environment that remembers where you left off and gets smarter the longer you use it.

One decision worth reading: the architecture is strictly layered, and AI is the topmost layer, never the foundation. Workspaces get real isolation via per-workspace Chromium session partitions (persist:ws-<id>) — separate cookies, logins, cache, and history — not just visual grouping. And Knowledge only grows through confirmed user actions, never passive observation. That line between ephemeral Context and durable Knowledge is the hardest constraint in the system.

flowchart TD
    AI["AI Provider · replaceable, cloud optional"] --> IE["Intent Engine"]
    IE --> KE["Knowledge Engine · durable, user-confirmed"]
    KE --> CE["Context Engine · per-workspace, ephemeral"]
    CE --> WS["Workspace · isolated session partition"]
    WS --> BR["Browser · the primary product"]

Repository · Architecture · Roadmap

A storefront and admin CMS built from scratch for a Philippine streetwear brand. No Shopify, no WordPress, no templates. It went live and sold out its first batch, and the owner runs the business through it without a developer. It makes the GCash and bank-transfer checkout first-class: stock is reserved, the buyer uploads a payment screenshot, and an admin verifies it. Unpaid orders expire and go back on the shelf. All media lives in the database, because the free hosting tier wipes its disk on every redeploy.

Live site · Case study · Repository (private)

A hand-built portfolio and long-form case study site. Zero framework, zero build step — the same constraint discipline as Wave3, applied to a site whose only job is to make a technical reader understand the work in under two minutes.

Live site

Private: salo (event photo app, live at saloph.com, in beta) and wave3 (e-commerce platform and CMS, operated daily by a non-technical owner). The source is closed; the sections and screenshots above cover the architecture and the decisions.

Also working in: hyperframes (HTML-to-video rendering for agents) and barehands (webcam hand tracking as an AI interface) — forks I build on top of, not original work.

Constraints first. I design around the real limits — free-tier ephemeral disks, one admin user, a non-technical operator — instead of designing for imaginary scale and paying for it immediately.

Fewer moving parts. Wave3 runs on two runtime dependencies. Every dependency, framework, and service has to earn its place against the cost of operating it solo.

Correctness where it counts. The most valuable engineering in Salo isn't a screen. It's making sure an event only exists once a signed payment proves it, and that a forged or repeated payment message changes nothing. In Wave3 it was making sure two buyers can never both get the last unit. Both are tested and boring on purpose.

Documentation is part of the deliverable. If a system can't be understood from its README, it isn't finished.

_{Open to senior full stack, AI automation, and founding engineer roles.
Portfolio · LinkedIn · bueranojhon@gmail.com}