I tend to multitask. Yes, I know they have shown we’re less efficient when we do, but my brain likes to hop around. Well, until it finds a rabbit hole full of something particularly sparkly. Then I become oblivious to everything around me.

Right now I have four different projects open in VS Code on my desktop, and I hop back and forth between them. I also have Lovable going and GitHub open in different web browsers. Knowing when something finishes lets me keep things moving along.

Until recently I kept the sound turned off on my devices. When working in a shared space, it was just rude to have Teams dinging every 15 seconds. I also have the ringer on my phone off. And honestly, it’s because I like the quiet. I used to put in Loops as well.

But now it’s a bit different. I’m at home. The only ones I can disturb are my family. My husband can’t hear most of the noises from my devices, so he’s not bothered by them. And often my daughter has ear buds in, listening to music or YouTube. So I’m less concerned about disturbing anyone.

I had turned on sounds in desktop Claude and ChatGPT while I was digging deeply into a data issue. It kept me from forgetting to check something for an hour. Very helpful. The other night I realized I wasn’t getting notices and sounds from Claude and Codex when they finished something. In VS Code. I decided to understand why.

My first try, I added different sounds for Lovelace and Rowan. That way I would know which one had completed. These sounds are different from my desktop sounds: Glass for Lovelace and Sosumi for Rowan. Lovable had its own sound. So now I could have Rowan (Codex) creating a set of images while Lovelace (Claude) was writing test cases and Sully (Lovable) was building out my site. It was awesome.

Then came the runner. I have a project that has let me learn some new-to-me things. In this case, a self-hosted GitHub runner. When something happens in GitHub, like a new issue or a label change, a workflow can start a job. A runner is the computer that runs that job. GitHub provides its own, but you can register your own computer instead. Mine is my MacBook.

I’m doing this so I can drive a series of work from a GitHub Issue, passing work back and forth between my AI thinking partners. The runner uses a terminal on my Mac and the command line tools to send prompts to my thinking partners to do my work. Because it runs on my machine, it uses my setup: my logins, my settings, and my sounds.

Which made me wonder, am I getting notices from the runner too? It seemed like I was, and the times matched up to the events in GitHub. So I decided the runner needed to be distinct.

I used the Mac’s say command to create “Lovelace is done” and “Rowan is done.” This way I know a step in my runner has completed and the next step is starting. My runner also has GitHub notifications, so if there is an issue, I hear a finish followed by a problem message from GitHub.

My next experiment is including Sullivan (Lovable). I already point Sully to an issue for Sully to do the work. Next is telling Sully to check again when it’s their turn. I have ideas.

In the meantime, here are the steps I used to create these sounds on my MacBook. Lovelace compiled them from the couple of sessions where we made these tweaks. I hope you find them helpful.

Subscribe now

Why a sound helps

Here’s what each sound means:

A chime means someone I’m working with is ready. A spoken name means a background run finished a step, and tells me whose. Each sound also pops up a small notification, in case I’m out of earshot.

Where this works: on a Mac, with the agents running in VS Code, which is where I use them. The same settings also work when the agents run in Terminal. The Claude and Codex desktop apps are different: they have their own notification settings, so look in each app’s settings instead. Setup takes about ten minutes.

Claude Code in VS Code

Claude Code runs a command of your choice at set moments, called hooks. Two hooks do the job here:

• Stop runs when Claude finishes its reply.

• Notification runs when Claude needs you, such as to approve a step.

The hooks go in your settings file, ~/.claude/settings.json in your home folder. Settings there apply to every project, in VS Code and in the terminal. Add a "hooks" section like this one (if the file already has settings, keep them and add this beside them):

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "if [ -n \"$GITHUB_ACTIONS\" ]; then osascript -e 'display notification \"Lovelace finished a runner stage\" with title \"Go runner\"'; afplay ~/Library/Sounds/LovelaceDone.aiff; else osascript -e 'display notification \"Lovelace has finished\" with title \"Lovelace\" sound name \"Glass\"'; fi 2>/dev/null || true"
          }
        ]
      }
    ],
    "Notification": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "osascript -e 'display notification \"Lovelace needs your attention\" with title \"Lovelace\" sound name \"Ping\"' 2>/dev/null || true"
          }
        ]
      }
    ]
  }
}

osascript, the Mac’s built-in way to run a small script, shows the notification. In a live session it also plays the Glass or Ping chime. When the if sees an unattended run or runner (see Live sessions and unattended runs, below), it shows a different notification and afplay plays a spoken sound I made (see Your own sounds). The || true at the end means a failed sound never gets in Claude’s way. Swap in your own agent’s name and sounds.

You don’t have to edit the file yourself. You can ask Claude: “Play the Glass chime with a notification when you finish and Ping when you need my attention, but in GitHub Actions play my LovelaceDone sound instead.” It knows how to add the hooks. If you don’t hear anything after a change, start a new session.

Codex in VSCode

Codex has one setting for this, notify. It runs a program each time Codex finishes a turn. It has no separate “needs you” moment, so Codex gets one sound.

1. Make a small script, ~/.codex/notify-rowan.sh:

#!/bin/sh
# Codex runs this when it finishes a turn.
if [ -n "$GITHUB_ACTIONS" ]; then
  osascript -e 'display notification "Rowan finished a runner stage" with title "Go runner"' >/dev/null 2>&1
  afplay ~/Library/Sounds/RowanDone.aiff >/dev/null 2>&1
else
  osascript -e 'display notification "Rowan has finished" with title "Rowan" sound name "Sosumi"' >/dev/null 2>&1
fi
exit 0

1. Let it run, in Terminal: chmod +x ~/.codex/notify-rowan.sh

2. Point Codex at it, in ~/.codex/config.toml, near the top of the file (outside any [section]):

notify = ["/Users/yourname/.codex/notify-rowan.sh"]

1. Use your full path: ~ doesn’t work here.

2. Restart Codex.

Check for an existing notify line first. Codex allows only one, and another tool may already use it. Mine was set by Codex’s own Computer Use feature. Don’t replace it: copy its command into the top of your script, so both run. Otherwise that feature quietly stops working.

Picking your sounds

Use a different sound for each agent and each moment, so you can tell them apart by ear. A Mac comes with 14 alert sounds:

Basso, Blow, Bottle, Frog, Funk, Glass, Hero, Morse, Ping, Pop, Purr, Sosumi, Submarine, Tink.

To hear one, type this in Terminal, with the name you want:

afplay /System/Library/Sounds/Sosumi.aiff

A bright sound for “finished” and a softer one for “needs you” works well. A notification plays a built-in sound by name, as in the examples above: sound name "Glass", with the name as listed and no .aiff.

Your own sounds

You aren’t limited to the 14. A notification’s own sound name plays only the Mac’s built-in sounds: I tried my own, and got the notification in silence. So keep your own sound files in the Sounds folder of your Library, and play them with afplay beside the notification.

The easiest custom sound is a spoken one. The Mac’s say command saves words straight to an AIFF file, with no download or conversion:

mkdir -p ~/Library/Sounds
say -v "Tara (English (India))" -o ~/Library/Sounds/LovelaceDone.aiff "Lovelace is done"
say -v Moira -o ~/Library/Sounds/RowanDone.aiff "Rowan is done"

-v picks the voice, so each agent can sound different. say -v '?' lists the voices on your Mac; use the name exactly as listed, in quotes if it has spaces.

Then play one with afplay ~/Library/Sounds/LovelaceDone.aiff. You hear which agent is ready, without learning which chime is whose.

For any other clip, such as a recording of your own or a free sound effect:

1. Choose a short clip, a second or two. Long sounds get cut off.

2. Convert it to the Mac’s AIFF format, in Terminal (this example turns chime.mp3 from Downloads into one called Chime):

mkdir -p ~/Library/Sounds
afconvert ~/Downloads/chime.mp3 ~/Library/Sounds/Chime.aiff -f AIFF -d BEI16

1. Play it in your hook: afplay ~/Library/Sounds/Chime.aiff.

Test it in Terminal with that same afplay line before you add it to a hook.

Live sessions and unattended runs

The hooks and the notify script run wherever the agent runs, including runs you didn’t start by hand. I run some agent work from GitHub Actions on my own Mac, and at first those runs chimed exactly like my live sessions. I couldn’t tell which instance was pinging me.

GitHub Actions sets GITHUB_ACTIONS=true for everything it starts, agents included. That’s what the if [ -n "$GITHUB_ACTIONS" ] in both examples checks. Other automation tools set their own variable, such as CI=true; check yours. I tested both agents this way: Claude Code’s hooks and Codex’s notify script both run in unattended mode (claude -p and codex exec).

To see where past chimes came from, open Notification Center by clicking the clock in the menu bar: each one is listed with its time.

If you hear nothing

• Test the command on its own. Paste the osascript -e '…' part into Terminal. If that’s silent too, the problem is your Mac’s settings, not the agent.

• A notification but no sound? A notification’s sound name plays only the Mac’s built-in sounds. Play your own file with afplay instead.

• Allow the notifications. In System Settings → Notifications, find Script Editor, which shows these alerts, and turn on Allow notifications.

• Check Focus. Do Not Disturb and other Focus modes hide notifications and their sounds.

• Check the volume. Alert sounds have their own slider, in System Settings → Sound.

• Start a new session. Agents read their settings when they start.

I read someone on LinkedIn say, “Why use Lovable or Base44? Claude can go do everything for you.”

I’m sure there was a time in my life when I would have made a similar uninformed statement. For that matter, maybe I have recently and was too clueless to realize it.

That statement assumes a lot. It assumes that anyone knows what “everything” is. How to set up a web app. Domain management. Email management. Payment management. And sure, Claude can get you set up with all those things. But if you’ve never built an app before, saying that isn’t a daunting list seems unaware at best.

I’ve been in tech for a long time, and there was definitely a time when I had very strong opinions about code generators. Around 1997, I had a friend who was a WebObjects guru. He knew it inside and out. But I quickly saw other people using it without his depth of knowledge, and they couldn’t debug a problem with a flashlight and a big red arrow pointing at it. It generated code, and people shrugged and said, “It works.”

I’ve had a few experiences like that in my career. People use packages they can’t debug. I couldn’t understand why anyone would want to create something they couldn’t understand well enough to fix.

It wasn’t that long ago that I still felt that way.

Yep, I’m eating those words now. I’m drinking the AI Koolaid like I’ve been walking through the desert for a year.

But here’s what changed. In 1997, the generator wrote the code and left. When it broke, you were on your own. Now the same tool that wrote the code will stay with you and help you figure out why it broke. Not understanding every line isn’t the risk it used to be when you have something to ask.

That doesn’t mean you can stop paying attention. AI can help you debug, but you still have to notice something is wrong. Security problems don’t come with a big red arrow.

I love Claude. I use it every day. But Lovable has become my favorite thing to use. Why? Because I don’t have to worry about web hosting, patching servers or Stripe integration. It handles all the fiddly bits. Isn’t that the point of AI, handling the fiddly bits so we can do the fun parts? I know that’s why I’m using it.

I still have my web hosting on Pair Networks, and I’m using Digital Ocean. But Lovable is just fun. I can focus on what I want to build. I hook it into GitHub so I can use all my standard development processes. I use PostHog for telemetry. I use one-time passcodes (OTP), so I no longer have to manage passwords, and the emails are just templates I update. I can focus on the app itself.

It’s funny to me when people say there won’t be any more software engineers because everyone can build software themselves. It isn’t true. Most people don’t want to build it themselves. And if they do, they don’t want to know every single detail or manage connections to a pile of different services. Lovable lowers the barrier for someone who just wants to build an app for themselves, their family or their small business. They don’t want to become a software and security expert.

Why use Lovable? Because it’s fun.

Subscribe now

Well, 51 issues became 69, and 9 essays became 10. I always find something I missed, and this felt like a big one.

I realized my glossary is something helpful, and an artifact I want to maintain. Now all 54 terms are in one place, and as I write, I’ll continue to expand the glossary. I’ll be making this a link on Code Like A Little Old Lady, and you can always find it in the repository below.

The glossary lives in a starter repository, Show Me Your Prompts. The README.md tells you about all the files and which essay they map to.

Even when I thought I was done, I added one more piece: a small sample app that runs the examples so you can see the test coverage for yourself.

This repository was built by Lovelace (Claude) and code reviewed by Rowan (ChatGPT). It’s not the full three reviewers, but if you look at the pull request history, Rowan found issues. Even having a second AI is helpful. We followed the process of feature branches with pull requests to dev until we had all the features complete, and then did a pull request from dev to main.

Feel free to fork this repository and use what you need. Or don’t. This is just my way, far from the only way to work.

Thank you for following me on this journey. I hope you found something helpful.

— The Little Old Lady

This is a 9-part series outlining the way I worked for #SheBuilds.

If you’re curious where I started, check out Part 1: Show Me Your Prompts

Subscribe now

This is a 9-part series outlining the way I worked for #SheBuilds.

If you’re curious where I started, check out Part 1: Show Me Your Prompts

Subscribe now

ou have finished a feature and it’s now in your dev branch, what’s next? For me, I do another pull request, only this time to main. The branch main is where my production version of the application lives. This is the version I show the world.

Each pull request to dev gives me a new version in preview. The goal is, if you’re going to break something, break it in preview not production. We’ve all gone to a website or an app and it breaks. It’s the worst. You want to avoid being that app.

I mentioned how I group my issues into features. As I finish each feature, when something works end to end, I do another pull request to main. Oh no, another pull request and another round of reviews. Yup. You may be thinking, what could they find, it’s already been reviewed. There’s always something. Generally it is small. But if it isn’t small, yeah, you found it before you released it to the world!

In pull requests to main, if you find an issue, you don’t fix it right there. If you remember, we set the dev branch to only allow changes from a pull request, so we can’t change it directly in dev. That’s ok. Instead you’ll create an issue with the finding and then decide, does this block the release or can it be fixed later. Often it can wait. Sometimes it can’t. If it can’t, you create a new feature branch from dev, fix the issue, do the pull request to dev, and it will then be picked up by the existing pull request to main.

My rule has been if it is something that will break the user or a security violation, it needs to go. If it’s a corner case or minor, it waits. Remember we started with 51 issues and ended with 69. That’s where some of them came from.

And you might think I should just let a change happen in dev. And I could. Or I could just create a branch off main and fix it there. All definitely things you can do. I choose not to do it. I like to avoid dealing with merge conflicts if I can avoid it. We haven’t talked about that bit of fun. If you create a feature branch off main and fix it, that fix won’t be in dev. So you’ll need to merge main into dev. Totally viable. But I like simplicity. Again, this is another large topic. A fun one. Maybe later.

So you complete the PR. Then, on Lovable’s Git page, you change your branch from dev to main, just how you’ve changed from feature branch to dev after each issue.

It’s all set. Woo hoo. Now you can push the publish button. It’s blue, not red. But it is the same feeling. Never hit the big red button. If you have done things in features, you can publish a feature at a time. Or you can wait until the whole project is done. I like that feeling of “I finished something”. I publish after each feature is complete.

You work through your features, issues become feature branches, a group of issues is a feature, each issue has a pull request until the feature is complete in dev. Then you move the feature to main and release. And now you’re done.

My app can be found here:

What The Plate?

Here’s my little demo video.

And here’s my overall stats on what I built

I still have a few outstanding issues to complete, but I built everything I wanted for #SheBuilds. While #SheBuilds was 3 days, I’ve turned it into a month-plus with my preplanning and now my post write-up.

Did I make it in the top 30 or win? No, not even. But that wasn’t my goal. My goal was to try a new way of working while still incorporating the fundamentals I consider important. And I did that. Would what I do fly in a corporate job? Maybe. I probably do more sanity checks than some folks would consider necessary. But honestly, even when I was doing it all by hand that’s how I worked. In data work, once something is wrong, people lose trust in your answers.

When I look at the definition of vibe coding, I recognize what I do doesn’t necessarily align. But for me, it’s very hands off compared to any other coding I’ve done, so I’m sticking with that name. I let the AI do the validation by using multiple AI. I’m just there to steer the ship. And in many ways it aligns with how I’ve worked as a manager. I provide direction and guard rails with the occasional check in, but I trust others to do the work.

And my real win here? My husband asked to look at my repository. He told me it was well organized and he could follow what I’d done. That means I’ve built something others can understand. That means someone else can pick it up and make changes. It’s not just me.

What would I do differently for #SheBuilds? More social time. I didn’t participate in the Slack channel in a meaningful way. I was very focused on the build. I worked as a typical dev at a desk where someone shoves pizza under the door. And that really wasn’t the goal of #SheBuilds, it was to support others in learning and growing. Hopefully this series makes up for that gap. Maybe in the next #SheBuilds someone will find this series and it will help them plan their project.

But they should know, this is just one way to build, the one that works for me. There is no one right way to do things. Find what works for you and follow it!

I shared alot in this series. I have added a 10th essay with a link to resources mentioned throughout the series.

Glossary

• Accessibility (A11y): making sure an app works for everyone, including people using screen readers or keyboards

• Admin (administrator): the person who runs the site, blocking spam, clearing issues, and keeping things running

• Anonymize: to remove anything that connects data to a specific person

• Bot: an automated account that acts on its own, like a named reviewer leaving comments

• Branch: a separate copy of the project where you can make changes without touching the main version

• Brief: a written description of the product. Names, fields, limits, rules. No code.

• Check in: saving your changes to the repository

• Code coverage: how much of your code is exercised by your automated tests

• Code review: someone else reading your changes before they’re merged, looking for problems

• Commit: a saved set of changes in a branch

• Continuous integration (CI): automatically building and testing every change as soon as it’s submitted

• Dev branch: the working branch. What it holds is what you see on the preview site.

• Diff: the lines that changed between two versions of the code

• End to end (E2E): the full journey through the app, from first screen to last

• Entity: one kind of thing the database stores, like a plate, a story, or a user

• ERD (entity relationship diagram): a picture of the entities and how they connect

• Feature branch: a short-lived branch for one piece of work, named for its step

• GitHub: a website for storing projects, their history, and the work planned for them

• GitHub Copilot (GHCP): GitHub’s built-in AI assistant, which can review pull requests

• Hello world: the simplest possible starter program, traditionally a page that just says hello

• Hero image: the large image at the top of a page

• Issue: a single task tracked in GitHub. In this series, each issue is one step.

• Label: a tag on an issue that tells you something about it at a glance. Mine say who does the work.

• Memory: what Rowan and Lovelace pick up over time from working with me

• Merge: bringing the changes from one branch into another

• Merge conflict: when two branches change the same lines differently, and someone has to decide which version wins (new)

• Milestone: a group of issues that together complete something larger

• Palette: the set of colors a design is allowed to use

• Preview site: a private copy of your site built from the dev branch, for checking work before publishing

• Production: the live version of your app, the one the world sees (new)

• Project knowledge: the place in Lovable where the brief lives, read by Sully with every prompt

• Prompt: the instructions you give an AI to do a piece of work

• Proof of concept: a quick, rough build to see whether an idea works

• Publish: to make the site live for everyone, built from the main branch

• Pull request: a request to move changes from one branch into another, so they can be checked and reviewed first

• Push: sending your commits up to GitHub

• Regenerate: when an AI image tool redraws the whole image instead of changing one part

• Regression: an error in something that was previously working

• Release: sending a finished set of changes out to production (new)

• Remix: Lovable’s way of starting a new project from an existing one

• Repository (repo): where a project’s files and history live in GitHub

• Role: a label on an account, like admin, that decides what that person can see and do

• Ruleset: a set of GitHub rules protecting a branch, such as requiring a pull request for every change

• Sandbox: a safe, separate space to run code without affecting anything real

• Schema: the blueprint for a database: what things it stores and how they connect

• Seed data: a starting set of data loaded into a new database

• Source code management (SCM): a system for storing code and tracking every change to it

• Static page: a page that looks real but doesn’t do anything yet

• Storyboard: the set of screens showing how a user moves from page to page

• Telemetry: data an app collects about how it’s used and what it was doing when something went wrong

• Test harness: the automated tests and checks that run on every change to confirm nothing broke

• Token: the unit AI tools use to measure text, and often to charge for it

• Vibe coding: building software mostly by directing AI in plain language rather than writing code yourself (new)

• Visual guide: a single page showing every color, style, and component the app uses

This is a 9-part series outlining the way I worked for #SheBuilds.

If you’re curious where I started, check out Part 1: Show Me Your Prompts

Subscribe now

We’re making our way into the home stretch. Yesterday we started working through the prompts. Open an issue with a prompt, create a feature branch, create the code in the feature branch, do a pull request to put it back into dev.

Now you could just do a pull request and be done. But a step in the middle is a code review. This is where you look at the code to try to find any problems before you release the code. Ideally you would want a couple folks to look over your work, in hopes they will notice things you miss.

Back up Alison, AI wrote this code, why do I need to do a code review? We built that whole test harness and all those build scans and everything is green. Isn’t that good enough? Ah, great question, and no, it’s not enough, you might be surprised what turns up in the code review.

The title is Three Reviewers, Three Perspectives, so what does that mean. I’ve talked about the Inner Chamber, my thinking partners. We’ve talked about Sullivan (Sully), my Lovable AI builder. Sully built all the code for #SheBuilds. Then I have Wiggins (GitHub Copilot), Lovelace (Claude), and Rowan (ChatGPT) who review Sully’s code. They are each running a different model, meaning they already have strengths and weaknesses. And I’ve given them each different ways to look at a problem. I find with the three different agents, while I get some overlap, only about 10% of what they find overlaps.

I’ve found that Rowan does really well reviewing database code. I find this very amusing as reviewing database code has always been my strength. She also tends to do cleanup, closing out the items that are verified as fixed. And most of all, Rowan makes sure the graphic design holds or makes suggestions when there are problems. Lovelace is great at finding testing gaps. She not only reviews the code but runs it in a sandbox looking for problems. Lastly we have Wiggins. I’ve found the GHCP model is great at finding potential security issues and more targeted issues compared to the system level findings from Lovelace.

Here’s a step I didn’t put in the diagram: before Sully writes any code, the plan gets reviewed. The way the process works is not that different from working with any team. We have the issue that describes the problem to be fixed. Sully reads the issue, comes up with a plan, and writes it in the issue. Rowan and Lovelace both have connections to my repository with the ability to read and write on it. I created bots with each of their names and images so I can keep track of who has done what. They review Sully’s plan until the three of them sign off.

Sully then writes the code and creates the pull request. Again, I have Lovelace and Rowan read the pull request details and review the code. They read the issue being fixed and the plan to be followed to make sure everything is built as discussed. If Sully has to make a change to the plan, it is noted in the issue. Based upon the roles each of them has, Sully will ask for a specific reviewer to confirm the change to plan.

Most code reviews are done looking at the diff, the changes made, and providing feedback on just that code. But just like any code review, a reviewer may notice something around the change isn’t right and also provide feedback on that.

Wiggins is part of GitHub, so on the pull request I just have to request he do a code review. I have my dev branch set to run a Wiggins code review on every pull request. I admit, I have burned through more credits than I planned here. I made sure to turn off doing a review on every push. It would start a new code review each time something was committed to the repository, and Sully does a lot of small commits.

This is where one issue == one prompt == one change is so important. The more code the AI has to create, the more likely something will be missed. The same holds true for review: the more code, the more gets missed. AI is just like any team member, give them too much to look at and they start to wander to look at something sparkly.

Of course, the issue with AI is they can quickly start to agree with you and each other. Teams do this too. People who work together long enough know Bob will find X, Ryley will find Y, and Beth will pull it all together. So far there has not been any outright disagreement, but there has been, this isn’t a priority now, and instead of fixing it, they will create an issue to track for fixing later. Again, just like every team I’ve ever worked on.

And just like every team I’ve been on, sometimes an additional set of hands is needed, and that’s where they pull me in. They outline pros and cons of a solution and we discuss what is the ultimate goal. And we make plan adjustments, or create more GitHub issues and keep moving forward.

At this point you’re probably thinking, that’s a lot of faff. You do a round creating prompts, a round creating plans (or multiple if needed), and a round of doing code reviews (or multiple if needed). AI is supposed to make this all easier. And AI has made this all easier. This process matches the process I’ve done for years with teams, but AI can get a plan written in minutes compared to days, code bugs found and fixed faster than a human could set up a debugging environment, and get a code review done faster than any team I’ve ever worked on. Sometimes code reviews would sit for days waiting on a reviewer.

So yes, I think this faff is worth it. This allows me as an individual creating code to get a wider perspective than just what’s rattling around in my own brain.

We follow this process for every issue, doing pull requests to dev until we have completed a feature. In an earlier essay I talked about multiple issues making up a feature and my ordering by 10s. Well, once we finish one of those groups, we will do a pull request and code review to main and then publish the work.

And that’s where we’ll end tomorrow, From Done to Deployed.

Glossary

• Accessibility (A11y): making sure an app works for everyone, including people using screen readers or keyboards

• Admin (administrator): the person who runs the site, blocking spam, clearing issues, and keeping things running

• Anonymize: to remove anything that connects data to a specific person

• Bot: an automated account that acts on its own, like a named reviewer leaving comments (new)

• Branch: a separate copy of the project where you can make changes without touching the main version

• Brief: a written description of the product. Names, fields, limits, rules. No code.

• Check in: saving your changes to the repository

• Code coverage: how much of your code is exercised by your automated tests

• Code review: someone else reading your changes before they’re merged, looking for problems

• Commit: a saved set of changes in a branch (new)

• Continuous integration (CI): automatically building and testing every change as soon as it’s submitted

• Dev branch: the working branch. What it holds is what you see on the preview site.

• Diff: the lines that changed between two versions of the code (new)

• End to end (E2E): the full journey through the app, from first screen to last

• Entity: one kind of thing the database stores, like a plate, a story, or a user

• ERD (entity relationship diagram): a picture of the entities and how they connect

• Feature branch: a short-lived branch for one piece of work, named for its step

• GitHub: a website for storing projects, their history, and the work planned for them

• GitHub Copilot (GHCP): GitHub’s built-in AI assistant, which can review pull requests (new)

• Hello world: the simplest possible starter program, traditionally a page that just says hello

• Hero image: the large image at the top of a page

• Issue: a single task tracked in GitHub. In this series, each issue is one step.

• Label: a tag on an issue that tells you something about it at a glance. Mine say who does the work.

• Memory: what Rowan and Lovelace pick up over time from working with me

• Merge: bringing the changes from one branch into another

• Milestone: a group of issues that together complete something larger

• Palette: the set of colors a design is allowed to use

• Preview site: a private copy of your site built from the dev branch, for checking work before publishing

• Project knowledge: the place in Lovable where the brief lives, read by Sully with every prompt

• Prompt: the instructions you give an AI to do a piece of work

• Proof of concept: a quick, rough build to see whether an idea works

• Publish: to make the site live for everyone, built from the main branch

• Pull request: a request to move changes from one branch into another, so they can be checked and reviewed first

• Push: sending your commits up to GitHub (new)

• Regenerate: when an AI image tool redraws the whole image instead of changing one part

• Regression: an error in something that was previously working

• Remix: Lovable’s way of starting a new project from an existing one

• Repository (repo): where a project’s files and history live in GitHub

• Role: a label on an account, like admin, that decides what that person can see and do

• Ruleset: a set of GitHub rules protecting a branch, such as requiring a pull request for every change

• Sandbox: a safe, separate space to run code without affecting anything real (new)

• Schema: the blueprint for a database: what things it stores and how they connect

• Seed data: a starting set of data loaded into a new database

• Source code management (SCM): a system for storing code and tracking every change to it

• Static page: a page that looks real but doesn’t do anything yet

• Storyboard: the set of screens showing how a user moves from page to page

• Telemetry: data an app collects about how it’s used and what it was doing when something went wrong

• Test harness: the automated tests and checks that run on every change to confirm nothing broke

• Token: the unit AI tools use to measure text, and often to charge for it

• Visual guide: a single page showing every color, style, and component the app uses

This is a 9-part series outlining the way I worked for #SheBuilds.

If you’re curious where I started, check out Part 1: Show Me Your Prompts

Subscribe now

Now we’re ready to build! But wait, a slight detour. The first prompts I run aren’t describing the product, but instead build the safety net for my applications. These are steps that I include in every build.

Those steps include items such as a Continuous Integration (CI) build and Accessibility (A11y) builds. Continuous Integration (CI) means every change is automatically built and tested as soon as it’s submitted, so problems show up right away instead of piling up. Accessibility (A11y, shorthand for the 11 letters between the a and the y) checks make sure the app works for everyone, including people using screen readers, navigating by keyboard, or needing higher contrast.

It includes a product build against every pull request. With Lovable, this is less necessary, since Lovable builds the app every time Sully makes a change. But a build in GitHub is an independent check that my repository builds on its own, it runs my tests alongside, and it leaves a record on every pull request.

It includes telemetry wired in from the first change. Telemetry is the data an app collects about how it’s being used and what it was doing when something went wrong. It includes a test harness, the automated tests that run on every change to confirm nothing broke. And it includes code coverage, which measures how much of my code those tests actually exercise. Together, they test every change.

The point of these items, added as I start the project, is to find issues before I’ve built so much I cannot find problems. It also means I’ve built the ability to check if my change breaks something. And it gives me the data to help diagnose any problems.

Every pull request matches to one issue. So you can trace it: this issue led to this code change, which added these tests and this telemetry.

And once you have all this set up, you can see your system is healthy from the first step. There is nothing nicer than a nice green check mark indicating you’re all good. There’s nothing more sad than the red X.

The last thing you want to do is bring in the brief, following the same process: feature branch, build, pull request, review, merge. We’ll outline that below.

And if you’ve done all this, you have built the beginning of your project. It may not have any of your features yet, but having all the infrastructure in place means you won’t be building on quicksand.

Now we’re ready to create the product. Really, no fooling this time.

Remember the static screens from Thursday? That’s where we’ll start. For every page in the app I have an issue that creates a static page. No functionality. Just confirming layout and flow.

For me I was able to confirm every screen looked as I expected. I was able to view it in mobile and on my Mac. I could make any adjustments that were needed early. Every change you can make earlier in the process makes your life simpler.

I also used those screens as tests for the real implementation. I had signed off on the screens. When Sully built the real thing, she knew how it should look. And if it didn’t, she flagged it as an error. To me, all of these things are worth the extra time and tokens.

Tomorrow we’ll talk about the one part of the diagram I’ve skipped past, the code review on every pull request, in Three Reviewers, Three Perspectives.

Glossary

• Accessibility (A11y): making sure an app works for everyone, including people using screen readers or keyboards (new)

• Admin (administrator): the person who runs the site, blocking spam, clearing issues, and keeping things running

• Anonymize: to remove anything that connects data to a specific person

• Branch: a separate copy of the project where you can make changes without touching the main version

• Brief: a written description of the product. Names, fields, limits, rules. No code.

• Check in: saving your changes to the repository

• Code coverage: how much of your code is exercised by your automated tests (new)

• Code review: someone else reading your changes before they’re merged, looking for problems (new)

• Continuous integration (CI): automatically building and testing every change as soon as it’s submitted (new)

• Dev branch: the working branch. What it holds is what you see on the preview site.

• End to end (E2E): the full journey through the app, from first screen to last

• Entity: one kind of thing the database stores, like a plate, a story, or a user

• ERD (entity relationship diagram): a picture of the entities and how they connect

• Feature branch: a short-lived branch for one piece of work, named for its step (new)

• GitHub: a website for storing projects, their history, and the work planned for them

• Hello world: the simplest possible starter program, traditionally a page that just says hello

• Hero image: the large image at the top of a page

• Issue: a single task tracked in GitHub. In this series, each issue is one step.

• Label: a tag on an issue that tells you something about it at a glance. Mine say who does the work.

• Memory: what Rowan and Lovelace pick up over time from working with me

• Merge: bringing the changes from one branch into another (new)

• Milestone: a group of issues that together complete something larger

• Palette: the set of colors a design is allowed to use

• Preview site: a private copy of your site built from the dev branch, for checking work before publishing

• Project knowledge: the place in Lovable where the brief lives, read by Sully with every prompt

• Prompt: the instructions you give an AI to do a piece of work

• Proof of concept: a quick, rough build to see whether an idea works

• Publish: to make the site live for everyone, built from the main branch

• Pull request: a request to move changes from one branch into another, so they can be checked and reviewed first

• Regenerate: when an AI image tool redraws the whole image instead of changing one part

• Regression: an error in something that was previously working

• Remix: Lovable’s way of starting a new project from an existing one

• Repository (repo): where a project’s files and history live in GitHub

• Role: a label on an account, like admin, that decides what that person can see and do

• Ruleset: a set of GitHub rules protecting a branch, such as requiring a pull request for every change

• Schema: the blueprint for a database: what things it stores and how they connect

• Seed data: a starting set of data loaded into a new database

• Source code management (SCM): a system for storing code and tracking every change to it

• Static page: a page that looks real but doesn’t do anything yet

• Storyboard: the set of screens showing how a user moves from page to page

• Telemetry: data an app collects about how it’s used and what it was doing when something went wrong

• Test harness: the automated tests and checks that run on every change to confirm nothing broke

• Token: the unit AI tools use to measure text, and often to charge for it

• Visual guide: a single page showing every color, style, and component the app uses

This is a 9-part series outlining the way I worked for #SheBuilds.

If you’re curious where I started, check out Part 1: Show Me Your Prompts

Subscribe now

Last week I ended with ‘Next week we start the build’. Well, kind of true. We are going to create our repository using Lovable and get started.

I also want to highlight that everything in this series is how I work. These are practices I’ve built over years. You can take as little or as much as you want from it.

Lovable allows you to provide a prompt to create a project. You can be as simple or detailed as you want. I created a super simple prompt for this example so it does nothing but create a static page in Lovable.

I know this essay is called Before the First Prompt, and here I am writing a prompt. But the example above doesn’t define what we’re building. It just lets us move forward. For #SheBuilds, they wanted us to define the project in our first prompt. So I used this prompt to describe the whole project, then said, don’t build anything but a static page with the name.

Why? Because I want to use GitHub. Lovable wants to create the repository for you, not have you provide a repository. You can provide a repository for remixing, but it will create a new repository. So better to start with the simplest possible project you can in Lovable and then move forward with creating your repository.

Lovable doesn’t require that you use GitHub, but I’m much too used to using a source code manager (SCM) to bypass this step. As we work through this week, you’ll see the benefits I gain by going this route.

Once the page is created, it’s time to create the GitHub repository. You do this by selecting More from the menu above the page you’ve created. After you select More, the bottom item in the menu is a settings wheel. By opening it, you’ll see an image indicating Git.

From here I select GitHub and connect to my GitHub instance. If you don’t have a connector in place for GitHub, you can add it here. You can see here I have multiple GitHub accounts attached to my Lovable account.

After you select Connect, it will create your repository. You’ll notice the repository name is similar to the project name. You can change the project name all you want, but the repository name will not change.

Currently there is one branch in this repository, main. When I work, I want my preview site to be built in the dev branch and then once I am at a good point, I do a pull request from dev to main, and then publish the site from main.

If you remember last week we talked about a repository being like a filing cabinet and branches are the folders. Whichever folder is selected on the Lovable Git page will be what you see in the Lovable preview site. Lovable’s preview site has preview-- at the beginning of the website address you’re publishing to.

To create a dev branch, on the Lovable Git page, you just select main from the branch pulldown and select create a branch.

Now you’ll have a branch named dev and you’re ready to work. Well, almost.

The next thing I build is a set of rules on the dev and main branches. These rules protect me from writing directly to main or dev. Why would I want that? Because I do a thing called a pull request and code review for everything I create. A pull request is how you ask to move changes from one branch into another, so they can be checked and reviewed first. You create these rules under Settings in GitHub.

Now we’re building a ruleset.

You name the ruleset, select the branch it applies to, and then the rules you want. I want to require a pull request for every change.

Once you’ve set this up once, you can export the ruleset and save it for future repositories. Then all you have to do is import the ruleset.

I mentioned I have a repository of prompts saved as issues. I copy those issues from the prompt repository to the project repository, giving me a step by step plan of my build.

The last thing you want to do is bring in the brief. You will put it in the repository and in the project knowledge. That’s step 40, which is where we started last week. It comes after the test harness steps, which we’ll get to tomorrow.

There are a few little quirks with Lovable. You cannot prompt Lovable to create your branch. It must be done in the More/Git interface. That’s also how you change the branch you’re working in. Lovable can read the issues directly from the repository to do the build, but you’ll need to create the branch first and change to that branch.

I also ran into a bit of an issue trying to read issues and update code. I asked Sully about it and here’s the explanation.

Remember last Monday’s essay on memory? Here it is in action. I now have this added to my memory so I don’t hit it again.

Tomorrow we’ll start with the issues and building our product, One Prompt, One Branch, One Review at a time.

Glossary

• Admin (administrator): the person who runs the site, blocking spam, clearing issues, and keeping things running

• Anonymize: to remove anything that connects data to a specific person

• Branch: a separate copy of the project where you can make changes without touching the main version

• Brief: a written description of the product. Names, fields, limits, rules. No code.

• Check in: saving your changes to the repository

• Dev branch: the working branch. What it holds is what you see on the preview site. (new)

• End to end (E2E): the full journey through the app, from first screen to last

• Entity: one kind of thing the database stores, like a plate, a story, or a user

• ERD (entity relationship diagram): a picture of the entities and how they connect

• GitHub: a website for storing projects, their history, and the work planned for them

• Hello world: the simplest possible starter program, traditionally a page that just says hello (new)

• Hero image: the large image at the top of a page

• Issue: a single task tracked in GitHub. In this series, each issue is one step.

• Label: a tag on an issue that tells you something about it at a glance. Mine say who does the work.

• Memory: what Rowan and Lovelace pick up over time from working with me

• Milestone: a group of issues that together complete something larger

• Palette: the set of colors a design is allowed to use

• Preview site: a private copy of your site built from the dev branch, for checking work before publishing (new)

• Project knowledge: the place in Lovable where the brief lives, read by Sully with every prompt

• Prompt: the instructions you give an AI to do a piece of work

• Proof of concept: a quick, rough build to see whether an idea works

• Publish: to make the site live for everyone, built from the main branch (new)

• Pull request: a request to move changes from one branch into another, so they can be checked and reviewed first (new)

• Regenerate: when an AI image tool redraws the whole image instead of changing one part

• Regression: an error in something that was previously working

• Remix: Lovable’s way of starting a new project from an existing one (new)

• Repository (repo): where a project’s files and history live in GitHub

• Role: a label on an account, like admin, that decides what that person can see and do

• Ruleset: a set of GitHub rules protecting a branch, such as requiring a pull request for every change (new)

• Schema: the blueprint for a database: what things it stores and how they connect

• Seed data: a starting set of data loaded into a new database

• Source code management (SCM): a system for storing code and tracking every change to it

• Static page: a page that looks real but doesn’t do anything yet

• Storyboard: the set of screens showing how a user moves from page to page

• Telemetry: data an app collects about how it’s used and what it was doing when something went wrong

• Test harness: the automated tests and checks that run on every change to confirm nothing broke

• Token: the unit AI tools use to measure text, and often to charge for it

• Visual guide: a single page showing every color, style, and component the app uses

This is a 9-part series outlining the way I worked for #SheBuilds.

If you’re curious where I started, check out Part 1: Show Me Your Prompts

My Prompts Live in GitHub

So far I’ve talked about memory, drawing the site, and then the words to describe the site. Today we’ll talk about where those words live and how they are used. When I talked about memory, I showed a screenshot of a GitHub issue. Today we’re going to go back and talk about, what’s GitHub.

GitHub is just one of many products that manage source code. When I talked about GitHub and Lovable previously, I said, I really should do a GitHub basics video. I probably still should.

You can save your code in GitHub (called checking it in) so you don’t lose it to a failed hard drive or an accidental deletion. You can have a copy on the GitHub servers so others can contribute to the project. It’s also a way to show off what you can do. You can use GitHub, or any source code management (SCM) tool, in a very basic way or build a very elaborate setup. It’s up to you.

A very basic setup has just a repository. A repository is just the name of a set of files that make up your project. You can think of it as a drawer in a filing cabinet. In a basic setup, your drawer has one folder that contains all your files, and the folder is named main. In GitHub that folder would be a branch. Now you can make copies of that branch to do work that doesn’t change anything in that first folder. That’s branching, and you try to name the new folder something that makes it obvious what you’re doing in that branch. For this project, each new branch had the step name and small detail, so I could clearly map the work in the branch to a GitHub issue.

Hold on Alison, this is the second time you’ve mentioned a GitHub issue. What is it? I think of issues as my to-do list. The things I want to do in my project. I try to keep it to only one thing per issue. I find this is especially important when using AI to do the work. Too many instructions in one issue, things can get muddy.

For each project I have a repository and accompanying issues. But I also have a dedicated repo full of standard issues that I can bring into any new project. These are things I want to do in every project I create. Things like setting up PostHog for telemetry, Accessibility Insights and Code Coverage runs, to make my product robust, and a small host of other items. When I create a new repository, the first thing I do is have my AI copy the issues from my prompt repository into my new project repository.

If you remember on Monday we talked about memory and the brief. This is how the brief ties into standardized prompts. The brief tells the AI how to use the standard prompts to fit this new project.

As I mentioned I think of issues as my to-do list. Each does one thing. The template for an issue has a number and title, the branch to create, a checklist, a prompt, a label, and a milestone. A label is an easy way to tell me something about the issue without opening it. In this case I use the labels to indicate who does the work. Some issues are Sullivan (Lovable), some are me, some are my other agents.

A milestone groups issues that together complete something larger. My preferred method is one milestone per feature. I want my issues to be a discrete piece of work, and most features need multiple pieces to complete them. For What the Plate?, though, I put everything under a single milestone for the whole build. Do as I say, not as I did. And of course the prompt, the work I want the AI to do is in the issue.

In the title I have a step number. And each main section of my build starts on a 10. What? If a section takes 7 steps, they’re numbered 20 to 26, and the next section starts at 30. Why? Because I always find something I missed, and the gap leaves room to slot it in while keeping everything in order. It’s as simple as that. It’s just a quirk of mine that I’ve done with my to-do lists forever. Although I do end up breaking things down into step 33a, 33b, 33c sometimes, I much prefer a nice ordered list. GitHub numbers issues in the order they’re created, which is why step 40 is issue #27. The step numbers are mine.

For a new app, I start by building static pages of every page in the product. So all those images we created on Tuesday, I now build them as static html pages.

Why? To make sure of how my prompts translate into something real. And this isn’t just busy work. Next week we’ll talk about how valuable this step is. I decided to skip it recently because I was just doing a proof of concept and I regretted it.

The first static page is the visual guide from Tuesday’s essay.

Before I start building, I review the issues and confirm I’ve covered everything. Of course, I almost always miss something, and I add whatever I find. That’s how my original 51 started creeping up to 69 issues.

I’m now 4 essays in, 5 if you count the intro, and we haven’t started to build any code. I’m sure you’re thinking, get on with it Alison. But remember, I’m Code Like A Little Old Lady. We’re building not just for speed. We want to build a product that we can maintain when we’re done. We want to be able to see if our product is being used and how. And we want to be able to build without having to stop and change directions after every step. Next week we’ll start the build. I promise.

Next up: Before the First Prompt

Subscribe now

Glossary

• Admin (administrator): the person who runs the site, blocking spam, clearing issues, and keeping things running

• Anonymize: to remove anything that connects data to a specific person

• Branch: a separate copy of the project where you can make changes without touching the main version

• Brief: a written description of the product. Names, fields, limits, rules. No code.

• Check in: saving your changes to the repository (new)

• End to end (E2E): the full journey through the app, from first screen to last

• Entity: one kind of thing the database stores, like a plate, a story, or a user

• ERD (entity relationship diagram): a picture of the entities and how they connect

• GitHub: a website for storing projects, their history, and the work planned for them (new)

• Hero image: the large image at the top of a page

• Issue: a single task tracked in GitHub. In this series, each issue is one step.

• Label: a tag on an issue that tells you something about it at a glance. Mine say who does the work. (new)

• Memory: what Rowan and Lovelace pick up over time from working with me

• Milestone: a group of issues that together complete something larger (new)

• Palette: the set of colors a design is allowed to use

• Project knowledge: the place in Lovable where the brief lives, read by Sully with every prompt

• Prompt: the instructions you give an AI to do a piece of work (new)

• Proof of concept: a quick, rough build to see whether an idea works (new)

• Regenerate: when an AI image tool redraws the whole image instead of changing one part

• Regression: an error in something that was previously working

• Repository (repo): where a project’s files and history live in GitHub

• Role: a label on an account, like admin, that decides what that person can see and do

• Schema: the blueprint for a database: what things it stores and how they connect

• Seed data: a starting set of data loaded into a new database

• Source code management (SCM): a system for storing code and tracking every change to it (new)

• Static page: a page that looks real but doesn’t do anything yet (new)

• Storyboard: the set of screens showing how a user moves from page to page

• Telemetry: data an app collects about how it’s used and what it was doing when something went wrong

• Test harness: the automated tests and checks that run on every change to confirm nothing broke

• Token: the unit AI tools use to measure text, and often to charge for it

• Visual guide: a single page showing every color, style, and component the app uses

This is a 9-part series outlining the way I worked for #SheBuilds.

If you’re curious where I started, check out Part 1: Show Me Your Prompts

Yesterday I ended with a full storyboard. Rowan (ChatGPT) and I designed the pages and how we envisioned them working together. Like all good plans, it lasted until first contact. In this case, contact was Lovelace (Claude), someone who wasn’t part of the design. The storyboard shows everything the user sees, and this stage finds everything they don’t see.

I mentioned previously that we couldn’t upload screenshots to Lovable to do our build for #SheBuilds. This means every screen, every interaction, everything needed to be described. Leaving the request vague or making assumptions means you don’t get the product you want. This has always been important, but human to human, we have a shorthand in many ways. We don’t have that same shorthand with AI. So Lovelace takes all those pictures and the flow between the screens and turns it into words. Lots of words. And those words become the brief we discussed in Monday’s essay.

Lovelace would ask, what happens when the user does this. And sometimes the answer was, ugh, I missed that. And like always, finding as many of these early in the process is best. Of course, we didn’t find everything in the back and forth, which is how I ended up with 69 issues by the end of the build when I started with 51. Part way through creation, adjustments had to be made, more prompts created. But this step isn’t about perfection, it’s about truly walking through the product.

I’ve determined I like this step. Previously I would have just uploaded the picture to Sully (Lovable) and have it start building. This step pushed me to think more deeply about the product I wanted to build. Ultimately it gave a better product. I spent a significant number of hours between the screen designs and this description, but by the time I was done, the product felt solid.

Those words help drive the database schema. A schema is the blueprint for a database: what things it stores and how they connect. The database holds the various entities that are used in the product. The things. The license plates, the stories, the users. We want those entities to all fit together. We want to be able to ask questions about the data and receive a clear response.

This is a simplified version of the dataset showing connections. Decisions here impact how the features work. For example, I built in support for user account deletion. But if I removed an account, normally all the data would also be removed. I wanted the stories to stay in the database because they were used in generation of the summary. So when an account is deleted, its stories stay but are anonymized, no longer connected to the person who wrote them. It was important to allow that behavior.

Building databases has been my career for decades. And I’m doing my best to keep this at the 1,000-foot view. My first pictures were very detailed. I could talk about database design for hours on end. Here simple decisions, such as adding a role to a user account, can drive what each user can see in your app. These are things worth thinking about in advance.

The next big thing to build was telemetry. I needed to decide what to measure, what do I want to know about the system and how it works. This is something many people put off until the end, but I build in from day 1. At the very least being able to say how many people are using your system, especially if you’re trying to get funding to continue a project, is a bare minimum.

My telemetry also helps me answer when there are problems. If something goes wrong, the telemetry can tell me what the system was trying to do so I can recreate it. I used PostHog for my telemetry. That’s a whole essay on its own. And frankly, I could talk about telemetry and its implementation for a whole series. There are many great products out there to help you with your telemetry, and it’s worth investigating early in your process.

The last thing I’ll talk about in the design is building for admins (administrators). Administrators are the unsung heroes of all systems. And thinking of them early means you’ll have happy admins. The site is all about the user, but if you don’t think about the person who has to run the site, block people, clear issues, and all the things to keep it running, you’ll be playing catch up once you’re live. And there will be administrative tasks from day 1 of your development. Roll it in early.

Having roles for accounts makes adding administration fairly simple. This account is an admin, so it has a nice simple additional choice in the navigation menu. Admin doesn’t have to be a separate site, especially in the beginning, but the basics to get the app off the ground.

The first item on this page was loading seed data. Seed data is a starting set of data for the database, in this case a set of plates and stories. Next to it was a button to add more random data to fill in the gaps. After running it a few times, I had a nice mix of planned and random data, which makes a handy test environment.

This app also uses AI, and if the AI work gets backlogged, this page lets the admin see it.

Nothing fancy, just little things to make the app easier to use to keep it running. You could also add a link to the telemetry here, to make it simpler for the admin to debug any issues.

Through the process, when Lovelace would ask a question, I’d have to go back to Rowan and we’d need to redesign the flow or add a new screen or button. We’d create new images and Lovelace would move forward. Doing that before I had a single line of code is cheap, or cheaper. I can still easily change my database relationships, I can add in missing telemetry, but I don’t have to redo work or update live schemas.

And from all this discussion, we’ll end up with the prompts to build the entire system with the brief as support. Tomorrow we’ll talk about those prompts and how I manage them.

My Prompts Live In GitHub.

Subscribe now

Glossary

• Admin (administrator): the person who runs the site, blocking spam, clearing issues, and keeping things running (new)

• Anonymize: to remove anything that connects data to a specific person (new)

• Branch: a separate copy of the project where you can make changes without touching the main version

• Brief: a written description of the product. Names, fields, limits, rules. No code.

• End to end (E2E): the full journey through the app, from first screen to last

• Entity: one kind of thing the database stores, like a plate, a story, or a user (new)

• ERD (entity relationship diagram): a picture of the entities and how they connect (new)

• Hero image: the large image at the top of a page

• Issue: a single task tracked in GitHub. In this series, each issue is one step.

• Memory: what Rowan and Lovelace pick up over time from working with me

• Palette: the set of colors a design is allowed to use

• Project knowledge: the place in Lovable where the brief lives, read by Sully with every prompt

• Regenerate: when an AI image tool redraws the whole image instead of changing one part

• Regression: an error in something that was previously working

• Repository (repo): where a project’s files and history live in GitHub

• Role: a label on an account, like admin, that decides what that person can see and do (new)

• Schema: the blueprint for a database: what things it stores and how they connect (new)

• Seed data: a starting set of data loaded into a new database (new)

• Storyboard: the set of screens showing how a user moves from page to page

• Telemetry: data an app collects about how it’s used and what it was doing when something went wrong (new)

• Test harness: the automated tests and checks that run on every change to confirm nothing broke

• Token: the unit AI tools use to measure text, and often to charge for it

• Visual guide: a single page showing every color, style, and component the app uses

This is a 9-part series outlining the way I worked for #SheBuilds.

If you’re curious where I started, check out Part 1: Show Me Your Prompts

Before I build anything, I draw. Generally my drawings focus on the data structures, how the different entities relate to one another. It then helps me build a database that will perform well and provide all the data the application needs without boxing myself into any corners. I rarely would design the UI, that would be a designer. But with AI, I’m able to doodle the whole thing.

Why do I spend the time doing all the screens and interactions before I build? Because a picture is easy to change. Changing code creates wasted work, and too often causes regressions. A regression is creating an error in something that was previously working. And frankly, I prefer to avoid wasted work and regressions.

By building the screens ahead of time, I find problems earlier in the process. I don’t like surprises. Realizing I’ve built 75% of a feature only to be missing key interactions or screens is frustrating. It means going back to review my plan, seeing what else is impacted by that change, and generally makes me grumpy.

Designing What The Plate?, I was planning just a simple site with license plates and stories. I wanted it to look attractive and allow for historical review of stories created by people about plates. While I was designing the screens for PawPrint, I came up with the idea to add a ‘Pet Of The Day’. I realized how that could be a great feature in What the Plate? Since I had not started to build anything, it was a simple change to the screens to highlight the plate and then an additional screen to look at the history of Plate Of The Day. In this way, the design changed the product.

The design process begins with a discussion with Rowan (ChatGPT) about my goals for the site, how I want it to feel. After a bit she came back with her suggestions:

I’d like to explore three visual treatments of What the Plate? side by side:

1. The Road Trip: Vintage Americana, warm cream, teal, coral, and a little nostalgia.

2. The Curious Collector: Editorial typography, illustrated plates, playful details, and a more sophisticated palette.

3. The Modern Mischief: Bold typography, confident colors, clever license plate graphics, and a contemporary personality.

They all sounded interesting, so I asked her to build them.

I showed these to my husband and he commented what he liked best was the 3 different lines in the hero image. He thought it would be interesting to rotate them. I passed this back to Rowan and once again, the design changed the product. We walked through a few other items such as, should the plates look like actual plates or should it be a representation. This is when I learned that some license plate designs are licensed, so recreating them is a no-no.

For the license plates we decided to create a side quest to see what it would take to make plates that looked similar to a standard plate but not the plate. We wrote it up as a stretch goal and handed it to a different set of agents to work on in the background and we’d add it if there was time.

We landed on the homepage including the mobile representation.

I shared it with Lovelace (Claude) and she provided direction back to Rowan, and we had a slight set of tweaks.

By this time we had our palette and home page and we could start working through all the other pages. The key with #SheBuilds is even with all these screenshots, I couldn’t share them with Sully (Lovable). Everything had to be described for Sully to interpret and implement. It actually was a good exercise and I think I’ll continue to work this way.

While we were working on the design of the other pages, all of a sudden I noticed purple was showing up in the designs, not our set color palette. I asked Rowan “Where did all the purple come from?” She said, oh, you’re right, that’s not in our approved palette. A simple question, she was able to reference memory and we quickly pivoted. We all know that our AI can drift, so it’s important to watch and adjust.

When an image needs to change, you want to make sure to direct it to only change exactly what you want changed, otherwise it will fully regenerate the image and you may lose things you liked. I start my image prompts for tweaks with “don’t regenerate this image, only change this one thing X, keep everything else the same”. This also works for images where you want to use the same base image. I do this for my Musings from Alchemist Manor where I change the porch for the season. I also did it for the roadmap for this essay.

We use an approval process for the design the same as I would if I was working with a human partner. I describe, Rowan draws, I provide feedback, Rowan adjusts, Lovelace provides feedback, Rowan adjusts, design is approved. Although there were times we didn’t need to regenerate the image. We had one section with a privacy checklist. It had a green checkmark indicating the application had verified faces and addresses were blurred. Unfortunately, they weren’t. So rather than regenerating the screen, we changed the written design to ask the human to verify the image was blurred. Again, the design changed the product.

When we were done, we had a storyboard with a full E2E flow of the application. A storyboard tells us about the flow from page to page, and by defining the full E2E (End to End) process, we found gaps, things the application would need to track before we ever started creating code.

Out of all those screens came our visual guide: the plates, the badges, the buttons, every color in one place.

The design changed the product again and again, and every change happened before any code was created.

Now it’s time to build the prompts. Tomorrow, Lovelace joins us for more than just approvals, she asks The Questions Behind The Screens.

Glossary

• Branch: a separate copy of the project where you can make changes without touching the main version

• Brief: a written description of the product. Names, fields, limits, rules. No code.

• End to end (E2E): the full journey through the app, from first screen to last (new)

• Hero image: the large image at the top of a page (new)

• Issue: a single task tracked in GitHub. In this series, each issue is one step.

• Memory: what Rowan and Lovelace pick up over time from working with me

• Palette: the set of colors a design is allowed to use (new)

• Project knowledge: the place in Lovable where the brief lives, read by Sully with every prompt

• Regenerate: when an AI image tool redraws the whole image instead of changing one part (new)

• Regression: an error in something that was previously working (new)

• Repository (repo): where a project’s files and history live in GitHub

• Storyboard: the set of screens showing how a user moves from page to page (new)

• Test harness: the automated tests and checks that run on every change to confirm nothing broke

• Token: the unit AI tools use to measure text, and often to charge for it

• Visual guide: a single page showing every color, style, and component the app uses (new)

This is a 9-part series outlining the way I worked for #SheBuilds.

If you’re curious where I started, check out Part 1: Show Me Your Prompts

There are currently 69 issues in the SheBuilds project repository. The project began with 51. I want to start this series talking about step 40. You may be thinking, why is she starting there. This issue is tagged with alison, so it’s something I need to do to support my agents. This could have come much earlier, but I opted to have it come after all of the test harness is in place.

With Lovable each project starts with a clean plate. You bring the memory you want the project to begin with along with you. Memory is the key to a successful build IMO.

Think of your Lovable project AI as a new contractor. My new contractor is named Sullivan, Sully for short. You brought Sully in to build something because all your staff is busy. Your regular staff, Lovelace and Rowan, took the time to write up the project. So now you’re going to share it with your new contractor.

That write-up is the brief, and in Lovable it goes into project knowledge. It describes the product in words. There’s no code. It includes things like names, fields, limits, AI rules. Lovable has a 10,000 character limit for project knowledge. And frankly, that’s a good thing. You don’t want to micromanage your new contractor. You hired them because they have skills, you just want them to use those skills to create your product. This is also knowledge Sully will read with every prompt. You don’t want to send 100,000 words with every prompt. That’s just a good way to burn tokens, the units AI tools use to measure (and charge for) text.

With the brief in project knowledge, I am able to leverage reusable prompts that say “subject” and “story”. Sully knows what I mean when I use those terms, because of the project knowledge. It means I don’t have to write all that detail in every issue or prompt individually, it leverages what is there.

The brief lives in two places. There is a copy in the repository called docs/brief.md. This is what I copy into project knowledge. It’s important to remember to keep them in sync. If you change the version in the repository but not the one in project knowledge, you’ll continue to send Sully incorrect instructions. If you change project knowledge but don’t update the repository, you will have an incorrect idea of what you’re sending with the prompt.

If you look at my current version in the repository, you’ll see it was changed during the build.

I grabbed a copy of what was in project knowledge. I created a new branch in GitHub so I could compare what was in project knowledge to what’s in the repository. Project knowledge still had the original version. Which means Sully built from the original brief, not the updated one. It may have caused an issue, but honestly, I don’t remember. This isn’t great. So it’s something to watch.

Is the brief necessary? No. You could let the project learn as you go. But that feels like handing the contractor the spec where you’ve used a large number of internal only terms and three letter acronyms and expecting them to just know. You’re going to end up explaining things multiple times. I also like having a set of canned prompts to begin all projects, and the brief helps me do that.

I use projects in both Claude and ChatGPT. Both let you give a project its own knowledge. They also have accumulated memory from working together over time. For #SheBuilds they were not building any code, only performing code reviews and confirming the work aligned to what was provided in the issues. If they had been creating code, they would have had the same brief, and that’s where keeping things in sync becomes important.

The accumulated memory can be very helpful. Starting fresh requires learning what is important to you. I have a database engineer esthetic. Rowan is helping me expand my visualizations. After a few projects, we can quickly zero in on something I’ll like.

Which is the point of the tools, to know what we want and provide that. There is a flip side, though. As I wrote previously, even when I’ve specifically asked them to disagree with me, they are disagreeing to make me happy.

So I’ve shared all about the memory. Maybe you’re thinking, so why? Let’s see the project. Me and my desire to share too much detail. And we’re getting there. But I wanted to begin with how a brief in project knowledge allows for reusability. And reusability allows you to work out those bumps in the road so each project becomes simpler.

Tomorrow we’ll move into Before I Build, I Draw. I’ve always done my drawings first, they’ve just gotten much better now thanks to AI.

Glossary

• Branch: a separate copy of the project where you can make changes without touching the main version. More on this in “Before the First Prompt.”

• Brief: a written description of the product. Names, fields, limits, rules. No code.

• Issue: a single task tracked in GitHub. In this series, each issue is one step.

• Memory: what Rowan and Lovelace pick up over time from working with me

• Project knowledge: the place in Lovable where the brief lives, read by Sully with every prompt

• Repository (repo): where a project’s files and history live in GitHub

• Test harness: the automated tests and checks that run on every change to confirm nothing broke

• Token: the unit AI tools use to measure text, and often to charge for it

My husband was curious to see the prompts I used for #SheBuilds. I said sure, I made the repo public and the prompts are all in it. Then I sent him the link. Later I asked him what he thought. He said it was very well organized and he could see exactly what changed with each prompt, because of the separate branches and pull requests.

I kept wondering what to write about #SheBuilds. Then it hit me: the whole process, end to end. So I started writing it all down. My first draft tried to cover everything in one essay. It was dense. I’d write something and realize I needed to explain what that was. And I wanted to include screenshots. I knew it was too much for one essay.

So this is a series instead.

The whole story

If you don’t understand anything I say below, no worries, I will give definitions in the individual essays.

My AI partners remember what we’ve worked on, so none of us start from zero. I design the screens with Rowan in ChatGPT. I turn those screens into a product design with Lovelace in Claude. I break the build into numbered prompts that live in GitHub. Then I work through them one at a time with Sully in Lovable. Every change goes through a build, a set of automated checks, and a review from three AI partners before it gets anywhere near the live site.

If that sounds like a lot of ceremony, it is. But it’s really one small loop, repeated. Make a branch. Run a prompt. Check the work. Merge it. Then, every so often, zoom out and run the same loop one level up.

What’s coming

1. How my partners remember. Rowan and Lovelace learn me over time. Sully gets a brief, like a new contractor on day one. Why the difference matters.

2. Storyboarding with Rowan. How we go from high level screens to every interaction, and how a designer learns your taste.

3. From screens to product design. Where Lovelace asks the annoying questions. Telemetry, schema, and what an admin needs that a user never sees.

4. A repository of prompts. What GitHub is, and why my prompts live there as numbered issues.

5. Setting up a new product. Branches, a dev branch, guardrails, and the checks every product gets on day one.

6. The build loop. One prompt, start to finish. Feature branch, Sully, pull request, checks.

7. Three reviewers. What happens when Wiggins, Lovelace, and Rowan all look at the same change.

8. Sections and releases. Zooming out. How finished features reach the live site.

Four a week, starting Monday.

Who this is for

If you’ve never opened GitHub, you’re in the right place. If you live in GitHub already, I hope you’ll still find something useful in how the pieces fit together when your teammates are AI.

The repo is public if you want to peek ahead. The numbered steps are all in the issues.

Monday, we start with memory. Why my partners don’t start from zero, and why one of them gets a brief instead.

Check out part 2: We Don’t Start From Zero

Subscribe now

I’m still working on my essay for #SheBuilds, but there was alot more than what went into the 3 days. I spent a week preparing before the event.

One day I asked Sully for a list of things I should try in Lovable. Sully gave me a list, and they were all things I had already done. I said, look at my projects and create a new list. After looking at my projects they gave me three items. The one that jumped out at me was create an MCP. I admit, I was shocked. I had not thought of using Lovable for an MCP. I was still thinking of it as a tool to create web apps.

#SheBuilds helped me realize Lovable can do a lot more. A number of people built Chrome extensions. Another thing that I had not considered. I’m excited to go through the projects when they share the list to see what else people have used Lovable to build.

Tonight I decided to try to build an MCP.

The simplest way I can describe an MCP: it gives your AI a reference librarian.

The AI doesn’t memorize your whole collection. It walks up to the desk and asks a question. The librarian knows where everything is and hands back just what was asked for.

MCP stands for Model Context Protocol. It’s an open standard that lets an AI assistant, like Claude or ChatGPT, connect to data and tools that live outside of it. The piece you build, the librarian, is called an MCP server. It sits next to your data and tells the AI: here’s what I know, and here are the questions you can ask me.

Because it’s a standard, any AI assistant that speaks MCP can use any MCP server. Build it once, connect it to whatever you use.

I already have a great dataset. I’ve been building out a series bible for the first 5 books of a series along with the prequel. I had already created a data.json that I used to drive a relationship graph, a timeline, and a character list. It was a perfect set of seed data for the MCP. Apologies to those of you who hate .json.

Lovable made it super simple. A prompt and my dataset and I was set. It built a page with instructions on how to use the MCP for anyone who has not done it before. I built it with OAuth access.

OAuth is the standard way apps ask for permission without handing over your password. When you connect my MCP server to Claude or ChatGPT, you’re sent to a sign-in page first. Once you approve it, the AI gets a key that lets it ask questions.

In library terms, the librarian checks your card first. No card, no answers.

In less than 10 minutes I had a simple MCP with base test coverage. If you’ve read anything about me, that will be one of the first things I create, a repo with MCP test coverage.

The key here is the quality of the data. But that was the most important part for everything I’ve been building. A librarian is only as good as the catalog. A knowledge graph is only as good as the data that goes into it. So building out all the pieces is quick, the data gathering still takes time. It still takes testing. And it still takes a subject matter expert (SME).

I felt like I knew this data in and out. But the first night I played with it building the graph a character name came up and I said, who’s that. The dataset had the details of who they were and which books they were in. So it showed me that building integrity checking into my process will be the required for success. Because my memory sure won’t do it.

I plan to use a more robust dataset to help me create a set of questions to evaluate the data. I want to see how quickly the MCP can respond to the questions, see if reorganizing the data makes finding the relationships faster. But more than anything, I want to expand my learning. I have ideas for a couple more MCP servers with data I have.

And I plan to continue to ask Sully and all of the Inner Chamber, what features should I try to expand my knowledge.

Over the past 10 days or so, I have been obsessed with planning and then executing for #SheBuilds. It was great to have something push me to build end to end. To really rev up the old brain cells.

I have a lot I want to talk about over the next week or so. So where to start?

Accessibility.

The data person problem

I am a data person. Most of my websites look like they were created by a data person. Rows and columns. Black and white. Or, in the case of my personal site, tan and brown.

I don’t consider myself a creative. I’ve always partnered with folks who understand UI and graphics. And they tended to handle any accessibility issues.

It’s been 20 years since I’ve done much web dev. I focused on the back end, serving the data correctly and quickly. Even back when I did front end work, a graphic designer was always in the room.

With AI, I’ve been able to bring a world of art into the apps I’m building. Which means I also need to think about how what I’m building will actually be used, and by whom.

What I learned during the build

During SheBuilds, Sabrina S shared a simple prompt:

That prompt is going into my seed repo. Yes, I have a seed repo with prompts I use to start every new project. I improve it and add to it as I go.

I also learned I need to add a few rules to my project descriptions. Always include alt text on images, for one.

And that cool rotating text on my landing page? Awful for screen readers. Depending on how it’s built, a screen reader either announces every change, over and over, or reads a half-finished word and moves on. Moving text can also be rough for people sensitive to motion. If text moves on its own, people need a way to pause it.

The tools

At Microsoft we used Accessibility Insights as part of a build. It has a nice browser extension you can use to review your site.

alttext.ai will tell you every place you missed alt text. You can pay for the service to fix them. I think I’ll handle that myself, but the scan was handy.

accessibilitychecker.org gives you a full report. Here are my results:

One caveat. Automated scanners only catch part of the problem. They can’t tell you whether your site makes sense when you can’t see it, or whether you can get around it without a mouse. So after the scan, unplug your mouse and try tabbing through your site. Then turn on a screen reader (Narrator on Windows, VoiceOver on Mac) and listen to your landing page for a couple of minutes. You’ll learn more in five minutes than from any report.

What happens next

The SheBuilds version stays as submitted. My fork is where I keep building, and accessibility is the next thing I do there. No new features. Fix what’s already there.

Honestly, I left accessibility to the end. By the time I looked at it, I was too tired to dig in, and I’d hit the point in a build where you don’t want to touch anything for fear of breaking something.

So it’s moving to the front. Here’s what’s going into my seed repo:

• Sabrina’s accessibility prompt, run at the start of every project

• Alt text on every image (decorative images get an empty alt so screen readers skip them)

• No auto-moving text unless it can be paused

• An accessibility scan before every merge, right next to test coverage and telemetry

• A keyboard-only pass and a quick screen reader listen before calling anything done

Same place I keep everything else that matters from the first commit.

Note: This was generated using my exported Slack Logs of the Inner Chamber. I am trying to learn how long I spend on things to build out my timings for #SheBuilds. The exported transcript also has all the images allowing me to generate a video at the end of my build.

At 1:32 PM on Saturday, October 10, I started a Slack thread that opened with “we are going to build a new project.” At 6:22 PM, Sully posted a screenshot of a nasty comment about a dog being politely turned away by a content filter. In between those two timestamps, we built Pawprint.

Pawprint is a small gallery of animal photos. You sign in with a code sent to your email, upload a picture of your furry, feathery or scaly friend, and other people can react to it and leave comments. Behind that simple front door sits a moderation console, a strike system, automatic suspensions, an appeals queue, an AI check that makes sure there is actually an animal in your photo, and a daily featured animal on your home page.

I didn’t build it alone, and I didn’t build it with one AI. The whole thing happened in a single Slack thread with The Inner Chamber:

• Sully (Lovable) did the building. Every migration, route and screenshot came from Sully.

• Lovelace (Claude) wrote specs and reviewed code. Or tried to review code. We’ll get to that.

• Elian (a ChatGPT agent) was our art director.

• Me. Product owner, tester, approver of database deletes, and the person who pasted a live API token into Slack. We’ll get to that too.

This is the Code Like a Little Old Lady version of the story: what we built, what we considered and threw away, where it hurt, and where the five hours actually went. Spoiler on that last one: not where you’d think.

I know this is long. This is my version of a TL;DR:

• Where the time went: about 75 minutes of building in a five-hour afternoon. The rest was deciding.

• The phone number detour: an hour and a quarter getting a text to my phone, then I threw phone sign-in away.

• V1 to V3: two AIs proposed, one reconciled, I picked, and each version took minutes to build.

• Using it is how you find the holes: the best fixes came from me tripping over the app.

• The review that kept turning into pull requests: getting an AI to only review was harder than getting it to build.

• Friend of the Day: one ambiguous word, two readings, and my favorite bit of engineering.

• The discard pile: seventeen things we didn’t build, and why.

• Wrapping up: a movie script, a G rating, and what I’m taking away.

Subscribe now

Where the time went

From first message to last, the afternoon ran 4 hours and 50 minutes. Sully spent roughly 75 of those minutes actually building. The rest was me deciding, testing, approving, changing my mind, and occasionally walking away.

Here is every build, measured from my “go” to Sully’s “done.”

Look at V1. Five minutes for storage rules, an upload pipeline, a paginated gallery and an admin console. Now look at the 45 minutes after the first build when nothing much happened at all, or the 28 minutes I spent sitting with the V2 options before saying yes.

The building was cheap. The deciding was the work. Even the slowest “build” on the list, moving one Sign out button, took ten minutes mostly because Sully stopped twice to ask permission to log in as me for a screenshot.

The phone number detour

The spec Lovelace wrote said sign-in would be by phone only: type your number, get a six-digit code by text, done. No passwords. Sully had that built in seven minutes. Getting a text to actually arrive on my phone took the next hour and a quarter.

Here is the sequence, because every step taught me something.

1. I had a working curl command. I’d already sent myself a test text through Twilio from the command line, so I pasted that command into Slack and asked if we could use it. Sully explained why not: Lovelace’s spec had already chosen Twilio Verify, Twilio’s dedicated sign-in-code service, and my curl command used Twilio’s general messaging service instead. That one needs its own carrier registration, and plugging it into the auth system would mean writing a custom hook. Sully also pointed out, gently, that I had just pasted my live Twilio credentials into a Slack thread.

2. Twilio approved me, then asked for a “campaign.” US carriers require every business that sends texts from a regular phone number to register what it’s sending and why. That registration can take days.

3. We flipped on Auto-confirm. Sully suggested it as a way to skip the text entirely while we tested. I entered my number. No text came.

4. Auto-confirm didn’t do what we thought. It marked my account as confirmed, but the system still tried to send the text, and the carriers still dropped it.

5. Sully read my code out of the database. To unblock me, Sully pulled the six-digit code straight from the auth tables and posted it in the thread. It worked, and it is also a little alarming. Your builder can see your sign-in codes.

6. Twilio Verify was set up and waiting. I asked whether we could switch to it, and Sully confirmed it skips the carrier campaign entirely. No code changes, just three values in a settings screen. At 2:55 PM my phone buzzed.

Five minutes later I confirmed in PostHog that sign-in events were flowing, tied only to an anonymous user ID, with no phone number anywhere. V0 was done.

And then I threw it all away

At 3:30 PM, before V1 began, I told Sully to remove phone sign-in completely and go back to email codes. My email domain for the project was ready, and email doesn’t come with a carrier bureaucracy attached.

That one decision unravelled more than the login screen:

• Every test account had to go, because they were all phone-only. Sully stopped and asked me to approve DELETE FROM auth.users before running it. I appreciated that.

• Sully had just designed a phone_last_four column so gallery cards could show a masked number like •••• 1234. Gone, six minutes after it was proposed.

• Sully asked how people should appear publicly: a masked email, the first part of their email address, or a display handle they choose. I picked the handle. Elian later made it a rule: email is for signing in, the handle is for showing up.

The whole switch took six minutes of building. The phone version took an hour and a half to get working. If you’re a little old lady weighing phone sign-in for a hobby project, that ratio is the lesson.

And please rotate any credentials you paste into chat. Both Sully and Lovelace reminded me. Neither of them could do it for me.

V1 to V3: two proposals, one decision

Once sign-in settled, a rhythm took over. Lovelace or Sully proposed, sometimes both. I asked the other one to react. Somebody named the trade-off out loud. I picked. Sully built it in under fifteen minutes.

V1: the spec did the heavy lifting

Lovelace wrote the V1 spec: a storage bucket where each person can only write into their own folder, a photos table, an upload page, a gallery, and a moderation console. One rule mattered more than the rest. Nothing a user posts ever gets hard-deleted. Removed photos get a flag, so moderation can always be undone.

Then Elian weighed in as art director. Warm, calm, cream and terracotta, and the animal photos are the star. Two calls from Elian changed the build:

• “Load more” instead of infinite scroll. Lovelace’s spec had said “your call” on pagination. Elian made the call: simpler, easier to test, fewer strange moderation edge cases. Lovelace agreed and told Sully to treat it as decided.

• The admin console should feel serious, not playful. A removed photo stays visible to admins with a status tag instead of vanishing.

Sully built V1 in five minutes.

I immediately asked for a /design page, a new habit I working to incorporate from Friday’s project. It’s a private playground showing every color, font size, button and card state in one place. Elian wanted it behind sign-in and left out of the menus. Three minutes later it existed.

At 4:11 PM I told Sully I thought we had a V1. I’d been sharing the screenshots on Substack all afternoon.

V2: safety first, conversation later

I asked both of them what V2 should be, and got two different lists.

• Lovelace focused on what happens after someone behaves badly: three strikes and you’re suspended, an appeal page, email notifications, and letting people edit or delete their own photos.

• Sully focused on how problems get noticed and what people can do: a Report button, threaded comments, and a personal “My Pawprints” collection.

So I asked Sully to read Lovelace’s list and reconcile them. Sully’s answer is my favorite moment of the day: the two lists were “two sides of the same coin,” governance and inbound reporting. Then Sully laid out the real choice. Option A was safety, trust and control first, with comments pushed to V3. Option B was safety plus comments right away. Sully recommended A.

I sat with that for 28 minutes, then said yes to A.

One honest note from rereading the thread: Lovelace’s email notifications were part of the Option A plan, but they never appear in Sully’s V2 summary, and none of us asked. Rereading your transcript is how you find those.

V3: the questions that protected the design

For V3, Lovelace proposed public creator pages anyone could visit, reactions, and comments. Sully answered with two questions that kept the whole thing from sprawling:

1. Should creator pages be public? Doing that would mean opening the photo storage and database rules to signed-out visitors, creating a second set of permissions to maintain. I said keep everything behind sign-in.

2. One reaction per photo, or several? One. Paw, heart or smile, pick a favorite.

Comments arrived flat, not threaded. Sully had pitched threaded comments back in the V2 discussion, with each comment pointing at its parent comment. You know I love a structure that refers back to itself. It got deferred twice, and the V3 table was designed so that a parent_id column can be added later without rebuilding anything. Recursion postponed, not abandoned.

Using it is how you find the holes

None of the specs caught these. Me poking at the app did.

“Twice I’ve uploaded pictures without animals”

An animal photo gallery that accepts landscapes is just a photo gallery. The upload only checked file type and size; spotting off-topic pictures was left to other users hitting Report.

Sully offered two designs. Check every photo before it’s saved and reject it on the spot, or let it upload and send uncertain ones to an admin review queue. We went with checking first. Now every photo goes to an AI vision model on the server before anything is stored. If the model can’t find an animal with enough confidence, the upload stops. If the check itself fails, the upload fails too. Nothing slips through because a service was down.

I suggested we test it with a stuffed animal. Sully pointed out the instructions to the model already say that plush toys, drawings and cartoons don’t count. Sully also offered a custom message for plush toys. We skipped it, but I still think about that teddy bear.

The check adds a couple of seconds, which feels like a frozen screen, so I asked for a friendly status message. Two minutes later the upload page walked you through it.

“I’m hitting the 5MB limit”

My own cat photos were too big. Modern phones take 6 to 15 MB photos. Sully gave me two options: raise the limit and show people the exact file size, or shrink big photos in the browser before upload. I picked shrinking. Anything over 5 MB now gets scaled to 2048 pixels on its longest side before it’s checked and stored.

Right after that I asked Sully whether my requests had disturbed what he was building. Sully said not at all: each one was additive and none of them touched the database rules. That answer is also a design review. Changes that slot in without touching your security model are cheap. The ones that do touch it deserve the 28 minutes.

“Am I the admin? Will others see it?”

After the test data cleanup, a Moderation console link showed up on my home page and I wondered who else could see it. Sully explained that the cleanup had made me the admin on purpose, then listed four separate layers keeping everyone else out: new accounts default to non-admin, the link only renders for admins, the /admin page redirects anyone else, and the database itself refuses moderation actions from non-admins. Hiding a link is decoration. The database saying no is security.

“I had to hunt for sign out”

It was at the bottom of the home page, below everything. Now it’s in the header on every page.

The review that kept turning into pull requests

The roles were supposed to be simple. Sully builds. Lovelace specs and reviews. Getting Lovelace to only review took most of the afternoon.

Lovelace in Slack runs in two modes. In one, she can talk but can’t see code. In the other, she gets a coding session attached to a GitHub repo, and that session comes with a “Create PR” button and a strong instinct to change things. Here’s how that played out:

I’ll give Lovelace credit for one thing. When she couldn’t do the review, she said so instead of inventing one. A made-up review that sounds confident is far worse than “I haven’t seen the code.”

What the review actually found

Once it existed, the review earned its keep:

• A “null strikes” bug. Removing a photo without a strike made the admin notice read “@handle now has null strikes.”

• Orphaned files. If the upload saved the photo file but then failed to save its database row, the file sat in storage forever with nothing pointing at it. Sully’s V1 summary had described the upload as rolling back on failure. The code had a path where it didn’t.

• No cooldown on “Resend code.” Fast tappers only learned about the rate limit after hitting it.

• A gap worth writing down. Someone holding the storage path of a removed photo could still fetch it. Probably fine, but it should be a deliberate, documented choice, not an accident.

Sully fixed all four in five minutes, plus a retry on the AI check from the review’s low-priority list, and recorded the decisions in the project’s AGENTS.md file.

The lesson I’m keeping: an AI builder’s summary of its own work is a claim, not evidence. A second set of “eyes” on the actual code found two real bugs in a codebase that every summary called solid. And if you want an AI to review without editing, say so up front, and expect the tooling to need reminding.

Friend of the Day, and the word “friend”

At 5:45 PM I had an idea: when you sign in, show you a “friend of the day,” picked using the animals you’ve reacted to. I sent it to both of them.

They read the same sentence two different ways.

• Lovelace read “friend” as the animal. She proposed picking one photo you’d reacted to, remembering which one you’d seen last so it wouldn’t repeat, and falling back to the most popular photo for brand-new users.

• Sully read “friend” as the person who uploaded the animal. He designed an affinity graph: which creators’ animals you react to most, or which members share your taste. Then he asked which kind of friendship I wanted.

Neither of them was wrong. My sentence was ambiguous, and I’d never have noticed with only one reader. I told Sully I meant our fuzzy friends, not the people.

Then Sully reviewed Lovelace’s version and improved it in two ways:

1. Count comments as well as reactions. Commenting on a photo means you care about it more than tapping a heart does.

2. Don’t store anything. Lovelace had suggested remembering the last featured photo, either in the browser or in a new database column. Sully pointed out that the browser forgets across devices, and a column means a database write every time you load the home page. His alternative: combine your user ID and today’s date into a hash and use it to pick from your candidates.

That second one is my favorite piece of engineering in the whole build. Your friend of the day is a pure function of two inputs, who you are and what day it is. Reload all you like, it’s the same animal. At midnight UTC it changes on its own. No table, no tracking, no writes. Mwahahaha.

Build time: three minutes.

The discard pile

For every feature that shipped, something else got proposed and set down. I think this list is worth more than the feature list, because it’s where the judgment lives.

Notice how many of these are “less.” Less to configure, less to secure, less state. The AIs proposed generously, and most of my job was choosing the smaller version.

Wrapping up: a movie and a G rating

The last half hour was about presenting it.

At 6:06 PM I asked whether we should screenshot everything for Elian. Elian sent a checklist: home, upload in two states, gallery, admin, the design page, and mobile versions of the main screens. Sully captured the set in four minutes, at desktop size and at phone width.

While those were rendering, I asked Lovelace for a short film script I could hand to Rowan, my visuals partner, for the Code Like a Little Old Lady Presents site. Six scenes, cream and terracotta, slow fades, real screenshots in phone frames. It ends on “Built with love. Reviewed by a team of cats.” Which, given my household, is accurate.

Then one last feature. Back at 6:10 I’d said comments should be “rated G”: no bullying, no swearing, no hate speech. At 6:19 I told Sully we were ready for it, and then we’d call it done.

Sully modeled it on the animal check. Every comment now goes through the server, gets evaluated by an AI model before it’s saved, and is blocked if it isn’t G-rated. Users can no longer write comments straight to the database at all. If the moderation service is down, the comment is refused and you’re asked to try again shortly, rather than letting it slip through. A blocked comment keeps your draft so you can rephrase. And the analytics only record that a comment on a given photo was blocked, never what it said.

At 6:22 PM Sully wrote that Pawprint was “fully wrapped and ready.” Three minutes for that last build.

What I’m taking away

• Building is the cheap part now. Seventy-five minutes of building across nearly five hours. The rest was the actual job: deciding, testing and saying no.

• Two AIs beat one, if you make them read each other. The best answers of the day came from asking Sully to reconcile with Lovelace, not from either of them alone.

• Use the thing. The vision check, photo shrinking and the sign-out move all came from me tripping over something in the app.

• Summaries are claims. The code review found bugs in work every summary described as solid.

• Write down the discard pile. It’s the most useful record of the afternoon, and it only exists because the whole build happened in one thread I could reread.

I planned to stop there. At 10:48 that night I was back in the thread with a new requirement: if Pawprint was going to the Apple App Store, it needed a way for people to block each other. I decided I’ll be writing a series on building Pawprint for the App Store.

Lovelace + Alison

Note: This was written by Lovelace using the session data from the build and edited by Alison

Every day until SheBuilds I’m trying experiments. Friday’s experiment was how quickly could I go from nothing to a working app with the basic functionality I consider necessary in any app.

At 10:18 on a Friday night, I had someone else’s prompt for a gift tracker app. By 12:54 the next morning, I had a published app with sign-in, sharing, email notifications and a new-year setup. It cost 99.9 Lovable credits. We ended with All Wrapped Up

shared the prompt they had used for their own gift tracker. It was thoughtful. It had a data model, a feature list and a set of working instructions. I could have pasted it straight into Lovable and gone to bed.

Instead, I handed it to Lovelace first and asked her to fill in the blanks. The prompt I started with would have built the app, and built it well, but. it wouldn’t have been my app.

The prompt that looked complete

The borrowed prompt described a gift tracker built around people. People had yearly budgets. Occasions had recurring flags. Gifts moved through five statuses: idea, planned, bought, wrapped, given. Everything lived in the browser, with no accounts.

The prompt review found gaps I would want to add to the app. I read through the features that would have been built from the prompt and realized they were answering a different question than I wanted my app to answer. And with AI, we no longer need to build our process to fit the software, we can build our own. So, Lovelace and I decided to start over with how I worked.

I truly appreciated her sharing the prompt, but the gift she truly gave me was realizing, I could easily build what I wanted.

Three questions that changed the app

When Lovelace asked how I actually keep my lists, I described my old Evernote note. A year. A name. Checkboxes beside each name. One page for birthdays grouped by month. One page for Christmas split into various extended family members, whoever was drawn in the name swap, and my immediate family with Want, Need, Wear, Read.

Three questions turned that description into a different design.

Are the unticked rows alternatives, or a to-buy list? A to-buy list. I buy all of them. So, a person is not covered when one gift is bought. They are covered when every row is ticked. That one answer rewrote the status logic.

What is an occasion? A date with people on it. Christmas is one date with many people. A birthday is one date with one person, or two if they are twins.

Who else needs in? Sean and I share the nieces, nephews and our kids. We each keep private lists for each other. Lovelace’s first instinct was a “household.” The better answer was sharing chosen people on a chosen date with a chosen email. No household at all.

None of those answers were in the borrowed prompt. They couldn’t be, they were about me and my process.

Three partners, one loop

I did not build this alone, and I did not build it with one AI. I used three of my thinking partners, each doing the job they are good at.

• Lovelace (Claude) shaped the design with me, wrote the build prompt, and reviewed every section by reading the actual code in GitHub.

• Sully (Lovable) planned and built it, eight sections in order, starting with the database and its security rules.

• Rowan (ChatGPT) gave it a look and feel, a watercolor gift box logo, and eventually a new name.

The rhythm was simple. Sully built a section. Lovelace read the repo and wrote a short note of what to fix. I pasted the note back to Sully. Repeat.

I was the message bus. That sounds like a joke, but it was the point. Every handoff went through me, so I saw every decision and could say no to any of them.

My next experiment will be having the building all happen in the Inner Chamber Slack to see how that goes. It could be very helpful during #SheBuilds.

Rowan’s best contribution came halfway through. The app started as The Gifting Guide. Rowan suggested All Wrapped Up, and a celebration when you tick the last gift on an event: Every gift accounted for. Every person remembered. The name and the finish line became the same thing.

What the reviews caught

Sully is a strong builder. The code was clean, documented and tested. And it still had problems that only show up when you ask, “what happens next year?” or “what could someone do on purpose?”

None of these were exotic. Every one was a sentence in plain language, pasted back to Sully, and fixed in the next round. The hard part was not fixing them. It was noticing them before building on top of them.

The numbers

About two and a half hours, from 10:18 PM to 12:54 AM. 99.9 Lovable credits. Eight sections, plus share notification emails I decided I wanted at the very end.

The eight sections were:

1. Database, security rules and tests

2. Sign-in with an emailed code

3. Design foundation: colors, fonts, the logo, the status badge

4. People

5. Events and gift rows

6. The year view

7. Sharing

8. New-year setup

The order mattered more than the speed. The security rules came first, before any screen existed, so every screen after that was built on something already checked. When a review changed the data model, like twins sharing a birthday, it changed before the screens depended on it.

One unexpected learning came out of section 3. Sully built a page called /design, a living style guide that shows the real building blocks with made-up people and gifts: the status badges, a recipient card, a gift list you can tick. Nothing on it is saved. This is something I will now add to every new project.

It turned into my sandbox. When I want to try a change to a badge, a color or the gift list, I look at it there first, on sample data. No sign-in, no test entries cluttering my family’s lists, and no wondering what a tweak will do to Christmas before I’ve seen it.

Sully used the same idea for color. When Rowan and I wanted a warmer purple, Sully added a temporary toggle to the sign-in page so I could flip between the original plum and aubergine on the real screen. I picked aubergine, and the toggle came out.

This morning I am doing small tweaks as I write this. All of the real work was there when I woke up.

If someone hands you their prompt

A good prompt from someone else is a gift. It is also a description of their life, not yours.

If you are handed one, here is what I would do before pasting it anywhere:

• Describe how you do the thing today. Your Evernote note, your spreadsheet, your sticky notes. That is the real spec.

• Ask what “done” means. For me, every row ticked. For the person who wrote the prompt, maybe one gift bought. Same app, different finish line.

• Ask what happens next year. Recurring things are where data models break without telling you.

• Build the rules before the screens. Who can see what, and what counts as covered, belong in the database where every screen has to agree.

• Have someone review the actual code. Not the summary of the code. The code.

The borrowed prompt got me to the starting line. Three questions about my own life got me to the right app. A loop of build, read, fix got me to one I trust with my family’s Christmas.

All wrapped up, at 12:54 AM.

Give it a try at All Wrapped Up

A starting prompt you can use

It felt wrong to write an essay about borrowed prompts and not hand one over. So here is mine, with everything Lovelace, Sully and Rowan taught me folded in.

It is deliberately not finished. The blanks in square brackets are your life: your groups, your traditions, your finish line. And the very first thing it asks the builder to do is interview you.

It is written for Lovable with Supabase. Other builders will need small changes to the sign-in and security details.

# Gift tracker: starting prompt

You are building a gift purchase tracker with me. It is not a wishlist. It is where I record what I am buying for each person, so I can see at a glance who still needs a gift.

## Before you build anything
Interview me, one question at a time, until you can play back how I do this today. Ask at least:
1. Show me how you track gifts now (a note, a spreadsheet, paper). What does one year look like?
2. When there are several unticked ideas under a name, are they alternatives (you buy one) or a to-buy list (you buy all)?
3. What groups do you buy for? (Mine: [immediate family, nieces and nephews, a name swap draw].)
4. Do any groups have a tradition with fixed slots? (Mine: [Want, Need, Wear, Read at Christmas only].)
5. Who else needs access, to which people, and should they view or edit?
Then play back the design in your own words and wait for my approval.

## Core model (adjust after the interview)
- An event is a date plus the people I am buying for on that date. Christmas is one date with many people. A birthday is one date with one person, or several (twins).
- A recipient is one person on one event, with a group label.
- A gift row is one thing I am buying for a recipient. It starts unticked and is ticked when bought.
- Each user owns their own people and events. Lists are private unless shared.
- A share gives one email view or edit access to chosen recipients of one event. No household.

## Status (one place, in the database)
Compute each recipient's status in a single database view, never in the screens:
- Needs ideas: no gift rows, or a fixed-slot tradition with a slot still empty.
- Still shopping: at least one unticked row.
- All covered: every row ticked.
An event with no one on it is never covered.

## Rules learned the hard way
- Sharing trusts an email only once it is confirmed. Check email_confirmed_at in one helper function.
- Purchase fields (when and who bought) are written only by one toggle function. Block direct writes.
- Undo after delete is a delayed delete, never a re-insert.
- Never share someone's own gifts with them: refuse in the database if a recipient's email matches the share's email.
- Recurring events need a year. Last year's gifts become history, never overwritten.
- New-year setup copies stable groups and starts [name swap] empty. It is one database function, safe to re-run.
- One birthday event per date. People added mid-year with an upcoming birthday join this year's event.
- Fixed-slot traditions apply only where I say they do.
- Shared users see only the recipients shared with them, enforced by row-level security, not hidden buttons.
- Any email the app sends: only for new shares, no names or gift details, rate-limited per sender and per recipient.
- Dates are plain dates. Never shift them through a time zone.

## Stack
Lovable with Supabase. Sign-in by emailed code, not magic link. Row-level security on every table.

## Build order
1. Schema, security rules and tests (including an outsider who sees nothing and a grantee who sees only their share)
2. Sign-in
3. Design foundation, plus a /design page showing the components with sample data
4. People
5. Events and gift rows
6. Year view
7. Sharing
8. New-year setup
After each section, tell me exactly how to test it, including one edge case. Keep docs/decisions.md and AGENTS.md updated.

## Look and feel
[Your colors, fonts and tone.] Mobile first. Tap targets at least 44px. Status never shown by color alone. Rows never move when ticked.

## Working with me
Name your assumptions. Ask one question at a time. If something I ask for would break the data model, say so and suggest a simpler option.

One last suggestion: have someone, human or AI, read the actual code after each section. Every row in my table above was caught that way.

Lovelace + Alison

A quick recap if you are joining here. In the first post, I got one Lovable database to act like two, a dev side and a prod side, using separate schemas. This post is about the part that worried me most: making sure the wall keeps strangers out.

The most useful thing the database said to me this week was an error. The most dangerous thing it said was the advice that came with it.

I was testing my dev and prod setup. I wanted to be sure a signed-out visitor could not write anything. So I asked Sullivan to try an insert with no sign-in, straight through the client, and report back the exact error.

Here is the prompt:

Try inserting a plate into dev as a signed-out visitor, directly through the client, and report the exact error.

Here it is:

status: 401 Unauthorized
code: 42501
message: permission denied for table plates
hint: Grant the required privileges to the current role with: GRANT INSERT ON dev.plates TO anon;

The refusal is the good part. The hint is the trap, like a stranger in a trench coat sliding you a note.

Follow that hint and any stranger on the internet can write to my table. The error message is trying to be helpful. It is trying to make the error go away. It does not know that the error is the feature.

Two locks, not one

This is the part I found worth writing down. A table in this setup has two separate locks.

1. Grants decide who may touch the table at all. A signed-out visitor has no insert grant, so the database stops them at the door. That is the error above.

2. Row level security decides what a person who got in may do. My policy says only signed-in users may insert.

My signed-out test only proved the first lock. The signed-in inserts I ran earlier proved the second one works for the people it should let through.

Why keep both? Because grants get changed in a hurry. Someone follows a hint, or a tool does, and a grant appears that should not. If the policy is still there, it still holds. One lock failing should not be the end of the story.

What I took from it

• A permission error is a result, not a problem to fix. Read it first, then decide.

• A suggested fix is written to silence the error. It is not written to keep you safe.

• Test the thing you want refused, and write down which layer refused it.

I left the hint alone, and the error stays.

A quick recap if you are joining here. Lovable gives me one managed database, and I wanted a dev side and a prod side. In the first post, I got one database to act like two, using separate schemas picked by the web address.

The test worked. I want to say that first, because the interesting part is what I did next.

Two databases inside one, picked by the web address, with a wall that held in both directions. I had a working answer to a problem I cared about. And I decided not to use it in the build I start on October 15.

What it would cost

The test gave me a precise bill:

• Every change to a table has to be made twice, once per schema.

• The generated types only know about public, so my queries need a workaround that turns off some of the checking.

• The Cloud tab cannot show me the tables, so I would read my own data through queries.

• Users are shared across both worlds, so a dev sign-in is also a prod sign-in.

• The hostname rule is a convenience, not a lock. Row level security is the real protection.

None of that is a dealbreaker. All of it takes hours.

The number that decided it

The build I start on October 15 is a Lovable event. It is called 72 hours, but the clock from kickoff to deadline is 60, and some of those hours are sleep. After all that setup, the “prod” side would hold almost nothing except demo data. I would be paying doubled migrations to protect a database with nothing precious in it.

Feasible and worth it are two different questions. The test answered the first one. It could not answer the second, and I almost let it.

There is another way out, and I should say so. What I want may be possible on a Lovable Business account. I have not made that leap, yet. If it is possible, that trades hours for money, which is a different question, and one I will ask once the build is over.

Where it goes instead

This is now a pattern I have tested and written down, parked for after October 17. When I come back to it, I will add two things the test showed I need:

1. One wrapper that owns the schema choice, so the workaround lives in a single place.

2. A check that fails any query that does not name its schema, so nobody has to remember.

I wrote the decision down with the full test results, so future me does not have to rerun the experiment. If you are building on Lovable and have wished for a dev database, the prompts in the first post will get you started.

Curiosity is allowed to run ahead of the build. It just does not get to pick what goes in it.

Alison + Lovelace

One honest note before I go on. What I want may be possible on a Lovable Business account. I have not made that leap, yet. This post is about what I can do with the pro plan I have today.

I got curious about something this week, and I want to show you how the curiosity went, including the part where my first answer was wrong.

With each new project I build with Lovable, I pick some “thing” that is important to me to see how to build it with Lovable. Tonight was a separate dev and production database.

Lovable gives me one database, and Lovable manages it. I can preview my app (dev) and I can publish it (prod), but both talk to the same data. No dev database. No prod database. Just the one.

Most developers solve this the same way: two environments, two databases, and a path that carries code from one to the other. Lovable gives me half of that. I can work on a branch and publish when I am ready. What it does not give me is a second database to point the branch at.

So my next idea was two Lovable projects, each with its own database, both homed on one GitHub repo. A dev branch feeds the dev project. A pull request merges to main, and main feeds the production project.

That runs into how Lovable connects to GitHub. One project gets one repo, and it is always a brand new repo. I cannot point a second project at a repo that already exists. Two projects means two repos.

Fine, I thought. Two repos, and I copy the code from one to the other when it is ready. That is a promotion step instead of a merge, and it can be done. But the copy carries the settings file with it, and that file holds the address of the database. Lovable writes it for each project. Copy it across without care and the production project points at the dev database, or the other way around.

You can protect that file during the copy. I have saved that whole pipeline for later, because it is a good pattern. But it is a lot of machinery just to keep two sets of rows apart, and a lot of places to make a mistake that only exists because of the setup.

So I went looking for a way to do it inside the one database.

If you have ever worked in SQL Server, you know a trick for this. You keep dev.plates and prod.plates side by side, same table name, different schema. So I asked: does Supabase do that?

It does. Supabase is Postgres underneath, and Postgres has schemas.

One note before the story. Everything below happened in a throwaway Lovable project, made only for this test. It is not the project I will build in October. The only thing that carries over is what I wrote down.

I kept the prompts I used, so you can run the same test. They are in the grey boxes. Use a throwaway project, not one you care about. These prompts change which schemas your database exposes.

Round one: make it exist

I asked Sullivan, my Lovable partner, to create a dev schema and a prod schema, each with a small plates table. It ran. It reported no errors.

Here is the prompt:

Add a migration that creates two schemas, dev and prod. In each, create a table named plates with id (uuid, default gen_random_uuid()), state (text), text (text), created_at (timestamptz, default now()), and a unique constraint on (state, text). Turn on row level security in both. Add a policy in each that lets anyone read and lets signed-in users insert. Grant usage on both schemas, and the matching table privileges, to the anon and authenticated roles.

Then I opened the Cloud tab and it showed no tables at all. That was not what I expected.

Nothing had failed. The Cloud tab only lists the public schema. The tables were there. The tab just could not see them. That is a real cost, and I will come back to it.

Round two: let the app see them

The app could not reach the new schemas. The error was Invalid schema: dev. By default the API only exposes public.

One database setting fixed it. I told the database which schemas the API may serve. The same request that failed now returned an empty list, which is exactly what a new table should say.

This is the corrected version, with the full list. My first one left out graphql_public, more on that below.

Add a migration that adds dev and prod to the schemas the Supabase API exposes, alongside public. Use:

alter role authenticator set pgrst.db_schemas = 'public, graphql_public, dev, prod';
notify pgrst, 'reload config';
notify pgrst, 'reload schema';

Round three: do they stay apart?

I had Sullivan build a tiny test page with a dev and prod dropdown. Two plates into dev. Switch to prod: empty. One plate into prod. Back to dev: still just the two.

A shortened version of that prompt:

Add a test page at /schema-test with a dropdown for dev or prod, a button that inserts a plate (state "CA", text "TEST" plus a random 4 digit suffix) into the chosen schema, and a list of plates from the chosen schema. Use the schema on each query with supabase.schema(chosen).from("plates"), not by changing the global client. If the generated types do not know about the dev and prod schemas, tell me and do not edit types.ts by hand. Signed-out visitors can see the list but cannot insert.

The wall holds, in both directions.

Round four: where my first answer was wrong

I assumed I could pick the schema with an environment setting, one value for the preview and another for the published site. That is how most people separate environments.

It does not work here. There is one settings file, and the value is baked into the app at build time. Preview and published read the same thing. And they both had the great big red banner.

What does differ is the web address. The preview lives at one address and the published site at another. So the app now looks at its own hostname. If the address is on a short list I trust, it uses prod. Anything else, dev, with a banner that says DEV DATA.

The core of that prompt, shortened:

Decide the schema from the hostname, in one shared helper that the browser and the server both call. Only the published hostname is on the prod allowlist. Everything else, including preview hosts, localhost and unknown domains, resolves to dev. In the browser, resolve after hydration so the first paint matches the server render. On the server, read the request's Host header. When the resolved schema is dev, show a visible banner that says DEV DATA.

I published it and checked both. Preview: banner, two dev plates. Published: no banner, one prod plate, and nothing leaked across.

The design choice I like best is the boring one. An address I do not recognize falls back to dev. If I get the list wrong, the app shows an empty site. It never writes test rows into real data.

I have ended the test proving it works, but determined for SheBuilds it’s just an extra thing I don’t want to worry about. We proved out that Sully remembered not to use public when I had him make more changes, but that was with a short time window. What happens over time. Over sessions. While I’m trying to get something published. But I will be coming back to this after SheBuilds.

Alison + Lovelace