What I'vebuilt.

The Problem

People were booking Apple Store appointments for problems Google could solve in 30 seconds.

I watched people in my own life do this — take half a day off, drive to a mall, wait in line — for a frozen screen or a battery that drained too fast. The information to fix it was out there. What was missing was a single place that just told you what to do, clearly, without making you feel like an idiot. That seemed fixable.

What I Built

An AI support tool that skips the appointment entirely.

You describe your iPhone problem in plain English, you get a real answer. Battery drain, frozen screen, storage issues, Wi-Fi dropping — it covers the stuff people actually Google at 11pm. No login. No upsell. No "have you tried turning it off and on again." Just a clear fix, fast.

What I Learned

How to wire an AI API into a production app and ship it without a build process.

This was my introduction to the Anthropic Claude API — learning how to authenticate requests, structure the message payload, handle streaming vs. non-streaming responses, and surface AI output cleanly in a UI. I learned how to write system prompts that constrain the model to a specific domain so it stays on topic and useful. I built the entire app as a single self-contained HTML file — all logic, styles, and API calls in one place — which taught me the value of zero-dependency architecture for fast shipping and easy deployment.

The Problem

Trade workers are out here grinding — and still relying on word of mouth to find work.

These are skilled people with full schedules and real demand in their area. But the tools they have for finding new business are either nonexistent or designed to extract money from them. Pay-per-lead platforms, overpriced directories, referral dependency — none of it actually puts them in control. I wanted to build something that did.

What I Built

A prospecting tool that actually works for the person using it.

TradeSpot lets a worker open a map, search by category, and see every local business that might need their services — right now. It generates a call script, lets you export leads, and covers 18 trade categories. Free for the worker. Businesses pay to be found. That model flip — charging the supply side, not the demand side — was the whole point.

What I Learned

How to build a location-aware app using the full Google Maps platform.

TradeSpot was my deep dive into Google's Maps ecosystem. I learned how to embed an interactive map using the Maps JavaScript API, retrieve the user's current location via the browser's Geolocation API, and run live business searches filtered by category and radius using the Places API. The Geocoding API let me convert plain addresses into lat/lng coordinates for accurate map placement. I also learned how to manage API keys properly — restricting them by HTTP referrer so they can't be abused — and how to handle API rate limits and quota errors gracefully so the UI never breaks on the user.

The Problem

Every serious UFC bettor is doing the same manual research. Nobody built them a shortcut.

The data exists — fight history, fighter styles, live odds across every book. People were pulling it from four different tabs and making gut calls anyway. The gap wasn't information. It was synthesis. Nobody had put live odds, line movement, and historical matchup patterns in the same place.

What I Built

One screen with everything a UFC bettor actually needs.

OctagonOdds pulls live odds, shows how lines have moved, and surfaces fighter style matchup data pulled from 2,200+ historical fights. You can see how a wrestler performs against a volume striker, or whether a submission artist has historically struggled on the feet. It doesn't tell you who to bet. It gives you a real basis for deciding.

What I Learned

How to build and operate a real backend with a live database and automated data pipelines.

OctagonOdds was my first real server-side project. I built a Flask application deployed on Render with a SQLite database on a persistent disk at /data/ufc_odds.db. I learned how to write a background polling thread that hits The Odds API on a schedule without any manual trigger — the server just keeps the database current automatically. I built a custom web scraper that pulls fight history and fighter stats from ufcstats.com, and learned how to structure REST API endpoints in Flask, handle CORS between a separate frontend and backend, and architect a data pipeline that runs continuously. I also learned how to connect a GitHub repo to Render for auto-deploy — push to main, the server redeploys itself.

The Problem

Personal trainers and PTs are good at their jobs. The paperwork is killing them.

Session notes, client progress summaries, follow-up reminders — it piles up fast. I talked to practitioners who were spending an hour after every shift just writing things down. The existing tools weren't built for them — they were generic practice management software with a skin on top. Nobody had solved the actual friction point: getting notes done without it becoming a second job.

What I Built

You talk like a human. It writes like a professional.

Practitioners submit session notes by text or photo — however they actually capture things in the moment — and Debrief turns them into a clean structured summary with action items and follow-up questions. No formatting. No templates to fill out. You capture the session your way, the app handles the rest.

What I Learned

How to build a full-stack app with authentication, a real database, and serverless functions.

Debrief was my most technically complex build. I learned Supabase end to end — provisioning a PostgreSQL database, writing table schemas, configuring row-level security policies so users can only access their own data, and wiring up auth with session persistence across page loads. On the frontend I used React with Vite for the first time — learning component architecture, hooks like useState and useEffect, and the npm build pipeline from dev to production dist/ folder. The AI calls run through a Netlify serverless function that proxies to the Anthropic API, keeping the key off the client entirely. That pattern — serverless function as a secure API proxy — is one I now use on every project that touches a third-party API.

The Problem

Every high school graduate gets told to go to college. Half of them shouldn't.

Not because they're not capable — because college isn't the only path, and for a lot of people it's not the right one. Trades, military service, apprenticeships, gap years — these exist, they work, and they're almost never presented as real options. The guidance counselor conversation defaults to college every time. I wanted to build the resource that actually lays it all out.

What I Built

A no-agenda reference for what actually comes after high school.

Groundwork covers college, trades, military, and alternative paths — what each one looks like, what it costs, and what it leads to. Written plainly, without an admissions pitch attached. The student is the reader. The school or counselor is the buyer. They're the ones with budgets and a real need to have this conversation at scale.

What I Learned

How to register a custom domain, configure DNS, and take a site fully live end to end.

Groundwork was where I learned the full domain-to-live workflow that I now apply to every project. I registered a custom domain (postgrad.wiki), learned how to set A records and CNAME records in a DNS registrar, pointed the domain at Netlify, and provisioned an SSL certificate via Let's Encrypt. I also set up Netlify Forms for contact and feedback capture — no backend code required — and configured email notifications so form submissions route directly to my inbox. Understanding DNS propagation, HTTPS configuration, and form handling without a server were all firsts on this project.