
# GuateLive

A live discovery platform for restaurants, cafés, and bars in Guatemala — conceived, scoped,
architected, and built solo. I'm the founder and the engineer on this one: every product call,
every schema decision, every line of infrastructure is mine to own, including the ones that turned
out to be wrong and had to be caught.

The premise: generic listings don't get people to actually go anywhere — editorial opinion does.
Structured search handles "what's open near me right now." A weekly editorial layer — each
"edition" a magazine-style writeup with a food verdict, a place verdict, and an itemized bill —
handles "convince me it's worth leaving the house." That product bet, not the tech stack, is the
actual thing being tested here.

{{gallery:bubbleSearch3.gif}}


## Why I built this (the founder bet)

Guatemala City has no shortage of restaurant-listing apps — what it lacks is a voice that tells
you what to actually do tonight instead of a wall of five-star-average noise. That's a product
positioning decision, not a technical one: GuateLive is built as an entertainment/discovery
product first, directory second, which is why the editorial layer got built before most of the
"nice to have" search polish.

A few calls I made as founder, not just as the person writing the code:

- **Scoped the POC to restaurants, cafés, and bars only, for the first 6 months** — instead of
  trying to cover nightlife, events, and culture from day one. Narrow enough that one person can
  sustain a real weekly editorial cadence, which is the part of the product that actually
  differentiates it.
- **Then deliberately broke that scope early, on purpose, once traction said to.** The plan had
  events deferred to month 4+; I pulled it forward to week 3 when it became clear an events
  carousel could drive attention now — a scope change I made and documented at the time, not one
  that quietly drifted in.
- **Monetize via disclosed sponsorship, not a paywall or ads that degrade the editorial voice.**
  Free listing by default; a paid tier (up to Q1,500/month) buys editorial placement and priority
  surfacing — always labeled as sponsored, including in anything an LLM might eventually read from
  the data. Trust in the editorial voice *is* the product, so the monetization design had to not
  undercut it.
- **No Stripe, by design, from day one** — it doesn't operate as a seller in Guatemala. That's a
  constraint I built the entire payment/monetization shape around up front, instead of discovering
  it mid-build and reworking the model.


{{gallery:events.gif}}


## Agents I designed and built

A solo founder can't hand-tag hundreds of places or hand-check a bank's website every day — so two
pieces of the product are built as agents, not one-off scripts, each with a specific job and a
specific boundary on what it's allowed to do wrong.

**Classification agent (tagging).** Places need tags across five axes — occasion, atmosphere,
price tier, features, cuisine — and today's catalog-wide coverage actually comes from deterministic
scripts (Google's own place attributes, a price-tier mapping, a hand-curated occasion/atmosphere
taxonomy). The agent designed to generalize this is a Claude Haiku pipeline (`auto-tag-places.ts`):
it takes a place's raw data and returns tags plus a short description, pinned to a fixed taxonomy
with strict JSON output — anything outside the allowlist gets dropped rather than trusted. It runs
in batches with per-item error isolation, so one malformed response degrades a single row instead
of the whole run, and it's deliberately barred from ever touching `is_published` — a bad AI output
should never silently promote or hide a listing. It's validated in test mode against a handful of
places; before it runs against the full catalog it needs one fix so its writes merge into a
place's existing tags instead of overwriting them.

{{gallery:placePage.png}}


**Scraping agent (bank promotions).** Banks publish restaurant discounts with no API and no
consistent structure, so this is built around a `BankPromoSource` interface — one bank live today,
designed so a second bank is one adapter file and one registry line, never a change to the
orchestrator, matching, or database logic. What makes it an agent rather than a brittle script is
that it decides when *not* to act: if a scrape returns zero results, it aborts before touching the
database, so a broken selector or a network blip can't be misread as "every promotion expired" and
silently deactivate real, live offers. Matching a scraped merchant name to a place is
exact-normalized-string, not fuzzy — a wrong match is worse than no match — and chains with
multiple branches get resolved per place page at read time instead of the scraper guessing a single
branch to write to. It runs unattended in production, daily, via GitHub Actions.

{{gallery:promos.png}}


## How I use AI as a senior engineer, not a passenger

The interesting skill here isn't "I used Claude to write code" — it's directing an AI collaborator
across an entire stack (product spec → database schema → agents above → frontend → design system)
while still being the one who owns the architecture, catches the AI's mistakes, and vetoes its
shortcuts. A few concrete times that mattered, not hypothetical ones:

- **Didn't trust "the field is 100% populated" as proof the AI tagging agent did the work.** Three
  different scripts had written to the same tags column over time; I verified the actual values
  matched the agent's vocabulary before accepting the claim — and caught myself almost making the
  same wrong assumption a second time in the same session before writing it down as fact.
- **Treated "the migration ran without error" as insufficient proof for a security-sensitive
  change.** For row-level security specifically, verifying meant comparing the same query's result
  with the public key vs. the admin key — a query that returns cleanly can still be silently
  filtering rows in a way that looks fine and isn't.
- **Found and closed a security blind spot** on a table that had been created outside the versioned
  migration path and had therefore never gone through the same checklist as everything else — the
  kind of gap that's invisible unless you go looking for tables that didn't come from a migration
  file.
- **Insisted on the fail-closed guard in the scraping agent** described above — that's a judgment
  call about what "safe" means in this specific system, not something that falls out of "call the
  API and save the response."

AI is the reason a solo founder can run a content-heavy, constantly-refreshed local catalog at a
pace that would normally need a small team. The architecture decisions, the skepticism about what
the AI just told me, and the calls about what's safe to automate versus what needs a human in the
loop are still mine.

## Tech stack

| Layer | Choice |
|---|---|
| Frontend | Next.js 15/16 (App Router), React, strict TypeScript, Tailwind + shadcn/ui |
| Backend / data | Supabase (Postgres + Auth + Storage + RLS) — no ORM, direct SDK queries |
| AI | Anthropic Claude (Haiku) for structured extraction/classification |
| Data acquisition | Google Places API (cost-tiered refresh), Cheerio-based scrapers for bank promos |
| Automation | GitHub Actions (cron) |
| Deployment | Vercel |

## Architecture & engineering decisions

**Google Places cost model, not just "cache it."** Photos are the dominant cost if fetched live
(~$0.017/photo via the Places Photo endpoint), so they're migrated once into Supabase Storage and
never requested from Google again at render time — enforced by convention: the file that used to
call the photo endpoint was deleted outright, and a live `maps.googleapis.com/photo` call anywhere
in the render path is treated as a regression. Everything else refreshes on a tier matched to both
data volatility and Google's own pricing: name/status/hours weekly (free, Basic Data),
rating/price-level/hours monthly (paid, Atmosphere), phone/website quarterly (paid, Contact). These
refresh scripts still run manually — there's no cron for them yet, only for the scraping agent
above.

**Client-side search as a deliberate, timestamped tradeoff.** `/buscar` loads the full catalog and
filters in the browser, which buys zero-latency filtering at current catalog size with no loading
states. It's written down as a call with an expiration condition, not a permanent one: past roughly
1,000–2,000 places, or the first time mobile load time becomes noticeable, the plan is server-side
Postgres full-text search before reaching for a dedicated search engine. Same logic on the database
layer: no ORM, direct Supabase SDK queries, revisited only if the schema needs complex many-to-many
relations or generated types.

**ISR + Supabase's client split.** Pages using `generateStaticParams` need the plain
`@supabase/supabase-js` client instead of the cookie-based server client, since `cookies()` doesn't
exist at build time — a gotcha that became a standing pattern across every ISR route
(`revalidate = 3600`) after it broke a page once.

**Editorial voice as a schema problem, not just copy.** Editions store their "verdict" as
structured ratings/text fields, and the itemized bill is a `jsonb` array of label/amount rows
rather than a hand-formatted string parsed with `.split()` — the fragile-string version broke the
moment the format drifted. Design identity (near-black dominant, a red accent that's never a large
background fill, serif display type for editorial headlines vs. sans for UI) is documented once and
applied everywhere, not decided per page.

**Bubble search kept its 3-step flow on purpose.** A full visual redesign of the home page
considered collapsing the "what → where → when" bubble flow into a single-tap search with instant
results. The call was to keep the 3-step flow and only reskin it — validating existing UX against a
new visual direction instead of letting a redesign silently change product behavior.

## AI roadmap

- **Shipped:** the classification and scraping agents described above; Schema.org/JSON-LD across
  place, edition, and event pages, validated in production.
- **Next:** generalize the classification agent from a small validated test set to the full
  catalog — fixing the tag-merge bug first — and scope additional narrowly-permissioned agents
  (event drafting from third-party sources, a read-only support assistant), each defined first by
  what it's *not* allowed to touch before what it can do.
- **Further out:** an MCP server exposing the catalog to LLM clients directly, gated behind
  500+ well-tagged places as proof the data is worth serving.

## Key learnings

- **Constrained output is what makes an LLM call production-grade.** A fixed taxonomy plus strict
  JSON plus an allowlist on the way back turns "the model might say anything" into a normal,
  boring failure mode instead of an unpredictable one.
- **Every architectural shortcut ships with its own expiration condition.** Client-side search, no
  ORM, manual (not cron'd) Google Places refresh — none of these are permanent calls; each has a
  written number or symptom attached that says when to revisit it.
- **A soft-404 (a "not found" page that still returns 200) is worse than no page at all** for
  anything meant to be indexed — worth catching explicitly rather than treating a friendly error
  message as good enough.


Live discovery platform for restaurants, cafés, and bars in Guatemala, combining an editorial voice with AI-driven data pipelines: automated tagging agents, web scrapers, and Google Places API integration.

GuateLive — Local Discovery Platform for Guatemala


## Description

SmartHome+ is TELUS's consumer-facing smart home app — the product customers pay a monthly subscription for. It spans video security, home automation, energy monitoring, and a newer AI-powered assistant, all controlling physical devices inside someone's home. As Senior Software Engineer (Telus International, August 2022 – Present), I built mobile features for it in React Native and TypeScript, against the same event-driven AWS backend and observability platform behind [Tenant Portal](/projects/telus-tenant-portal) — TELUS support's internal tool for this device ecosystem.

That shared foundation matters more here than in a typical consumer app: this isn't a to-do list where a bug means a lost checkbox, it's an app where a bug can mean a door someone thinks is locked isn't, or a camera alert someone is relying on doesn't fire. Reliability on this app is a trust problem for TELUS, not just an engineering metric — and trust is what a recurring security subscription is actually selling.

## Role-Based Access: One App, Two Audiences

The sign-in flow looks like a normal customer login, but it isn't only for customers — field technicians authenticate through the same entry point and land on a different experience built for their job: install and diagnostic screens instead of the customer-facing controls. That's a deliberate choice, not an accident of how auth happened to get built: maintaining one app with role-scoped views is cheaper to ship and easier to keep in sync with real device state than running a separate technician app against the same backend, and it means a technician standing in a customer's home is looking at the same live device data the customer sees, not a stale mirror of it.

{{gallery:login.png}}

## Product Areas

- **Video** — smart cameras with AI-based detection of people, pets, and packages, with cloud event storage for up to 60 days on compatible plans
- **Automation** — controlling lights, plugs, locks, and sensors, plus building automations and routines, all from a single app
- **SmartEnergy** — monitoring energy consumption, estimating costs, automating devices to save energy, and earning TELUS rewards through compatible devices
- **SmartHome+ Assistant** — an AI assistant that manages devices and automations through text, voice, or images

Centralizing all of this in one screen per device, rather than the manufacturer's own app for each camera or lock, is itself a retention lever: the more of a customer's smart home lives inside SmartHome+, the higher the switching cost to a competitor, and the more surface area TELUS has to sell SmartEnergy and additional devices into.

{{gallery:camera.png}}

## Compatible Devices

Cameras, thermostats, smart locks, smart bulbs, sensors, and TELUS's Automation Hub, with support for select compatible third-party devices. Every additional device category the app has to support without regressing the others is a real constraint on how the mobile codebase is structured — device-specific logic has to be isolable enough that adding a new device type doesn't mean re-testing the whole app.

{{gallery:manages.png}}

## SmartHome+ Assistant

Built in-house by TELUS, the assistant lets a customer create routines or troubleshoot a misbehaving device through text, voice, or a photo, instead of hunting through settings screens or calling support. From an engineering and business standpoint, this is a deflection play as much as a feature: every issue a customer resolves through the assistant is a call that never reaches a support queue, which is the same cost center [Tenant Portal](/projects/telus-tenant-portal) exists to make more efficient on the agent side.

{{gallery:jarvis.png}}

## Mobile Engineering

The app is built in React Native and TypeScript, sharing the same backend contract as Tenant Portal rather than a separate mobile-only API — which meant mobile features had to work within an API surface designed for both a support agent's dashboard and a customer's phone. Device state changes (a lock engaging, a camera detecting motion) come from the same event-driven AWS backend feeding the support platform, so the mobile app is built to treat device state as something that arrives asynchronously and can be momentarily stale, not something it owns and polls for on its own schedule.

## Security & Reliability

Given the app controls physical security devices, secure engineering practices — input validation, authentication, authorization, and API design — were treated as a baseline requirement, not a hardening pass added later, and role-based access (see above) is itself a security boundary as much as a UX one: a technician account and a homeowner account need very different permissions against the same household's devices. On the reliability side, unit and integration tests plus deliberate error-handling around device actions exist because a silent failure on a lock or camera command is a materially worse outcome here than a silent failure on a typical consumer app screen.

## How It Connects to Tenant Portal

SmartHome+ is what the customer (and, through the same login, a field technician) uses to control a home; [Tenant Portal](/projects/telus-tenant-portal) is what a remote support agent uses to diagnose and resolve issues for that same household without being on-site. All three roles — customer, technician, and support agent — ultimately read and act on the same device state through the same backend, just through interfaces built for very different jobs. Working across both the consumer app and the internal support tool gave me visibility into this device ecosystem from every angle it gets used from, which made it obvious when a feature belonged in one app, the other, or both.

## Key Learnings

**A single app with role-scoped views can beat two separate apps, but only if the roles are genuinely thin variations of the same job.** Technician and customer views diverge in what they show, not in what backend they talk to — that's what made one app the right call instead of a maintenance burden.

**Consumer-facing reliability has a different failure cost than internal tooling.** A bug in a support agent's dashboard is an inconvenience; a bug in the app controlling someone's front door lock or security camera is a trust problem — that difference shaped how much testing and error-handling rigor went into mobile-side changes.

**An AI assistant that resolves an issue is a support call that never happens.** Framing the SmartHome+ Assistant as a deflection mechanism, not just a novelty feature, is what ties its engineering cost directly to the same support-efficiency goals behind the internal tooling.

**Sharing a backend across a consumer app and an internal support tool means the API contract has to serve very different consumers.** Fields designed primarily for agent diagnostics still had to stay lean enough not to bloat the consumer mobile experience.


TELUS's consumer smart home app — video security with AI detection, home automation, and SmartEnergy monitoring — where I contributed mobile features as a Senior Software Engineer.

Telus SmartHome+ — Smart Home Mobile App


## Description

Tenant Portal is the internal system TELUS support operations run on — not the app customers use, but the tool support agents, technical specialists, and operations teams use to diagnose and manage the SmartHome+ device ecosystem on a customer's behalf. It's in daily use by distributed teams in Canada, Central America, and India, sitting in front of millions of connected IoT devices.

As Senior Software Engineer (Telus International, August 2022 – Present), I architected and delivered this platform end to end — React/TypeScript on the frontend, Kotlin/Java/Spring Boot and Node.js/Express services on the backend, running on AWS — and I'm the one who owns the tradeoffs behind it: what to make event-driven versus synchronous, how much to invest in observability before it pays off, and where clean architecture actually earns its cost versus where it's just ceremony. Requirements came from stakeholders, engineers, and QA across multiple regions, which meant designing for agents whose workflows, network conditions, and support volume differ by market, not for one reference user.

SmartHome+ is a paid subscription product wrapped around physical devices in someone's home — locks, cameras, sensors — so a bad support experience isn't just an inconvenience, it's a churn risk on recurring revenue and, in the case of security devices, a trust problem. Tenant Portal is also the piece of infrastructure that lets TELUS staff a follow-the-sun support model across Canada, Central America, and India at a shared cost base instead of each region running its own tooling — so the platform's economics matter as much as its feature set.

{{gallery:tenantcover.png}}


## Impact at a Glance

- **~40%** improvement in application performance, at **99.9%+** availability — directly shortens how long an agent sits on a case, which is the main lever on cost-per-support-interaction at this scale
- **~50%** reduction in incident response and resolution time after investing in observability — fewer escalations and less customer-facing downtime to account for against SLAs
- **~40%** improvement in environment consistency and deployment reliability after moving to Infrastructure as Code — faster, safer releases mean new device integrations and features reach agents (and indirectly, customers) sooner
- **85%+** automated test coverage across unit, component, and end-to-end layers — fewer regressions reaching a system agents depend on to do their job in real time
- **~60%** engineering productivity gain from deliberately structured AI-assisted workflows — more roadmap delivered without growing headcount

{{gallery:dashboard.png}}

## What It Gives an Agent

A support call starts with almost no context beyond a customer's account. The portal exists to close that gap fast:

- Pull up a household and every device tied to it in one view
- Read a device's current connection status and health, not just whether it's "online"
- Trigger remote actions against a device directly from the case
- Trace a diagnosis across an entire household instead of one device at a time
- Look up customer profiles and manage subscriptions from the same screen
- Search across the household base quickly enough to use mid-call
- See data pulled from several backend services rendered as one coherent record, instead of an agent stitching it together from multiple internal tools

Every one of these is really about call-handle time: the less time an agent spends hunting for context across tools, the more cases a support team can close per shift without adding headcount.

{{gallery:devices.png}}

## Automation Visibility: Human and AI-Generated Routines

Devices in this ecosystem run on automation rules — some authored directly by the customer or an agent, others generated by an AI layer inferring useful automations from device behavior. Agents needed a way to see which rules were actually driving a device before troubleshooting it, so the portal surfaces both kinds of routines side by side against the same device timeline. That distinction matters operationally: a device "acting up" is a very different conversation when the cause is a human-configured rule versus an automated one nobody in the household consciously set — get that wrong on a call and the agent either escalates a case that didn't need it, or reassures a customer whose automation genuinely is misbehaving. Both outcomes cost the business: one in agent time, the other in repeat contacts and eroded trust.

{{gallery:routines.png}}

## Incident and Activity Visibility

Support is retrospective as often as it's live — an agent needs to reconstruct what happened on a device before the customer ever called. The portal's incident/log view gives agents that timeline directly, instead of requiring a separate ticket into another team to pull raw logs — turning what used to be a multi-day, cross-team investigation into something resolved on the first call, which is the difference between a satisfied customer and one who calls back.

{{gallery:alerts.png}}

## Frontend Engineering

The UI is built as a component-driven React/TypeScript system, combining Material UI's component primitives with a shared data-table architecture — search, pagination, configurable columns, row selection, and per-row actions driven by shared context and reducers rather than re-implemented per screen. Server state (households, devices) is managed through TanStack Query rather than hand-rolled fetch-and-cache logic, which removed an entire category of stale-data and race-condition bugs that used to show up as "the table says something different than the device detail page." Domain data is exposed to components through typed custom hooks, keeping components themselves focused on presentation rather than data-fetching concerns.

## Backend & Event-Driven Architecture

Core services are REST APIs in Kotlin, Java, and Spring Boot, with some services in Node.js/Express — deliberately not a single-language backend, since different services had different reasons to exist (some tied closely to existing Java domain logic, others needed to move fast on thinner, IO-bound endpoints). Layered onto that is a distributed, event-driven architecture using AWS Lambda, API Gateway, SQS, SNS, EventBridge, DynamoDB, and OpenSearch — necessary because polling millions of IoT devices synchronously doesn't scale, and a support agent needs near-real-time device state without the backend blocking on every device round-trip. That tradeoff isn't free: event-driven systems push complexity into idempotency, retry handling, and eventual consistency, so a meaningful part of the architecture work was making sure "eventually consistent" didn't leak into agent-facing screens as "occasionally wrong."

Object-oriented principles, SOLID design, and clean architecture boundaries in the Kotlin/Java services weren't applied as a checkbox — they're what kept a backend touched by a distributed team, over years, from calcifying into something only its original author could safely change. Security was treated as a design constraint from the start: input validation, authentication, authorization, and API design decisions were made with the assumption that this system holds access to real customers' home devices, not a low-stakes internal tool.

## Testing & Reliability

Jest and React Testing Library cover frontend unit and component behavior, MSW mocks network boundaries so tests don't depend on live services, Vitest covers newer modules, and Cypress covers end-to-end flows that actually matter to an agent mid-call. The 85%+ coverage number is a byproduct of testing the right layers, not a target chased for its own sake — coverage on the reducer/state logic driving the shared tables mattered far more than coverage on presentational components.

## Observability & Incident Response

CloudWatch metrics and alarms, real-user monitoring, dashboards, and Opsgenie paging turned "a device seems broken" from a multi-team investigation into something traceable from a single alert. Cutting incident response and resolution time by roughly half wasn't the result of one tool — it came from deciding upfront what needed to be observable (which service boundaries, which failure modes) instead of instrumenting reactively after an incident exposed a blind spot. In business terms, that's the gap between an outage that stays invisible to a handful of engineers and one that turns into a spike in support call volume across every region at once.

## Infrastructure & Delivery

Deployment workflows run on Docker and Kubernetes, with GitLab CI/CD automating testing, validation, and production releases. Infrastructure as Code, via AWS CDK and Terraform, replaced manually provisioned environments — the ~40% gain in deployment reliability came specifically from eliminating environment drift between staging and production, which used to be a recurring source of "it worked in staging" incidents. The business case for this is time-to-market: every new device model or support feature TELUS wants agents equipped to handle ships faster when releases aren't gated on hand-configured environments.

## AI-Assisted Engineering, Used Deliberately

GitHub Copilot, Amazon Q, Claude Code, and Cursor are part of the daily workflow — for code review, documentation, codebase analysis, and generating first-draft technical solutions. The ~60% productivity gain came from being specific about where AI helps: it's fast at producing a first pass and surfacing patterns across a large codebase, and it's not a substitute for deciding whether an event-driven approach is worth its complexity, or whether a "passing" migration actually preserved behavior. Alongside day-to-day use, I've run structured experiments with LLM APIs and prompting techniques aimed at developer workflows specifically — automated knowledge retrieval over internal documentation and codebases, and evaluating where AI-assisted capabilities are actually production-ready versus still a demo. For the business, that productivity gain is roadmap throughput: the same engineering team shipping more of what support operations and product are asking for, without headcount scaling linearly with device volume.

## From Mocks to Real APIs

The frontend started against a `json-server` mock backend so UI work could move ahead of the real services. As those services matured, the app was migrated onto the real APIs — a deliberate cutover, not an incidental swap, since that's exactly where contract mismatches between mock and reality tend to surface.



## Key Learnings

**Event-driven architecture is a tradeoff, not a strict upgrade.** Lambda, SQS, SNS, and EventBridge made it possible to handle device-scale traffic without the backend becoming a bottleneck, but every one of those queues and streams is a place where "eventually consistent" can become "occasionally wrong" if you don't deliberately design for it on the agent-facing side.

**Observability is worth building before the incident that would have justified it.** The ~50% cut in incident resolution time came from deciding in advance what needed to be measurable, not from adding dashboards after a bad outage exposed the gap.

**AI tools are a force multiplier on throughput, not on judgment.** Copilot, Amazon Q, Claude Code, and Cursor meaningfully sped up review, documentation, and first drafts — but the calls about event-driven complexity, clean-architecture boundaries, and IaC tradeoffs were still mine to make and defend.


Internal enterprise web platform used by TELUS support agents in Canada, Central America, and India to diagnose and manage the SmartHome+ device ecosystem across millions of connected homes.

Telus Tenant Portal — Internal Smart Home Support Platform (Web)


## Description

To complement the learning experience on [Virtual Tech GT(Web)](/projects/virtual-tech-gt), Virtual Tech GT also built a companion mobile app focused on interactive quizzes and knowledge reinforcement. Built in React Native, it lets students practice the concepts from their courses in short sessions, track how their performance changes over time, and do it from a phone — deliberately outside the checkout-and-classroom flow of the web platform, which isn't built for a five-minute study session between classes.

As Software Developer (Virtual Tech GT, June 2019 – September 2022), I built frontend and backend features for the app using React Native, Kotlin, Java, Spring Boot, and AWS. The product bet behind it is simple: the web platform sells and delivers a course, but repetition is what actually makes the material stick, and repetition only happens if practicing is close to frictionless.

{{gallery:test2.png}}

## Practicing Like the Real Test

The quiz content itself is written to mirror exam-style questions rather than generic true/false flashcards, since the goal isn't just exposure to the material, it's reducing the gap between how a student studies and how they'll actually be assessed. That distinction matters commercially as much as pedagogically: for an institution whose value proposition is the certificate at the end of a course (see [Quizzes Usac (Web)](/projects/quizzes-usac-web)), a practice tool that builds real test-taking confidence protects pass rates — and pass rates are what make an institution's certification worth paying for in the first place.

## Key Responsibilities & Achievements

- **Built the React Native mobile app** for interactive, course-tied quizzes, scoped deliberately narrow — a fast practice loop, not a second course-browsing app — so it stayed genuinely quick to open between classes.
- **Implemented progress tracking**, giving students a visible signal of improvement over time instead of a quiz being a one-off, disconnected activity.
- **Integrated the app with backend REST APIs** (Kotlin, Java, Spring Boot) shared with the web platform, keeping quiz content tied to a student's actual course enrollment rather than a generic question bank.
- **Developed a responsive, mobile-first UI** for quiz-taking flows, optimized for short, anytime/anywhere practice sessions rather than long-form study.
- **Contributed to cloud infrastructure and application performance** on AWS supporting both the web platform and the mobile app.

## Tech Stack

| Layer | Choice |
|---|---|
| Mobile | React Native, TypeScript |
| Backend | Kotlin, Java, Spring Boot — REST APIs (shared with Quizzes Usac Web) |
| Infrastructure | AWS |

## Key Learnings

**A quiz app only reinforces learning if it's frictionless to open.** Keeping the app scoped to "practice a quiz in a couple minutes" rather than replicating the full course-browsing experience of the web platform kept it genuinely usable as a quick between-classes reinforcement tool, not a second app students had to relearn.

**Question quality is the actual product, not the app shell around it.** Writing practice questions to mirror real exam style — not just covering the same topics — is what turned the app into something that measurably prepares a student, instead of a gamified but shallow flashcard exercise.

**Sharing a backend between a transactional web platform and a lightweight mobile app works well when the mobile client only needs a thin slice of the API surface** — quiz content and progress, not the full course-commerce contract — which kept the mobile app's integration surface small and easy to reason about.


React Native companion app to the Quizzes Usac course platform, letting students practice course concepts through interactive quizzes, track their progress, and reinforce learning anytime from their phone.

Quizzes Usac — Interactive Quiz Mobile App


## Description

Quizzes Usac is a full-stack EdTech and e-commerce platform built at Virtual Tech GT (Software Developer, June 2019 – September 2022) to help educational institutions and training providers sell, manage, and deliver online courses. Students can browse course catalogs, purchase courses through secure payment gateways, access learning content, and manage their enrollments — while, on the business side, the platform gives organizations administrative tools for course management, student enrollment, payment processing, invoicing, analytics, and reporting to scale their online education operations.

The platform is paired with a companion React Native app — [Quizzes Usac (Mobile App)](/projects/quizzes-usac-mobile) — that lets students reinforce what they learn through interactive quizzes.

## Key Responsibilities & Achievements

- **Developed frontend and backend features across the platform** using React, Java, Kotlin, Spring Boot, and AWS.
- **Built scalable REST APIs** powering course catalog browsing, purchases, enrollment, and content access.
- **Implemented secure payment integrations**, enabling reliable course purchases and reducing checkout friction.
- **Developed responsive user interfaces** for course discovery, checkout, and the student learning experience.
- **Built administrative tools** for course management, student enrollment, payment processing, invoicing, analytics, and reporting, enabling institutions to scale their online education operations.
- **Automated invoicing and regulatory workflows**, reducing manual processing and improving compliance accuracy.
- **Contributed to cloud infrastructure and application performance** on AWS.
- **Participated in digital marketing initiatives**, integrating analytics and supporting data-driven growth strategies that improved user acquisition and course sales.

## Tech Stack

| Layer | Choice |
|---|---|
| Frontend | React, TypeScript |
| Backend | Kotlin, Java, Spring Boot — REST APIs |
| Database | PostgreSQL |
| Payments | Stripe and other payment gateway integrations |
| Infrastructure | AWS |

## Key Learnings

**An EdTech platform is really two products in one: a storefront and a classroom.** The purchase/checkout flow and the actual learning/content-delivery experience have different priorities — conversion and friction on one side, engagement and retention on the other — and both had to be designed for without one compromising the other.

**Admin tooling is what lets a platform scale past its first few institutional customers.** Course management, enrollment, invoicing, and reporting tools weren't an afterthought — they're what let an institution run its own catalog without engineering involvement in every course launch.

**Regulatory/invoicing automation pays for itself quickly in an EdTech context**, since institutional customers need auditable, compliant invoicing far more than a typical consumer e-commerce buyer does.


Full-stack EdTech e-commerce platform built at Virtual Tech GT, enabling educational institutions to sell, manage, and deliver online courses with secure payments, enrollment, invoicing, and analytics.

Quizzes Usac — EdTech Course Platform (Web)


## Description

Virtual Tech GT is a full-stack EdTech e-commerce platform that lets educational institutions and training providers sell, deliver, and certify online courses. As Software Developer (June 2019 – September 2022), I worked across the entire stack — React/TypeScript on the frontend, Kotlin/Java/Spring Boot and Node.js/Express services on the backend — and the work that actually moved the business number (a ~40% increase in course sales) was as much about checkout friction and funnel design as it was about backend architecture.

For an institution, this platform *is* their online education business — every course sale, every completed exam, every invoice runs through it. That framing shaped the priorities: reliability and compliance weren't nice-to-haves layered on top of a course catalog, they were the product, because an institution won't put its revenue and its regulatory standing behind a platform that treats either as an afterthought.

{{gallery:video.png}}

## Content Delivery and Assessment

The platform's two jobs, beyond commerce, are getting course content to a student reliably and proving they actually learned something. Video content is served from cloud storage encoded for web playback rather than raw uploads, so a student on a weaker connection in a smaller city gets a degraded-but-working experience instead of a spinner — a deliberate tradeoff given the platform's actual user base spans well beyond fast urban connections. Exams are taken directly inside the platform and tied to course completion, which matters commercially as much as pedagogically: for most institutional customers, the certificate at the end is the actual product being purchased, and the course video is the delivery mechanism for it. An exam feature that isn't trustworthy — that can be gamed, or that loses a student's progress — undermines the credential the institution is selling, not just the UX.

{{gallery:examen.png}}

## Key Responsibilities & Achievements

- **Built and launched the platform end to end**, taking course sales and delivery from concept to a system driving a ~40% increase in course sales — through funnel optimization and checkout UX, not just backend throughput.
- **Architected REST APIs and microservices in Kotlin, Java, and Spring Boot, with Node.js/Express for lighter, IO-bound services** — a deliberate split, not a historical accident: core transactional and domain logic stayed in the strongly-typed JVM services, while thinner integration endpoints moved faster in Node.js. PostgreSQL and DynamoDB backed transactional integrity and flexible data models respectively.
- **Built the React frontend around reusable components, Hooks, Redux, and Context API**, which kept state complexity manageable as the platform grew from a single course catalog into a multi-institution commerce and content-delivery system.
- **Integrated Págalo, 2Checkout, and Stripe side by side**, because a Guatemalan/Central American customer base does not convert on a single US-centric payment processor — offering the payment method a buyer already trusts was a direct lever on completed-purchase rate, not just a technical integration checkbox.
- **Applied OOP, SOLID, and clean architecture across the Kotlin/Java services** so the backend could absorb three years of institutional customers with different course structures and pricing models without each new customer becoming a special case in the codebase.
- **Automated invoicing and regulatory compliance through SAT and InFile integrations** — SAT is Guatemala's tax authority, and manual invoicing at course-marketplace volume is both an operational bottleneck and a compliance risk. Automating it let institutions scale their catalogs without scaling back-office headcount in lockstep.
- **Ran the platform on AWS with CI/CD pipelines** for availability, fault tolerance, and repeatable, low-friction releases.
- **Worked in Agile/Scrum**, shipping iteratively against real institutional feedback rather than a fixed upfront spec.

## Tech Stack

| Layer | Choice |
|---|---|
| Frontend | React, TypeScript, Redux, Context API, Bootstrap |
| Backend | Kotlin, Java, Spring Boot for core domain services; Node.js/Express for lighter integration endpoints |
| Database | PostgreSQL, DynamoDB |
| Payments | Págalo, 2Checkout, Stripe |
| Integrations | SAT and InFile APIs (regulatory & invoicing automation) |
| Infrastructure | AWS, CI/CD pipelines |
| Process | Agile/Scrum |

## Key Learnings

**In EdTech commerce, the certificate is often the product and the video is the delivery mechanism.** That reframes what "reliable" means for a feature like exams — it's not just uptime, it's whether the institution can stand behind the credential it's selling.

**Payments are a UX and market-fit problem before they're an integration problem.** Wiring up Págalo, 2Checkout, and Stripe side by side mattered less for the API calls than for meeting Central American buyers with a payment method they already trusted — that's what actually moved completed-purchase rate.

**A polyglot backend is a legitimate architecture decision, not a lack of discipline.** Keeping core domain logic in Kotlin/Java and pushing thinner integrations to Node.js let each side move at the speed its actual complexity warranted, instead of forcing every endpoint through the same framework regardless of fit.

**Clean architecture pays off most in long-lived backend services.** Applying OOP and SOLID principles across the Kotlin/Java microservices kept the codebase extensible over three years of iteration and a growing, heterogeneous set of institutional customers — where a less disciplined structure would have accumulated much more debt.

**Automating regulatory workflows (SAT, InFile) removes an entire class of manual error**, and for institutional customers specifically, compliance risk is a bigger deal than it looks from the engineering side — it's the difference between an institution being willing to scale its catalog on the platform or not.


Full-stack educational e-commerce platform for digital course sales, built with React, TypeScript, Kotlin, Java, Spring Boot, and Node.js, driving a ~40% increase in course sales.

Virtual Tech GT — Educational E-Commerce Platform


## Description

Warava is a PropTech platform built in partnership with Hogares ISN, one of Guatemala's largest residential real estate companies, to modernize how prospective buyers discover and evaluate property. The default in this market was a sales agent or a static listing sheet as the only way to compare homes, apartments, and offices; Warava's job was to move that comparison online — letting a buyer search, filter, and shortlist properties on their own terms, while giving Hogares ISN a digital storefront for its inventory and a new, measurable channel into its sales pipeline.

As a Software Developer Intern (January – June 2019), I worked across the stack on an established product: responsive React/Bootstrap interfaces on the frontend, Django and FastAPI services on the backend, and the discipline of shipping inside someone else's codebase and design system rather than a blank canvas — turning Figma mockups into production components and delivering through the team's existing Agile process.

{{gallery:warava.png}}

## What It Let Buyers Do

- Search and filter across residential and commercial listings — homes, apartments, and offices — instead of paging through an undifferentiated inventory
- Explore detailed listings with interactive image galleries and location context
- Compare properties side by side while narrowing toward a shortlist
- Move from browsing to genuine evaluation of a specific property without a sales agent as the only intermediary

On the business side, that same interface was Hogares ISN's inventory showcase: every listing presented clearly and easy to find translated directly into engagement, and engagement was the top of the funnel the platform existed to feed.

## Key Responsibilities & Achievements

- **Shipped user-facing features for property search, exploration, and evaluation** across residential and commercial listings, moving the platform's usability and engagement forward one release at a time.
- **Built responsive, reusable React/Bootstrap components** that kept search, listing, and detail pages visually consistent and made new pages a matter of composition rather than rebuilding UI from scratch.
- **Partnered closely with design in Figma**, converting mockups into production-ready components with the fidelity that keeps a design-to-development handoff trustworthy instead of something that quietly drifts page by page.
- **Built and integrated backend services and REST APIs in Python across Django and FastAPI**, supporting data management and reliable frontend-backend communication as the feature set grew.
- **Optimized frontend performance** — component structure, rendering behavior, state handling — cutting load times on the image- and listing-heavy pages where sluggishness costs engagement directly.
- **Delivered inside the team's Agile workflow**, using Jira for planning and Bitbucket for version control and code review, and learning to work within existing conventions rather than code in isolation.

## Tech Stack

| Layer | Choice |
|---|---|
| Frontend | React, Bootstrap |
| Backend | Python — Django and FastAPI for REST APIs |
| Design Handoff | Figma |
| Process | Agile/Scrum, Jira, Bitbucket |

## Key Learnings

**A component library is only as good as its consistency discipline.** Building reusable React/Bootstrap components across dozens of property listings made clear how much faster a page comes together once the design system is trusted, versus re-deriving spacing and structure by eye on every new screen.

**Design-to-development handoff is a skill of its own.** Translating Figma mockups faithfully — not just visually close, but matching spacing, states, and responsive behavior — was as much a discipline to learn as any framework, and sloppy handoff shows up immediately once real data hits the layout.

**Running two Python web frameworks side by side (Django, FastAPI) taught me to read *why* a service exists before assuming its shape.** Django's batteries-included structure and FastAPI's lighter, async-friendly style solve different problems — an early lesson in matching the tool to the job instead of defaulting to whatever framework I'd already used.


A PropTech web platform built in partnership with Hogares ISN, one of Guatemala's largest residential real estate companies, letting buyers search, compare, and evaluate homes, apartments, and offices online.

Warava — PropTech Real Estate Platform


## Description

Full-stack AR-powered payment application built with React Native, Expo, and the MERN stack. The application combines immersive augmented reality experiences with secure payment processing and real-time transaction management.

It is designed to deliver a seamless mobile-first experience while maintaining enterprise-grade security, scalability, and a clear separation between client (React Native frontend) and server (Node.js/Express backend) responsibilities.

The platform enables users to authenticate securely, capture AR camera views, process payments, and manage their complete transaction history—all in real-time with instant UI updates and persistent data synchronization.

## Key Features

- **Full-stack architecture** with React Native mobile frontend and RESTful API backend
- **Augmented Reality integration** using React Viro and Three.js for immersive experiences
- **Secure authentication** using JWT with bcryptjs password hashing and persistent AsyncStorage sessions
- **Complete CRUD operations** for payment processing and transaction management
- **Real-time UI updates** without page reloads using Axios with interceptors
- **Protected routes** and API endpoints with user authorization and role-based access control
- **Cross-platform support** (iOS, Android, Web) from single React Native codebase
- **Transaction history tracking** with filtering and detailed payment records
- **Payment confirmation flows** with success/failure feedback and detailed status messages
- **Per-user data isolation** ensuring privacy, security, and multi-tenant data separation
- **Responsive design** optimized for mobile devices with bottom tab navigation
- **Offline-first architecture** with AsyncStorage for local data caching and sync

## Tech Stack

### Frontend
- **Mobile Framework**: React Native 0.76+ with Expo 52.0+
- **Routing**: Expo Router (file-based routing)
- **AR Technology**: React Viro 2.41+, Three.js 0.166+
- **Navigation**: React Navigation 6.x+ (Bottom Tab Navigator)
- **State Management**: AsyncStorage for local persistence
- **HTTP Client**: Axios 1.7+ with JWT interceptors
- **Camera Access**: Expo Camera 16.0+
- **UI Components**: Custom themed components with React Native
- **Styling**: React Native StyleSheet with theme support

### Backend
- **Runtime**: Node.js 18+
- **Web Framework**: Express.js (latest)
- **Database**: MongoDB 8.0+ with Mongoose 8.6+ ODM
- **Authentication**: JWT 9.0+ + bcryptjs 2.4+
- **API Architecture**: RESTful endpoints with middleware pattern
- **Security**: CORS, helmet, input validation, rate limiting
- **Environment**: Dotenv for configuration management

### Testing & Quality
- **Unit Testing**: Jest 29.7+ with Jest-Expo preset
- **E2E Testing**: Cypress 13.17+ with TypeScript support
- **Code Linting**: ESLint 8.57+ with Expo configuration
- **Code Quality**: TypeScript for type safety across the stack
- **Mock Data**: Jest mocks and Cypress fixtures

### Development & Deployment
- **Version Control**: Git with GitHub integration
- **Mobile Deployment**: Expo Application Services (EAS)
- **Database Hosting**: MongoDB Atlas with automatic backups
- **CI/CD**: GitHub Actions for automated testing and deployment

## Architecture

### System Architecture Overview

The application follows a **three-tier architecture** with clear separation of concerns:

```
┌─────────────────────────────────────────────────────────┐
│  Presentation Layer (Mobile & Web)                      │
│  ├─ Authentication Screens (Login/Signup)              │
│  ├─ Payment Processing Screens (Forms & Confirmation)  │
│  ├─ AR Camera Integration (Viro + Three.js)           │
│  ├─ Transaction History (Filtered List View)          │
│  └─ Success/Failure Feedback (Modal Dialogs)          │
└──────────────────┬──────────────────────────────────────┘
                   │ (HTTP/REST + JSON)
                   ↓
┌──────────────────────────────────────────────────────────┐
│  Business Logic Layer (API & Middleware)                │
│  ├─ Authentication Service (JWT + Password Hash)       │
│  ├─ Payment Service (Validation & Processing)          │
│  ├─ User Service (Profile & Data Management)           │
│  ├─ Transaction Service (History & Records)            │
│  └─ Middleware (Auth, Validation, Error Handling)      │
└──────────────────┬──────────────────────────────────────┘
                   │ (Mongoose ODM)
                   ↓
┌──────────────────────────────────────────────────────────┐
│  Data Access Layer (MongoDB)                             │
│  ├─ Users Collection (Profiles, Credentials)           │
│  ├─ Payments Collection (Payment Records)              │
│  ├─ Transactions Collection (Complete History)         │
│  └─ Sessions Collection (Optional - Token Blacklist)   │
└──────────────────────────────────────────────────────────┘
```

### Data Flow & Request/Response Cycle

```
User Interaction (Payment Submission)
        ↓
Frontend: Form Validation + State Management
        ↓
Axios HTTP POST with JWT Authorization Header
        ↓
Express Route Handler
    ├─ CORS Validation
    ├─ JWT Token Verification (Middleware)
    ├─ Input Sanitization & Validation
    ├─ Business Logic Processing
    └─ Mongoose Query to MongoDB
        ↓
MongoDB: Insert/Update Document
        ↓
Backend Response with Status & Data
        ↓
Axios Response Interceptor Handling
        ↓
Frontend: Async State Update via AsyncStorage
        ↓
Navigation & UI Render
        ↓
Success/Failure Screen Display ✓
```

### Authentication & Security Flow

```
Registration/Login Screen
        ↓
User Submits Email + Password
        ↓
Express Route Handler
    ├─ Validate Email Format
    ├─ Check User Exists (Registration) or Verify (Login)
    ├─ Hash Password with bcryptjs
    └─ Generate JWT Token
        ↓
Token Sent to Frontend
        ↓
AsyncStorage: Store Token Securely
        ↓
Axios Interceptor: Add Token to Every Request
        ↓
Protected Routes Unlocked
        ↓
Redux/Context: Auth State Updated
        ↓
Dashboard & Payment Screens Accessible ✓
```

### Component Architecture (Frontend)

```
Root App (_layout.tsx)
├── Bottom Tab Navigator
│   ├── Home (Index Screen)
│   ├── ARCamera Screen
│   ├── History Screen
│   └── Profile Screen
│
├── Modal Navigation (Non-Tab Routes)
│   ├── Login Screen
│   ├── Signup Screen
│   ├── Payment Confirmation
│   └── Success/Failure Screens
│
└── Navigation Context
    ├── Auth State Management
    ├── User Session Management
    └── Deep Linking Support
```

### Backend API Structure

```
/api
├── /auth
│   ├── POST /register       → Create new user
│   ├── POST /login          → Authenticate & get token
│   ├── POST /logout         → Invalidate token
│   └── GET /verify          → Check token validity
│
├── /payments
│   ├── POST /process        → Process new payment
│   ├── GET /status/:id      → Get payment status
│   ├── PUT /update/:id      → Update payment record
│   └── DELETE /:id          → Cancel payment
│
├── /transactions
│   ├── GET /                → Get user's transactions
│   ├── GET /:id             → Get single transaction
│   ├── GET /filter          → Filter by date/status
│   └── POST /export         → Export history (CSV)
│
├── /users
│   ├── GET /profile         → Get user profile
│   ├── PUT /profile         → Update profile
│   └── POST /upload-avatar  → Upload user avatar
│
└── Middleware
    ├── Auth Verification    → JWT validation
    ├── Error Handler        → Centralized error handling
    ├── Logger               → Request/response logging
    └── Rate Limiter         → API rate limiting
```

## Key Design Patterns

### 1. **JWT-Based Stateless Authentication**
- Frontend stores JWT in AsyncStorage
- Every API request includes token in Authorization header
- Backend verifies token signature and expiration
- **Benefit**: Scalable, stateless, no server-side sessions needed

### 2. **Axios Interceptors for API Consistency**
- Request interceptor: Auto-attach JWT token
- Response interceptor: Handle 401 errors globally
- Error interceptor: Centralized error handling
- **Benefit**: DRY principle, consistent API behavior

### 3. **Component-Based UI Architecture**
- Reusable components (ThemedText, ThemedView)
- Screen components for routing
- Navigation container for state
- **Benefit**: Modular, maintainable, testable UI

### 4. **Mongoose Schema Validation**
- Define data structure at database level
- Automatic validation on insert/update
- Type enforcement and default values
- **Benefit**: Data consistency, prevents invalid records

### 5. **Express Middleware Pipeline**
- Request flows through middleware chain
- Each middleware adds functionality (auth, validation, logging)
- Error handling middleware catches all errors
- **Benefit**: Clean separation of concerns, reusable logic

### 6. **AsyncStorage for Offline-First Architecture**
- Cache user data locally
- Sync with backend when online
- Survives app restart and network disconnects
- **Benefit**: Better UX, reduced API calls

## Key Learnings & Best Practices

### Frontend Insights

Building a cross-platform mobile app with React Native revealed the importance of:

1. **Platform-Specific Considerations**: iOS and Android have different UI patterns, camera permissions, and storage mechanisms. Using Expo abstracts much of this, but understanding platform differences remains crucial.

2. **Efficient State Management**: AsyncStorage for persistence and Expo Router for navigation provide a simpler alternative to Redux for many use cases. Start simple, add complexity only when needed.

3. **AR Integration Complexity**: React Viro requires careful handling of camera permissions, Three.js transforms, and memory management. Testing on real devices is essential—simulators can hide performance issues.

4. **Real-time Updates**: Using Axios interceptors and proper error handling ensures consistent API behavior across all requests. This is more effective than prop drilling and callback hell.

5. **Testing Strategy**: With Jest and Cypress, unit test components and integration test critical flows (auth, payment). E2E tests should focus on user journeys, not implementation details.

### Backend Insights

Designing a scalable Node.js/Express API highlighted:

1. **Middleware-Oriented Architecture**: Express middleware provides a clean pattern for cross-cutting concerns (logging, validation, auth). Order matters—middleware executes top to bottom.

2. **Database Design Matters**: Proper MongoDB schema design with indexes on frequently queried fields (userId, paymentStatus, createdAt) significantly impacts performance.

3. **Security as Default**: Always validate input, hash passwords with bcryptjs, use HTTPS in production, implement rate limiting, and store secrets in environment variables—never in code.

4. **Error Handling Consistency**: A centralized error handler middleware ensures all errors return consistent HTTP status codes and JSON structures, making frontend error handling predictable.

5. **Stateless Design**: JWT-based authentication eliminates the need for server-side sessions, making horizontal scaling trivial. Multiple server instances can handle requests independently.

6. **API Versioning**: Design APIs with versioning in mind (`/api/v1/`, `/api/v2/`) from the start to avoid breaking existing clients during updates.

### Full-Stack Integration

The complete system demonstrates:

1. **Separation of Concerns**: The frontend focuses on UX, the backend on data integrity and security. Neither should leak into the other's domain.

2. **Contract-Based Development**: Define API contracts (request/response schemas) upfront. This allows frontend and backend development to proceed in parallel.

3. **Type Safety**: Using TypeScript on both frontend and backend catches errors at development time, reducing runtime bugs and improving developer productivity.

4. **Observability**: Implement logging on both sides. Frontend logs to analytics service, backend logs to centralized logging (ELK stack, Datadog, etc.). This helps diagnose production issues.

5. **Continuous Deployment**: Automate testing and deployment with GitHub Actions. This catches integration issues early and enables frequent, low-risk releases.

## Scalability & Future Extensions

### Current Scalability
- **Horizontal**: Stateless API design allows multiple server instances
- **Vertical**: Efficient database queries with proper indexing
- **Database**: MongoDB sharding for very large datasets

### Potential Enhancements
- **Payment Gateway Integration**: Stripe, PayPal, or local payment providers
- **Push Notifications**: Real-time payment confirmations via Expo Notifications
- **Advanced AR**: 3D models, body tracking, environmental understanding
- **Analytics Dashboard**: Charts and metrics for transaction analysis
- **Admin Panel**: Management interface for payments and users
- **Social Features**: Share transactions, split payments, payment links
- **Internationalization**: Multi-language support with i18n
- **Dark Mode**: Theme toggle with persistent preference
- **Offline Mode**: Complete offline capability with sync queue
- **AI/ML**: Fraud detection, spending predictions, recommendations

## Deployment Strategy

### Frontend
1. Build with EAS (`eas build --platform ios` and `android`)
2. Test on TestFlight (iOS) and Google Play Beta (Android)
3. Submit to App Store and Google Play
4. Monitor crash reports and user feedback

### Backend
1. Push to GitHub
2. GitHub Actions runs tests and builds Docker image
3. Deploy to Railway or Heroku with automatic scaling
4. MongoDB Atlas handles database backups and recovery
5. Monitor with logging and error tracking (Sentry)

## Conclusion

This AR payment application demonstrates a complete full-stack implementation with modern technologies and best practices. It balances rapid development with code quality, scalability with simplicity, and user experience with security.

The separation between frontend and backend, combined with clear data contracts and comprehensive testing, creates a maintainable foundation for future growth and feature expansion.

Key takeaway: **Start simple with a clean architecture, test thoroughly, and scale incrementally**—this approach has proven effective for both the calendar app and this more complex payment system.

---


Full-stack AR-powered payment application built with React Native, Expo, and the MERN stack. The application combines immersive augmented reality experiences with secure payment processing and real-time transaction management.

AR Payment App


## Description

Heroes App is a modern React frontend application that enables users to search, browse, and manage their favorite superhero characters. The application demonstrates best practices in state management, data fetching optimization, and component architecture using contemporary React patterns and tools.

Built as part of the React Zero to Expert course, this project showcases production-ready code with TypeScript, comprehensive error handling, and a responsive user interface optimized for all device sizes.

## Key Features

- **Real-time hero search** with optimized request deduplication
- **Efficient data fetching** powered by React Query with automatic caching
- **Favorite heroes management** using Context API with localStorage persistence
- **Detailed hero profiles** displaying stats, powers, and biographies
- **Responsive design** optimized for mobile, tablet, and desktop devices
- **Loading states and skeletons** for better user experience
- **Type-safe implementation** with full TypeScript support
- **Modern UI components** built with Radix UI and Tailwind CSS

## Tech Stack

- **Frontend Framework**: React 19 with React DOM
- **Routing**: React Router v7 with nested routes
- **Server State Management**: React Query (TanStack Query) v5.81
- **Client State Management**: Context API for favorites
- **HTTP Client**: Axios with interceptors
- **Styling**: Tailwind CSS v4.1 with responsive utilities
- **Component Library**: Radix UI for accessible components
- **Type Safety**: TypeScript v5.8
- **Build Tool**: Vite v7.0 with React SWC plugin
- **Testing**: Vitest v3.2 with React Testing Library
- **Icons**: Lucide React v0.525

## Architecture Highlights

### Separation of Concerns

The application follows a clear layered architecture:

```
API Layer → Actions Layer → Hooks Layer → Components
```

- **API Layer** (`heroes/api/`): Raw HTTP requests with Axios
- **Actions Layer** (`heroes/actions/`): Query functions for React Query
- **Hooks Layer** (`heroes/hooks/`): Custom hooks abstracting Redux/Query complexity
- **Components**: Presentation components consuming hooks

This separation makes the codebase highly maintainable and testable.

### React Query for Server State

React Query handles all server state with built-in benefits:

- **Automatic caching** of API responses
- **Request deduplication** preventing redundant API calls
- **Background refetching** for fresh data
- **Optimistic updates** for better UX
- **Stale state handling** and cache invalidation

```typescript
const { data: heroes, isLoading, error } = useQuery({
  queryKey: ['heroes'],
  queryFn: getAllHeroes,
  staleTime: 5 * 60 * 1000,
  gcTime: 10 * 60 * 1000,
});
```

### Context API for Client State

Client state (favorites) is managed elegantly with Context API:

- **No prop drilling** across component tree
- **Easy to understand** compared to Redux
- **Lightweight implementation** suitable for this use case
- **localStorage persistence** for data retention

### TypeScript for Type Safety

Full TypeScript implementation ensures:

- **Compile-time error detection**
- **Superior IDE autocomplete**
- **Self-documenting code** through type definitions
- **Refactoring confidence** with type checking

## Key Learnings

**React Query is transformative for data fetching.** Managing server state with useQuery eliminates countless edge cases around caching, deduplication, and background updates. Compared to manual useState + useEffect patterns, React Query provides production-ready solutions out-of-the-box.

**Layered architecture enables scalability.** By separating API calls from component logic, the codebase remains maintainable as it grows. Each layer has a single responsibility, making changes and testing straightforward.

**Context API is sufficient for moderate client state.** While Redux is powerful, Context API paired with custom hooks is ideal for applications with moderate state complexity like favorite management. The simpler mental model reduces overhead without sacrificing functionality.

**Tailwind CSS accelerates UI development.** Utility-first CSS enabled rapid iteration on responsive layouts without context-switching between files. The built-in responsive modifiers (`md:`, `lg:`) make cross-device design seamless.

**TypeScript prevents entire classes of bugs.** Type safety caught several potential issues during development, particularly around API response shapes and hero object properties. The investment in typing pays dividends immediately.

## Project Structure

```
src/
├── router/                 # React Router configuration
├── heroes/
│   ├── api/               # Axios API setup
│   ├── context/           # Context API (Favorites)
│   ├── hooks/             # Custom hooks (useQuery, useContext)
│   ├── actions/           # Query functions for React Query
│   ├── types/             # TypeScript interfaces
│   ├── components/        # UI components
│   ├── pages/             # Page components
│   └── layouts/           # Layout components
├── admin/                 # Admin section (extensible)
├── components/            # Shared components
└── lib/                   # Utility functions
```

## Development Experience

The development experience is excellent:

- **Vite** provides near-instant hot module replacement
- **React Query DevTools** enables debugging cached data
- **TypeScript** catches errors before runtime
- **Vitest** runs unit tests with fast feedback loops
- **Tailwind IntelliSense** offers real-time CSS suggestions

## Performance Optimizations

The application includes several performance considerations:

- **Query caching** reduces unnecessary API requests
- **Request deduplication** prevents duplicate fetches
- **Component memoization** avoids unnecessary re-renders
- **Code splitting** via React Router for lazy-loaded routes
- **Responsive images** with Tailwind's image utilities
- **CSS optimization** through Tailwind's purging

## Future Enhancements

Potential improvements for expanding the application:

- **Advanced filtering and sorting** by power levels
- **Hero comparison tool** side-by-side analysis
- **Dark mode toggle** with Tailwind CSS
- **Internationalization (i18n)** for multiple languages
- **Analytics integration** tracking user behavior
- **Offline mode** with service workers
- **E2E testing** with Cypress or Playwright
- **Component Storybook** for UI documentation
- **PWA support** for app-like experience

## Deployment

The application is deployment-ready and can be hosted on:

- **Vercel** (recommended for Next.js-like performance)
- **Railway** for containerized deployments
- **Netlify** for static hosting
- **GitHub Pages** for free static hosting

Environment variables are managed through `.env.local` and include:

```env
VITE_HERO_API_URL=https://superhero-api.com/api
```

## Conclusion

Heroes App demonstrates modern React development practices with emphasis on developer experience, performance, and maintainability. The combination of React Query, Context API, TypeScript, and Tailwind CSS creates a solid foundation for building scalable frontend applications.

The project serves as a reference implementation for team members learning React and as a template for similar data-driven applications.


Modern React application for searching and managing favorite superhero characters. Built with React 19, React Query, React Router v7, and Tailwind CSS. Features real-time search, optimized data fetching with caching, and favorite management using Context API.

Heroes App - Search & Favorite Superhero Characters


## Description

Full-stack calendar application built with the MERN stack, featuring a modern React frontend and a robust Node.js/Express backend API. The application enables real-time event management with secure authentication and a scalable architecture.

It is designed to deliver a seamless user experience while maintaining a clear separation between client and server responsibilities.

## Key Features

- **Full-stack architecture** with React frontend and RESTful API backend
- **Secure authentication** using JWT with persistent sessions
- **Complete CRUD** operations for calendar events
- **Real-time UI updates** without page reloads
- **Protected routes** and user authorization
- **Centralized state management** using Redux Toolkit
- **Responsive and modern UI** optimized for all devices
- **Per-user data isolation** ensuring privacy and security

## Tech Stack

- **Frontend**: React 18 with Vite, React Router
- **Styling**: CSS
- **State Management**: Redux Toolkit + React-Redux
- **Backend**: Node.js with Express.js
- **Database**: MongoDB (Mongoose ODM)
- **Authentication**: JWT + bcrypt
- **HTTP Client**: Axios
- **UI Components**: React Big Calendar, SweetAlert2
- **Deployment**: GitHub Actions → Vercel or custom hosting

## Architecture

The application follows a scalable full-stack architecture with clear separation of concerns:

Frontend (Client)
- Handles UI rendering and user interactions
- Uses Redux for centralized state management
- Communicates with backend via HTTP requests

Backend (Server)
- Exposes RESTful API endpoints
- Handles authentication, authorization, and business logic
- Manages data persistence with MongoDB

Data Flow
- User actions trigger frontend state updates
- Async operations call the backend API
- Backend processes requests and returns JSON responses
- Redux updates the UI in real time

This layered approach ensures maintainability, scalability, and testability across the entire application.

## Key Learnings

Building a full-stack application highlighted the importance of separating concerns between frontend and backend while maintaining a consistent data flow.

On the frontend, using Redux Toolkit enables predictable state management and real-time UI updates. On the backend, implementing stateless authentication with JWT improves scalability and simplifies session handling.

Additionally, structuring both layers with clear responsibilities (API, state management, UI, and database) results in a more maintainable and extensible system, making it easier to scale and introduce new features over time.

Full-stack calendar application built with the MERN stack, featuring a modern React frontend and a robust Node.js/Express backend API.

Calendar


## Description

This is the website you are currently viewing—a professional portfolio combined with a personal blog. It is built with Next.js 13 using the Pages Router and leverages full static generation to ensure fast and efficient deployment.

## Key Features

- **Fully featured blog** powered by Markdown files with frontmatter support
- **Projects section** designed to showcase work to recruiters and collaborators
- **Syntax highlighting** implemented with react-syntax-highlighter
- **Modern and professional** design with a dark theme
- **Automated deployment** via GitHub Actions
- **Fully static architecture** — no database and no API calls at build time
- **Responsive design** — optimized for mobile, tablet, and desktop
- **SEO optimized** using Next.js Head and meta tags

## Tech Stack

- **Frontend**: React 18 with Next.js 13 (Pages Router)
- **Styling**: CSS Modules with CSS variables
- **Content Management**: Markdown with gray-matter for frontmatter parsing
- **Typography**: Oswald (headings), Roboto (body), Source Code Pro (code)
- **Deployment**: GitHub Actions → Vercel or custom hosting

## Key Learnings

Maintaining a clear separation between the data layer (`lib/projects-util.js` and `lib/posts-util.js`) and presentation components significantly improves code maintainability and testability.

Using CSS Modules instead of a CSS framework ensures proper style scoping and prevents conflicts across components.

Additionally, implementing a well-structured dark theme with clearly defined CSS tokens enables consistent and efficient feature development.

Personal website built with Next.js. Includes a blog with Markdown support and syntax highlighting, automatic deployment via GitHub Actions, deployed on Vercel. Redesigned with Claude Code.

All Projects