Work

Products, the agents that maintain them, and the tools that build both.

These are the ones I can show you. My day-to-day is enterprise software behind a login — IoT platforms, case management, identity migrations — so what follows is the work that lives in public.

01 · Own productLive on both stores

Wander Wallet

The problem

Travel logistics live in a dozen browser tabs — exchange rates, safety advisories, connectivity, weather, passport scans, what to actually do on Tuesday. None of it talks to each other, and none of it survives the flight.

What I built
The whole architecture — a scalable Firebase backend with Angular and Ionic on the client, released to iOS and Android from one codebase via Capacitor.
An AI travel assistant on Azure Semantic Kernel and OpenAI: contextual chat completion, function calling for live weather, and streaming responses wired into the Ionic UI.
Currency and unit conversion built to keep working offline, plus storage for travel documents and the details you need at a border.
Google Maps and Cloud Vision integrations driving packing, restaurant and lodging recommendations tied to a specific place.
Safety, connectivity and cost-of-living scoring per destination, normalised onto one ordinal scale so "good" means the same thing everywhere.
Atlas — a warm-white design system I extracted from live SCSS into one token set, then rolled across twelve screens so the app stops drifting.
Where it stands

Live on the App Store and Google Play and updated steadily — more than twenty releases since December 2025, version 1.37 as of August 2026. Everything described here is in production, not on a roadmap.

Stack
AngularIonicCapacitorFirebase AuthFirestoreFunctionsGoAzure Semantic KernelOpenAICloud VisionGoogle MapsBigQuery
App StoreGoogle Play
Wander Wallet itinerary: Trip to Guadalajara, a five-day plan with a booked flight, revise-itinerary and Ask AI actions
Wander Wallet multi-currency converter showing live mid-market rates

Itinerary and converter, running on Atlas — Warm White.

02 · AI infrastructureRunning in production

An agent that triages its own production errors

The problem

A one-person product means production errors compete directly with feature work. Sentry fires at 2am and the context needed to understand it is scattered across Cloud Logging, Firestore and the repo — twenty minutes of gathering before the thinking even starts.

What I built
Two ingress paths — an HMAC-validated Sentry webhook and a Cloud Logging sink through Pub/Sub — normalised into one event shape. Handlers acknowledge immediately and process fire-and-forget, so a slow investigation never triggers a retry storm.
An atomic Firestore claim before any model call, keyed on the request trace ID — so one failed request emitting forty log lines still produces exactly one investigation and one PR.
A two-tier model cascade: a cheap triage call separates actionable bugs from GPS, permission and device noise, and only survivors reach the expensive reasoning step. Most events die for a fraction of a cent.
An investigation loop with real read access — repo files, Sentry events, log queries, Firestore documents — hard-capped at ten iterations, returning a root cause and the full corrected file.
Output is always a draft PR, never a direct commit, and the prompt forbids refactoring beyond the fix. The agent proposes; I still merge.
Four .NET MCP servers on Cloud Run underneath it — Firestore, Cloud Logging, BigQuery over the GA4 export, and a partner activities API — bearer-authed from Secret Manager, with dual stdio/HTTP transport so one binary serves both my editor sessions and the agent.
Why it matters

The engineering here isn't the model call — it's the containment around it. Dedup, tiered cost, capped loops, a budget alarm and draft-only output are what make an autonomous agent something you can leave running against production.

Stack
C# .NET 10Minimal APIsCloud RunPub/SubFirestoreSecret ManagerBigQueryModel Context ProtocolAnthropic APISentryGitHub REST
The pipeline
Sentry webhook · GCP log sink
↓
Normalise to one event
↓
Atomic dedup claim
↓
Triage — cheap model
↓
Investigate — tool-use loop
↓
Draft pull request

Every stage is capped, deduped or gated before it can spend.

03 · Client workLive

Mariposa Home Care

The problem

Home care is two sales at once. Families are deciding who to trust with a parent or a newborn, while the agency competes just as hard for the caregivers who make that care possible. One site has to do both jobs without either audience feeling like an afterthought.

What I built
Two service tracks with distinct colour identities inside one navy brand — green for senior care, orange for new-family wellness — so a visitor knows within a second which half of the site is theirs.
A caregiver side that's a real funnel rather than a careers link: a recruitment page feeding a dedicated application flow, so hiring runs through the same site as client acquisition.
Instrumentation the owner actually reads: a four-stage conversion funnel from landing to submit, contact events tagged with method, service interest and the exact button that fired them, and ZIP capture that maps where demand is coming from.
Accessibility built in rather than retrofitted — skip-to-content link, themed focus states, a focusable main landmark, and scroll restoration on every route change.
Eight lazy-loaded routes behind Suspense with a branded loader, and a Firebase Functions contact pipeline that confirms by toast — because this site gets read on a phone in a hospital parking lot.
Why it matters

The analytics layer is built so the owner never has to guess whether the site is working. Instead of "we got an inquiry," it can answer which button, which service, which ZIP code — the information a small business needs when deciding where to advertise and hire.

Stack
React 19TypeScriptViteTailwindDaisyUIReact RouterFirebase FunctionsFirebase Analytics
Visit the site
Mariposa Home Care
Three audiences, one site
Senior care — families choosing help for a parent
New family wellness — postpartum support
Caregivers — recruitment and application

Eight routes, two service identities, one navy brand.

Also built
04 · Client work
MooreHelp Moving

A mobile-first site for a Colorado Springs moving company. One Functions endpoint sends the owner notification and the customer confirmation on every submit, and mirrors each lead to a locked-down Firestore collection so a mail failure can't lose a job.

React 19Tailwind v4FunctionsNodeMailer
Live site
05 · Personal
Travel journal

Photography and favourite places, mapped with the Google Maps Platform. Built on the Angular, Material and Firebase stack I use for client work — a place to keep it sharp on something personal.

Angular 20MaterialGoogle Maps
Live site
06 · Prototype
AI travel recommendations

The prototype that became Wander Wallet's recommendation engine: an OpenAI-backed destination brief with live weather, a safety score and a connectivity score, wired to Cloud Functions and a Firestore cache.

AngularOpenAIFunctions
Folded into Wander Wallet
Freelance

I take on a few freelance builds a year.

Mariposa and MooreHelp above are both freelance work: one developer from first conversation to launch — design, frontend, backend, deployment, and the analytics to know what the site is actually doing.

An engagement starts with what the business needs, not a spec. I scope small, show working software early, and hand over something the owner can run without me.

Tell me what you're building — Brendon.carrasquillo@gmail.com

Looking for someone who owns the whole thing?

Open to remote roles and positions in the Denver metro, plus select freelance builds. Tell me what you're building.

LinkedIn