Apps, automations, and AI-powered workflows — scoped tightly, documented properly, and tested on real people before I call them done.
Three minutes: how I work, and a walkthrough of what's below.
Live products with paying customers — not demos.
Takes someone's mood, flavor preference, and wellness focus and returns a blend they can actually make — with proportions, steeping guidance, and a reflection prompt.
Built from a written spec that's still the source of truth. The spec defined the output contract as JSON before anything was built, so the app, the sales page, and the printable companion pages could all be built against the same shape instead of drifting apart. It also has a section listing what the product is not allowed to do — which, because the language boundary was fixed up front, turned the input categories into a controlled vocabulary rather than free text. A cleaner design, arrived at through a constraint.
People kept telling me AI images "weren't for them." None of them were stuck on the technology — they'd all opened ChatGPT. They were stuck on the empty box. They didn't know that a good image prompt names the lighting, the camera angle, the setting, and the mood.
So the app asks eight plain-language questions and writes the prompt for them. Copy, paste, done. It deliberately does not generate the image. Doing that would have added API cost, failure states, and a support burden — and it would have moved the product away from the actual problem. Keeping it a prompt generator means it works with whatever AI tool someone already has, and it'll still work when they switch.
A fast-lookup companion to a printed herbal guide. The design decision that mattered: the app never states dosage amounts. Every entry links back to the guide page where the age-by-age charts live.
Partly a legal boundary — dosing guidance inside an interactive tool carries risk that the same information in an educational PDF doesn't. Partly product: the app and the guide work better as a matched pair than as two things competing to be complete. It gives the guide a reason to exist and keeps the app to the job it's good at.
Hand-built, live, and starting to travel.
I built and shipped both of my brand sites myself — controlling the structure, the copy, and the design, not filling in a template. They're where I learned to take a site from blank screen to live.
And that skill is starting to travel: I'm building a site for a small local bread business right now, with a t-shirt shop next. Early and informal, but real practice building for someone other than myself.
Where the pieces talk to each other.
I've been building a team of role-based AI assistants — each one a reusable skill file that gives a "team member" a job, my voice, and standards to hold itself to. So far: operations, communications, sales, and marketing, with more on the way. I call them by name, and one of them writes nothing without running a five-point check first — is it accurate, relevant, appropriate, complete, and does it sound like me.
The part I'm proudest of is that they work together. I can put them in a room, have them talk a decision through, and hand me back one plan. That's the difference between a pile of prompts and an actual team — and it's the clearest example of the thing I care about most: building systems that hold together, not one-off tricks.
And I didn't build it to be clever. I built it so one person — me, around a full-time teaching job — can deliver everything I plan this year without burning out or dropping the ball. That's the test I hold every system to: does it make the work more sustainable for the person actually doing it?
Not a chat window I paste code out of. A structured workspace where Claude reads persistent context before it acts, follows written behavioral rules, executes documented SOPs, and reaches real tools through MCP connections — MailerLite, Gamma, Canva, Base44, Lovable, Google Drive.
The thing I'd point at first is a rules file called look-before-asking.md. My biggest
early friction wasn't wrong output — it was being asked questions I'd already answered somewhere in
the workspace. That file maps question types to the file that holds the answer, and draws an explicit
line between "proceed with a stated assumption" and "stop and ask one focused question." It cut the
back-and-forth more than any other change I made.
When Claude gets something wrong in my workspace, the fix is almost always a file, not a better prompt.
Intake answers flow into a structured sheet, become a per-client knowledge base, and come out the other end as a drafted plan — without anything being retyped into three places. Built to remove the part of client work that was pure transcription.
The small things that decide whether something is actually useful.
I sell printable pages. For months I attached each one as a PDF and considered it shipped.
Then I watched how people actually used them. Some downloaded the PDF and printed it. Others screenshotted the preview image off the post and printed that — because on a phone, opening a PDF and getting it to a printer is four steps, and screenshotting is one. Those screenshots printed badly: low resolution, cropped edges, prompts cut off.
Those people were getting a worse version of the thing and I would never have heard about it, because nobody emails you to say your free page printed a little fuzzy. The fix took ten minutes: attach a print-ready PDF and a 300 dpi PNG to every post, so the one-step path produces a good result too.
I run live sessions where I walk through a printable page on screen while people write on paper. I found that if the slides don't mirror the printed page exactly — same prompts, same order, one prompt per slide — people lose their place and stop writing.
It's not a design preference. It's the difference between a session where people participate and one where they watch. That rule is now written into the SOP for every live I run.
Documented so a tired version of me produces the same result as a rested one.
Four live sessions a week and a daily post, all pre-produced. Every recurring series has a written SOP: inputs, steps, where files land, what gets published where, and a compliance check that runs every time.
The part that makes it work isn't the steps — it's the list at the bottom of every SOP of reusable assets to build once. Week one took a full day. Week four takes an evening, because the templates, the standard copy blocks, and the layouts already exist. The weekly cost stays flat instead of growing with the series.
Every significant decision gets logged with its reasoning — and an outcome field that's filled in later. The outcome field is the part I'd argue for hardest. It turns the log from a record of what I chose into a record of whether my reasoning was any good, which is the only way to get better at the next one.
The constraint that shaped everything above.
I teach special education and dyslexia intervention full time. Everything here was built in evenings and weekends, which means anything requiring me to re-explain context, re-decide a settled question, or remember an undocumented step simply would not have survived.
That's made me unusually strict about two things. Scoping work so it actually finishes — I'd rather ship the smaller thing that's genuinely done than the ambitious one stuck at eighty percent. And asking whether something should be built at all — the image generator I didn't build, the dosing information I kept out of an app, the features I've cut because they'd have made the demo better and the product worse.
And testing before it ships. Nothing I make goes live on my say-so alone — two or three people put it through its paces first, and I test it hard myself before that. I'd rather be the one who finds the broken thing than have a user find it. "The code works" is where I start, not where I stop.
Teaching is also where the rest of it comes from. The whole job is taking something a student is convinced they can't do, finding the step where it actually breaks, and removing everything that isn't that step. That's the same instinct I bring to a confusing interface.