Every project starts with someone showing me how they actually work.

A business running on spreadsheets and email attachments

Why they called

Azuri, an environmental compliance consultancy, was living out of Excel and email. Every client's documents — permits, submissions, supporting files for their compliance work — arrived as attachments, got saved wherever, and lived in whichever spreadsheet was open at the time. They wanted one secure place for client data that they could actually search.

What I noticed

The spreadsheets weren't the disease, they were the symptom. The real issue was that client information had no home. Finding a document meant remembering who emailed it and when. Answering "what have we received from this client?" meant archaeology. And for a compliance business, "we can't find it" isn't an inconvenience — it's a liability.

Learning their workflow

I sat with the team and traced the life of a single client submission: how it arrived, who touched it, where it ended up, and how someone tried to find it three months later. That map — not a feature wishlist — is what shaped the build. The structure had to mirror how they actually think: by client, by requirement, by date.

What I built

A secure client data platform: every document and submission stored in one place, organized per client, searchable and filterable across all of it. Need everything from one client for one requirement in one date range? Three clicks, not three hours of inbox spelunking.

Then the documents started answering questions

Why they called

This one grew directly out of the data platform. Once Azuri's documents finally lived in one searchable place, a new pattern became visible: people weren't just looking for documents — they were looking for answers inside them, and a keyword search can't tell you what a 90-page technical report concludes.

What I noticed

Routine questions still routed to the same senior people, because they were the only ones who knew which document — and which section — held the answer. The bottleneck had moved from "where is the file?" to "where in the file?"

Learning their workflow

I collected the questions the team actually asked over a couple of weeks — real ones, not hypotheticals — and traced where each answer lived. That shaped the design rule the whole build hangs on: the assistant must cite its sources. In compliance work, an answer you can't verify is worse than no answer.

What I built

A private AI assistant on top of their document library. Ask in plain English; it answers in seconds and points at the exact document and section it drew from, so nobody takes the machine's word for anything. It runs on their documents only — no internet guessing — and their data stays theirs.

The trainer whose whole business lived in one Google Doc

Why they called

BSMT Personal Training came to me for a basic website — a place to point new people to. Simple enough, and I built it. But the interesting part was what I saw while learning the business.

What I noticed

He didn't have a marketing problem — referrals were rolling in on their own. He had a scaling problem. The entire operation ran through one sprawling Google Doc and a wall of text threads: who's paid for how many sessions, what each client did last workout, who's due, who's traveling. Every new client made the doc heavier and the texting louder. The business could only grow as fast as his thumbs.

Learning their workflow

I went through the actual doc and the actual threads with him — how a session got logged, how a package got sold, how a "wait, how many sessions do I have left?" text got answered. The pattern was clear: clients wanted visibility, and he was the only window into it.

What I built

A custom client portal. Each client logs in and sees how many sessions they have left, what they did each workout, and their progress over time. He logs a session once and everyone's numbers stay straight — no reconciliation texts, no doc-scrolling.

The Sunday-night invoicing session, retired

Why they called

A small family-owned farming operation — the kind of business where everyone does three jobs — was drowning in end-of-week paperwork. Crews wrote job tickets by hand in the field all week; then someone spent Sunday evening re-typing every ticket into invoices.

What I noticed

Watching the process, the waste was obvious but the cause was subtle: the same information was being written down three times — once on the ticket, once in the invoice, once in the records book. And every re-typing was a chance for an error a customer would catch before they did.

Learning their workflow

Off-the-shelf invoicing apps had failed them already, because those apps assume an office worker at a desk. Their reality was a crew lead with dirty gloves and a truck cab. So I shaped the tool around the ticket they already used — same fields, same order, same shorthand — instead of asking the crews to learn something new.

What I built

A custom single-entry system: a job gets recorded once, in the familiar ticket format, and the invoice, the records, and the weekly totals all follow from that one entry. No re-typing, no transcription errors, no Sunday session.

The client I couldn't say no to: my parents' store

Why they called

They didn't call — they're my parents, and I've watched their laundry store run for years. Pickup and drop-off scheduling happened the way it always had: the phone rings, whoever's at the press stops mid-garment, a time gets scribbled somewhere near the register, and everyone hopes the scribble survives the day.

What I noticed

Every scheduling call was a double loss — it interrupted paid work at the counter or the press, and the scribbled-note system meant the occasional missed pickup, which is the fastest way to lose a loyal customer. Meanwhile, plenty of customers would happily have booked at 10pm from their couch, when the store can't answer a phone at all.

Learning their workflow

This was the deepest workflow study I'll ever do — years of it. But building for family keeps you honest: the tool had to work for customers who aren't tech-savvy, in more than one language, and fit around how the store actually routes its day. No feature survived unless it made the counter quieter.

What I built

A simple online scheduling system for pickups and drop-offs: customers pick a time window from their phone, the store gets a clean list of the day's pickups and drop-offs instead of a constellation of sticky notes, and the phone rings less during the busiest hours.

The inquiry that came in at 9pm — and got answered at 9:01

Why they called

A small real estate team had a problem every service business will recognize: leads arrive around the clock — listing inquiries, website forms, portal messages — but people can only answer during the day. And in real estate, the first agent to respond usually wins the client.

What I noticed

Mapping a week of inquiries told the story: a big share landed evenings and weekends, exactly when nobody was at a desk. By morning, the hot ones had already heard back from somebody else. They weren't losing leads to better agents — they were losing them to faster clocks.

Learning their workflow

I listened to how the agents actually talked to new leads — the questions they asked first (buying or selling? timeline? area? pre-approved?), the tone they used, what made a lead worth a same-day call. The system had to sound like them and sort like them, not like a robot with a form.

What I built

A lead response agent that watches their inbox and forms, replies within minutes at any hour in their voice, asks those same qualifying questions, and texts the agent a clean summary — so the morning starts with a sorted list of who's hot, not a pile of cold emails.

A study assistant that never misquotes scripture

Why they called

A Bible study leader had tried general AI chatbots for preparing sessions and hit the dealbreaker fast: the tools would confidently invent verses — real-sounding references that didn't exist, or paraphrases presented as quotations. For scripture study, "close enough" is disqualifying.

What I noticed

The need wasn't a chatbot that knows everything — it was the opposite: an assistant with a deliberately closed world. Specific translations, and a set of trusted commentaries they already used. Nothing else. The trust would come from what it couldn't say.

Learning their workflow

I sat in on how sessions actually got prepared: pick a passage, gather cross-references, check the commentary, build discussion questions. Hours of flipping between books and browser tabs. The assistant needed to serve that exact prep loop — passage in, connected material out — not replace the studying itself.

What I built

A retrieval-based study assistant built only on their chosen translations and commentaries. Every quotation is pulled verbatim from the source text with chapter and verse cited; if the answer isn't in its library, it says so instead of improvising.

your business could be story #8 ↓