I build software that actually ships.

• Delivered a live site for a real client, end to end
• Accessibility pass — contrast, focus order, semantic structure
• Content structured for clarity and easy client updates

Problem

A licensed therapist needed a professional web presence that would help new clients find her and feel comfortable reaching out — calm and trustworthy, not clinical or generic.

Built

I designed and built the full site solo: services, approach, and a clear contact path. I focused on accessibility (WCAG-conscious contrast, semantic structure, sensible focus order), responsive layout for phones, and fast load times — then structured the content so it's easy to update.

Result

A live site for a real paying client, in production today. It gives her practice a credible front door and a simple way for prospective clients to get in touch — my first end-to-end delivery for someone who is paying for the outcome, not the code.

What I'd change

If I rebuilt it today I'd move it onto Next.js and wire a lightweight CMS so she can edit her own copy without me, and add privacy-friendly analytics from day one — so we can see whether the site is actually turning visits into new-client inquiries, not just assume it.

• Designed and built the studio site plus every trade-specific demo template, solo
• Each demo is a self-contained page that personalizes per business via URL params
• Runs the full offer end to end — design, build, hosting, and ongoing care

Problem

Plenty of local service businesses either have no website or an outdated, slow one — and they quietly lose customers to competitors who simply show up better online.

Built

I built a productized studio: a system of fast, self-contained site templates spanning many trades, each personalizable to a specific business, plus the studio's own front page presenting the offer, a live demo gallery, FAQ, and a guarantee. Everything is deployed on Vercel at studio.brandondickey.dev.

Result

A live studio and demo gallery I can put in front of any prospect on the spot, and a first paying client shipped to production. It's proof I can take a service from offer to delivery, not just write the code.

What I'd change

The build was the easy part — the real lever is distribution: getting in front of the right local owners. If I keep pushing it, my next step is wiring privacy-friendly analytics and a clear intake funnel so I can see which demos actually turn into conversations.

• Designed a FastAPI + SQLite back-end for ingestion and scoring
• Built the Next.js front-end: catalog UI, deal alerts, inventory tracker
• End-to-end ownership — data model, API, and interface

Problem

Finding underpriced resale items means watching several marketplaces at once and eyeballing whether a listing is actually a good deal — slow, manual, and easy to miss.

Built

I built the whole stack myself. A FastAPI + SQLite back-end ingests listings and scores them against comparable sales to flag undervalued ones; a Next.js/TypeScript front-end presents a browsable catalog, a 'Deal Radar' that surfaces the best finds, and an inventory tracker. Buying stays a guided, human-in-the-loop checkout — the app suggests, the person decides.

Result

A working full-stack app that demonstrates my range end to end: data in through an API, insight out through a considered UI. It's my clearest proof that I can own a feature from the database to the screen.

What I'd change

The scoring is only as trustworthy as the comparables behind it. My next step is swapping the seed dataset for live marketplace feeds and back-testing the 'undervalued' calls against real sold prices — because a deal score nobody has validated is just a guess with a confident font.

• User-perspective QA on a live, in-production product used by institutional clients
• Report bugs and edge cases, then pitch the fixes and changes that ship
• Help keep the platform demo-ready across releases

built with Logan Guest (lead developer)

• User-perspective testing on a live, shipped website
• Flagged issues and pitched changes that shipped

• Turned a fuzzy 'is this worth buying?' problem into a usable interface
• Built the React/TypeScript front-end around a clear decision-support UX
• Held a firm 'the tool suggests, the buyer decides' design principle

Problem

Resale buyers and store owners have to size up on the spot whether an item is worth buying — margins are easy to misjudge, and it's easy to overpay when you're moving fast.

Built

I built a decision-support tool that runs profit-forward analysis on a potential buy and surfaces a clear confidence signal, with the person always making the final call. I designed the React/TypeScript interface around one principle I kept firm the whole way: the tool suggests, the buyer decides — it augments judgment, it never auto-buys.

Result

An in-progress product that shows I can take a vague, real-world problem and turn it into a focused, usable interface with a clear point of view — my own build, start to finish.

What I'd change

The hardest part wasn't the math — it was resisting the urge to let the tool auto-decide. If I kept building I'd put the confidence signal in front of real buyers early and let their overrides tune it, rather than trusting my own assumptions about what a 'good buy' looks like.

• Integrated third-party market data APIs
• Scheduled background jobs with error handling
• Self-directed — chosen and shipped on my own initiative

Problem

Reacting to live market data by hand is slow and inconsistent. I wanted to teach myself how to automate the full loop — pull data, evaluate it, act — and make it run reliably without me watching.

Built

I wrote Python bots that pull live market data on a schedule, evaluate it against defined rules, and take action automatically. The real lessons were in the unglamorous parts: handling flaky third-party APIs, retrying failed jobs, and keeping the schedule dependable.

Result

Working automation experiments that gave me hands-on reps with third-party APIs, background jobs, and reliability — and, just as importantly, show the self-driven habit of picking a hard thing and shipping it on my own initiative.

What I'd change

Early on I treated the happy path as 'done' and got burned by silent failures when an API rate-limited me overnight. The real lesson was that reliability is a feature: logging, retries, and alerting are what separate a script from something you can actually leave running.