Brad Hobbs Dacula, GA

Work

Things I’ve built.

Personal projects, concepts, and portfolio samples, each labeled for what it is. None of these are presented as paid client work, and none include client code or data. Client case studies will be added once clients approve them.

  • Concept designed to show an approach, for a fictional business
  • Sample a working example with fictional data
  • Personal project something I built and use
Concept · fictional business
oakstreetplumbing.example
Concept homepage for a fictional plumber with a call button, towns served, and a quote form
The same concept on a phone, with a sticky Call now button

Website refresh

Oak Street Plumbing concept

Problem
Many older small-business sites open with a generic welcome, never say which towns they serve, and hide the phone number in the footer as plain text that can’t be tapped.
Approach
Start with what a customer is trying to do on a phone, which is to find out whether you serve their area and then call. Put the services, towns served, and a one-tap call button on the first screen, and keep the quote form to three fields.
What I built
A responsive homepage concept with a sticky call bar on phones, clear hours, a list of towns served, and a short quote form. The business, phone number, and details are all fictional.
  • HTML
  • CSS
  • Responsive design
  • Accessibility basics
View the concept site →
Sample · fictional data
community-resource-directory
Resource directory with a search box, category and city filters, and four result cards
The directory on a phone with stacked filters

Web · Accessibility

Community resource directory

Problem
People looking for local help need to filter quickly by need and city, and see right away how many options match.
Approach
Keep the public side small and clear, with one search box, two filters, a visible result count, and proper labels and focus states.
What I built
A React and TypeScript directory with automated tests. The records are fictional, and it hasn’t had a formal accessibility audit.
  • React
  • TypeScript
  • Vite
  • Tests
View code ↗
Sample · fictional data
expo-universal-picks · web
Weekend picks web app listing three fictional matchups with team buttons
Weekend picks running on a phone

Mobile + Web

Weekend picks: one app, three platforms

Problem
Building the same screens separately for iPhone, Android, and the web triples the work and the bugs.
Approach
Share one interface and one set of rules, like when a pick locks based on local time, across every platform.
What I built
An Expo React Native app that also runs in the browser. There are no accounts, odds, or wagers; it only demonstrates the shared build.
  • React Native
  • Expo
  • TypeScript
View code ↗
● Personal project · live
Workout tracker week view on a phone

Web app · AWS

Workout tracker

Problem
A flexible weekly routine didn’t fit fixed-schedule apps, and none of them offered useful recovery guidance.
Approach
A calendar-first log plus a rules engine that reads each workout and recommends recovery, with its reasons.
What I built
A multi-user React app with an illustrated stretch guide and 8-week progress charts, on a serverless AWS backend (Lambda, API Gateway, S3, CloudFront) defined with AWS CDK.
  • React
  • Vite
  • AWS Lambda
  • API Gateway
  • S3
  • CloudFront
  • AWS CDK
Open live app ↗View code ↗
Sample · fictional data
electron-web-shared-views
Workspace notes app with search, a category filter, and three note cards

Desktop · Electron

Desktop + web shared views

Problem
Teams that ship both a desktop app and a web app often maintain two copies of the same screens, and the two drift apart.
Approach
Keep one view and feature model, and let each platform supply only what’s different, like file access on desktop.
What I built
An Electron + React sample with a searchable notes screen that runs the same code in the desktop app and in the browser.
  • Electron
  • React
  • TypeScript
View code ↗
Sample · fictional data
ai-first-react-workspace
Work-item queue with totals, filters, and three fictional items

AI-assisted development

AI-ready React workspace

Problem
AI coding tools move fast, but without shared context and checks their changes are hard to trust and review.
Approach
Give the AI agent and the human the same architecture map, conventions, feature spec, and verification commands, and let CI fail if docs fall out of date.
What I built
A small work-item queue app inside a repo with agent guidance, docs-as-code, an implementation-ready spec, tests, and a documentation check in CI.
  • React
  • TypeScript
  • Vite
  • GitHub Actions
View code ↗
Sample · fake AI provider

AI · Reliability

AI request guardrails

Problem
A single AI request can fail in many ways, like bad input, a duplicate click, a slow response, or output in the wrong shape, and each needs handling before it reaches a customer.
Approach
Wrap every call in the same small set of guardrails and record what happened, so failures are visible and repeat requests don’t cost twice.
What I built
A dependency-light TypeScript library with tests and a demo. It uses a fake provider, so it runs without API keys, costs, or customer data.
  • TypeScript
  • Node.js
  • Tests
View code ↗

More on GitHub, including offline sync, AWS CDK and Terraform infrastructure, and a .NET + PostgreSQL API.

Next step

Want something like this for your business?

Pick whichever is easiest. If there’s a good fit, I’ll send a short written scope. If not, I’ll tell you, and you’ll leave with at least one useful idea.

Book a 15-minute callPick a time that works for you. Opens my Google Calendar booking page.Choose a time ↗
Call or textLeave a message if I’m with a client.(912) 663-9223CallText
EmailSend a link to your site and what’s bugging you.brad@bradhobbs.dev

I reply within one business day.