Last year it was everywhere.

This year he stood on a stage at Sequoia and called it passé.

I named a newsletter after that word.

So let me be the one to tell you what actually happened, because most of the takes I have read this week are wrong in the same lazy way.

New here? Subscribe so the next build lands in your inbox. It is free.

It goes like this:

1. What Karpathy actually said (it is not “AI coding is dead”) (everyone got this backwards)

2. The one thing that really changed, and it is not the models

3. The three questions I now ask before I let an agent write a single line

4. How to make your agent show you its plan first, click by click (this takes four minutes)

I will show you every step, with screenshots.

But first, here is what the change looks like on my actual screen.

PS: if terminal looks scary to you, ignore the background and just focus on the content/text on it.

Two things before we start:

1. Save this and block twenty minutes this week to actually run the three questions on your own project.

2. Send it to one founder who is about to ship something they have not read.

Sharing is free, and it is how this newsletter grows.

Share

I named my newsletter after a word that just expired.

That is an awkward sentence to write.

I have been building software for over seven years.

I am a developer and a software architect, which means I spent a long time doing this the hard way before the AI showed up to do the typing.

And when Karpathy coined “vibe coding,” I did not think it was a threat to my job.

I thought it was the best on-ramp I had ever seen for the people I teach.

Because it gave them permission.

Permission to open a tool and describe a thing and watch it appear, without first learning what a semicolon does.

That permission was real, and it worked, and I am not taking it back.

But I am also not going to pretend the word aged well.

I am not selling you a new label today, and I am not going to tell you that you now need a course to keep up, because you do not.

If anything in here is useful, the only thing I want is for you to stay on the list, which is free, and read the next one.

1. What he actually said (nobody read past the headline).

Here is the quote everyone clipped.

Vibe coding is passé.

Here is the part they cut off, which is the part that matters.

Karpathy’s replacement term is agentic engineering.

He explains it in two halves.

“Agentic” because the new default is that you are not writing the code directly ninety-nine percent of the time, you are orchestrating agents who do, and acting as oversight.

“Engineering” to emphasise that there is an art and a science and an expertise to it.

Read that again, slowly.

He is not saying stop using AI to build.

He is saying the opposite.

He is saying using AI to build has become so normal that it is now just how professionals work, and the skill has moved somewhere else.

The skill moved from typing to oversight.

And then he said the line that I think is the most useful sentence anyone has written about this all year.

Vibe coding raises the floor for beginners.

Agentic engineering raises the ceiling for professionals.

Those are two different jobs, and both of them are still open.

Twelve headlines say it died. One page says what he actually meant. Guess which one got the clicks.

2. The thing that really changed is not the AI. It is who is holding the bag.

Here is my honest read, and it is less exciting than the headlines.

The models did not suddenly become trustworthy.

They became good enough to be dangerous.

A year ago, when an AI wrote you something broken, it was usually obviously broken.

It did not run.

You got a red error, you pasted it back, you moved on.

Now it runs.

It runs, it looks right, it deploys, and it is wrong in a way you cannot see from the outside.

That is a much worse failure mode, and it is the actual reason the word had to change.

The Stack Overflow developer survey found that sixty-six percent of developers say AI answers are “almost right, but not quite.”

Almost right.

That phrase is doing an enormous amount of work.

Forty-five percent said they lose significant time debugging AI-generated code, which is a very funny way of saying the time you saved has been quietly repossessed.

And only twenty-nine percent said they actually trust the output to be accurate.

These are professional developers.

People who read code for a living.

(If they are getting caught, the idea that you will spot it by vibes alone is optimistic, and I say that with love.)

So the word did not die because AI got worse.

The word died because “I do not read the code” stopped being a cute personality trait and started being a liability with your name on it.

If this is landing, send it to one founder who is still describing themselves as a vibe coder in their bio.

Share

3. The three questions I ask before I let an agent touch anything.

This is the whole oversight pass.

It takes about ninety seconds and it has saved me more time than any prompt I have ever written.

I ask these out loud, at the plan stage, before a single file changes.

Question one: what are you about to touch?

Not what are you going to build.

What files are you going to open, change, or delete.

If the agent says nine files and I asked for a button, something is wrong, and it is wrong right now while it is still free to fix.

Question two: what happens if this is wrong?

Is this a cosmetic thing where the worst case is an ugly button.

Or is this the thing that decides who can see whose data.

I am relaxed about the first one.

I read every line of the second one.

(These two categories are not the same and treating them the same is how people end up in a security blog post. More on that Thursday.)

Question three: how will I know it worked?

Not “does it look like it worked.”

What is the actual test.

What do I click, what should I see, and what should I see if I am logged in as somebody else.

If I cannot answer that, I do not ship it, because I have just admitted I have no way to tell success from failure.

That is it.

Three questions.

You will notice none of them require you to read a single line of code.

They require you to think like the person who is responsible, which you already are, whether or not you feel like it.

4. Make your agent show its plan first (four minutes, do it today).

You do not need a new tool for any of this.

You need to turn off the default where the agent just goes.

Here is the smallest version, click by click.

Step 1. Open your agent of choice.

I use Claude Code in the terminal.

Google Antigravity works the same way if you prefer a desktop window with buttons (and if you are on the Google stack, this is the one you want, we will get into why on Sunday).

Step 2. Before you describe your feature, type this one line first.

Before you write anything, show me your plan as a numbered list, and tell me which files you will change. Do not write code yet. Wait for me to say go.

That is the whole trick.

Three sentences.

Step 3. Now describe what you want, normally, in your own words.

Do not try to sound technical.

“I want people to be able to save a recipe to their profile” is a perfectly good specification.

Step 4. Read what comes back.

Actually read it.

This is the step people skip and it is the only step that matters.

Count the files.

Step 5. Run the three questions from section three against that plan.

If any answer makes you uncomfortable, do not approve it.

Type “that is too big, do only step one” and send it back.

You are allowed to do this as many times as you want.

(The agent has no feelings about it. I have tested this extensively, on its behalf and on mine.)

Step 6. Only now, say go.

Here is the part I like.

Once you have done this a few times, you start noticing when a plan is too big before you have read a word of it.

You develop a nose for it.

That nose is the skill Karpathy is talking about, and you cannot buy it, you can only get it by reading plans and occasionally saying no.

Where this falls short (being honest).

It is slower. Genuinely.

You are adding a read-and-think step to a process whose entire selling point was that there was no read-and-think step.

On a tiny throwaway project, skip it, I do.

It does not make you a developer. Reading a plan is not the same as reading code.

It catches the big obvious wrongness.

It will not catch a subtle logic bug, and anyone telling you otherwise is selling something.

The agent can write a lovely plan and then not follow it. This happens.

Less than it used to, but it happens.

The plan is a filter, not a contract.

Nobody agrees on the vocabulary yet. Some people say agentic engineering, some say AI-assisted, some are still happily saying vibe coding and shipping fine work. The word matters much less than the pause.

I am keeping the word. Here is why.

Nobody paid me to write this.

Karpathy does not know I exist, and my newsletter is not going to change his mind about his own term.

Here is where I actually land.

The floor he raised is the thing that let a bunch of people I teach build their first real product, and I am not going to stand on that raised floor and tell them the word that got them up here is embarrassing now.

But I am going to hand them the three questions.

Because “vibe coding” was never really about not reading the code.

It was about not being scared of the code.

Those got confused somewhere around the middle of last year, and the confusion is what expired, not the idea.

People read this because someone they trusted forwarded it to them. If it earned that, be that person for someone else.

Share

And if a stranger sent you this one, thank them, then subscribe so the next one finds you on its own.

Subscribe now

Save this.

1. Karpathy retired “vibe coding” for “agentic engineering.” He did not say stop building with AI. He said the skill moved from typing to oversight.

2. The models did not get worse. They got good enough to fail quietly, which is harder to catch than failing loudly.

3. Two thirds of professional developers say AI output is “almost right, but not quite.” You are not slow for missing it.

4. Before any agent writes code, ask: what files will you touch, what happens if this is wrong, and how will I know it worked.

5. Paste “show me your plan first, do not write code yet” as your opening line. That is the whole seatbelt.

PS: Thursday I am going to show you exactly what “failing quietly” looks like in the wild, and it involves one and a half million API keys. Bring your app. We are going to look at it together.

Leave a comment

Not prompt once and pray.

Talk to. As in, make it, look at it, say “make the light warmer,” and watch it change.

It is called Gemini Omni Flash, and inside Google AI Studio it costs money.

But there is a door where it is completely free, and almost nobody has noticed it yet.

I tested this on a free YouTube account with no Premium and nothing special on it.

New here? Subscribe so the next build lands in your inbox. It is free.

Today I am going to walk you through that door, and you are going to leave with a real video of your app.

It goes like this:

1. I show you the paid door first, so you know what you are skipping (and what it would have cost)

2. We find the free door, which is not where anyone expects it

3. You make your first clip by typing one sentence

4. You talk to it and fix the bits you do not like

5. You get the file out so you can use it anywhere

I will show you every step, with screenshots.

But first, here is the thing that made me sit up.

Two things before we start:

1. Save this, then give yourself fifteen minutes tonight and make one clip. Just one.

2. Send it to a founder who keeps saying they need to “get a video made.”

Sharing is free, and it is how this newsletter grows.

Share

Why I bothered chasing this down.

I ship products for a living.

(They all end up at prompts2products.com eventually, if you would rather see the things than read about them.)

And the gap I watch people fall into, over and over, is not building the thing.

It is that they build the thing, and then they have nothing to show anyone.

No demo.

No clip.

Just a link and a hope.

So they screen record something at eleven at night, it comes out shaky and forty seconds long, and it never gets posted.

I have done exactly this. More than once.

When Google launched Omni Flash at the end of June, I assumed it was another thing I would need to pay for before I could form an opinion.

Then I actually went looking, and found that the free version is sitting inside an app that two billion people already have on their phone.

(I am not going to pretend I found this out of pure genius. I found it because I was annoyed about a paid badge and kept clicking.)

1. First, let’s be honest about what free actually means.

I am not going to sell you a free lunch and hide the bill in the small print.

Here is exactly what you get and exactly what you give up, in plain words.

What you get. The real Omni Flash model. Text to video. Image to video. Conversational editing, which means you can ask for changes in normal English instead of starting over. Sound generated with the picture.

What it costs. Nothing. No subscription. No invite list. No card.

Limit one, ten seconds. Clips are capped at ten seconds at launch. That is short. It is also, annoyingly, the exact right length for a product demo that people actually watch.

Limit two, no audio editing. In the free YouTube route you cannot go back and change the sound afterwards. You get what it gives you.

Limit three, the watermark. Every clip carries something called SynthID, which marks it as AI generated. It is largely invisible to the eye but it is detectable, and it is not removable.

That last one matters and I want to be straight about it.

If you are making a demo clip of your own product, a watermark is completely fine.

If you were planning to pass AI video off as real footage of real people, this is not your tool, and honestly, I am glad.

2. Now let’s make your first clip.

Right. Phone in hand.

I am going to assume you have never opened a video tool in your life, because most of the people I teach have not.

Step 1: Open the YouTube app on your phone. Not the browser. The actual app.

Step 2: Look at the bottom of the screen. See the + in the middle of the row? Tap it.

Step 3: A menu slides up from the bottom. Tap Create a Short.

Step 4: You are now on the recording screen. Do not record anything. Look at the row of tools instead, and find the AI video option.

(Google is still moving these buttons around, so if it is not where I say, look for anything with a sparkle icon. That is always the AI one. It is a universal law at this point.)

Step 5: Tap it. A text box appears asking what you want to see.

Step 6: Now type what you want. And here is where most people go wrong, so read this bit twice.

Do not write “a video about my app.”

That is not a description. That is a category.

Write what the camera can literally see.

Here is the shape that works:

[what is on screen] + [how the camera moves] + [what the light is like] + [the mood]

So instead of “a video about my task app,” you write:

“A close shot of a phone on a wooden desk, morning light, a to do list app open on the screen with items ticking off one by one, the camera slowly pushes in.”

Same idea. Wildly different result.

Step 7: Tap generate, and wait. It takes a moment. Do not tap it four more times (I did, and got four videos, and deserved it).

3. The bit that makes this different: talk to it.

Every other video tool works like a vending machine.

You put a prompt in, something falls out, and if you do not like it you start again from nothing.

Omni Flash does not work like that, and this is the actual news.

You look at what it made, and you tell it what to change.

Step 1: Look at your clip properly. Find the one thing that bothers you most. Just one.

Step 2: Say it, in normal words, the way you would say it to a person.

Things that work:

“Make the lighting warmer.”

“Slow the camera down.”

“Same shot, but at night.”

“Keep everything, just change the desk to a kitchen counter.”

Step 3: Send it, and watch what happens.

The important part is what it does not do.

It does not throw your clip away and roll the dice again.

It keeps the scene, keeps the light, keeps the look, and changes the one thing you asked for.

(This is the difference between a slot machine and an assistant, and it is the reason this model matters more than the last five that launched.)

Step 4: Do it again. And again. Stack the changes up until it is what you pictured.

If this is the first time AI video has felt useful rather than impressive, send it to one person who felt the same way.

Share

4. Four descriptions that work, and why.

I have made a lot of bad clips this month so that you can skip that part.

Here are four descriptions that reliably produce something usable, with the reason each one works underneath it.

Steal the shape, swap in your own product.

The over the shoulder.

“Over the shoulder view of someone at a laptop in a bright kitchen, a simple app open on the screen, they click once and the screen updates, camera stays still.”

This works because a person is in it. Not a face, just a shoulder and a hand, which is enough for a brain to identify with and not enough to look uncanny.

The desk push in.

“A phone lying on a dark desk beside a coffee cup, screen glowing, an app open showing a list, the camera slowly pushes in towards the screen, warm evening light from the left.”

This works because slow forward motion reads as important. It is the oldest trick in film and it still works on a ten second clip.

The before and after.

“A cluttered desk covered in sticky notes and paper, the camera pans right to reveal a clean desk with a single phone on it, soft daylight, calm mood.”

This works because it tells a whole story with no words at all. Your product is the thing that happened between the two halves.

The abstract.

“Close macro shot of soft violet and cream shapes flowing and reassembling into a neat grid, pale background, gentle movement, no text.”

This works when your product is genuinely hard to show. It buys you attention without pretending to be a demo.

(Notice that not one of these mentions AI, software, technology, or the future. Describe a room, not a concept. The model is very good at rooms and very bad at concepts.)

5. Getting the clip out so you can actually use it.

A video trapped inside YouTube’s creation screen is not much use to you.

You want the file, so you can put it on your landing page, or in an email, or on the other five platforms.

(No landing page yet? That is Sunday’s article, and the older step by step guides live at prompts2products.com.)

Step 1: Before you post anything, look for the download or save option on the finished clip. Save it to your phone.

Step 2: Check your phone’s photo library. It should be sitting there as a normal video file.

Step 3: Send it to yourself. Email, cloud drive, whatever you use. Now it exists somewhere that is not one app.

Step 4: Only now, if you want to, post it as a Short.

That order matters. Save first, post second.

(I have lost a clip I liked by posting it and assuming it saved. It did not. I was very calm about it and definitely did not say anything out loud.)

Where this falls short (being honest).

I would rather you hear the limits from me than find them at eleven at night.

Ten seconds is ten seconds. You are not making a two minute explainer here. You are making one moment. Plan for that and it is a strength, fight it and you will be miserable.

It does not know your product. It has never seen your app. It is making something that looks like your app’s world, not a recording of your actual screens. For real screens, you still record your real screens.

The free route is a phone route. This lives in the YouTube app. If you were hoping to do it all from your laptop, that is the paid door.

Watermarked, always. SynthID goes on everything and does not come off. For product demos this is a non issue. For anything pretending to be real, it should be a full stop.

Google will move the buttons.

They always do.

If a tap in this article does not match your screen, look for the sparkle icon and you will find it.

The free door might close.

I want to be straight with you about this rather than pretend otherwise.

Free access inside YouTube is a decision Google made to get this model in front of a lot of people quickly, and decisions like that get revisited.

It is free today, which is why I am telling you today rather than saving it for a nicer week.

Go and make something with it while the door is open.

Nobody sent me a free account for this.

Google does not know I exist.

I chased this down because I was irritated by a blue Paid badge, and I thought you might be irritated by it too.

There is a version of this newsletter where I only write about the paid tools, because the paid tools are easier to write about and nobody argues with you.

I would rather write the version where I go and check whether you actually need to pay, and then tell you when you do not.

That is most of what I think this job is.

If it saved you from paying for a video tool this month, that is the whole job done.

The nicest thing you can do costs nothing: send this to one person who has been putting off making a demo.

Share

And if someone forwarded this to you, go and thank them, then subscribe so the next one turns up on its own.

Subscribe now

Save this. The five things that matter.

1. Omni Flash is Paid in Google AI Studio and free in the YouTube app. Same model.

2. Free route: YouTube app, tap +, Create a Short, find the sparkle icon.

3. Describe a picture, not a topic. What is on screen, how the camera moves, what the light is like.

4. Then talk to it. “Warmer.” “Slower.” “At night.” It keeps the scene and changes one thing.

5. Save the file to your phone BEFORE you post it. Learn from my bad evening.

PS: on Thursday I am taking the one clip you just made and turning it into a whole week of posts, without making anything new. Bring the clip.

People still send it to me.

I have not opened Lovable properly in months.

That is not a tantrum, and it is not a hot take for the sake of it.

It is a number I read on my own screen, and once I saw it I could not unsee it.

New here? Subscribe so the next build lands in your inbox. It is free.

Today I am going to show you that number, explain exactly what it means, and then walk you out.

It goes like this:

1. You find the one page in Lovable that tells you what your app really cost (most people have never opened it)

2. You learn what a credit actually pays for (it is three things, not one)

3. You take a full copy of your code out in two clicks

4. You open that copy somewhere fixing is free

5. You plug your data back in and run it once, to prove nothing broke

I will show you every step, with screenshots.

But first, here is what made me write this.

Two things before we start:

1. Save this, then block twenty minutes today and actually do step one.

2. Send it to one founder who is about to top up their credits again.

Sharing is free, and it is how this newsletter grows.

Share

Before anything, I want to be fair to Lovable.

I liked Lovable.

I still think it is the best first hour in this entire category.

You type a sentence, and a working screen appears next to you.

For someone who has never built software, that moment is genuinely magic, and I have watched it change what people believe they are capable of.

I wrote a whole article about it, and I meant every word of it at the time.

Here is the part I did not understand then.

I have been building software for seven years.

I am an architect by training, which means my actual job is worrying about what a system costs to keep alive, not what it costs to start.

And I applied that thinking to every client project I have ever run, and somehow never applied it to my own vibe coded apps.

Everything I build, and everything I break, lives at prompts2products.com

So one evening in June I opened the settings page on a project I had shipped, expecting nothing.

1. Go and read your own bill first.

Do not take my word for any of this.

Go and look at your own number, because yours is the only one that will actually change your mind.

This page is buried, and I think that is a little bit on purpose (or a little bit on accident, which is somehow worse).

Step 1: Open Lovable and click into any project you have actually worked on for more than an afternoon.

Step 2: Look at the very top left, at your project name. See the small arrow next to it? Click it.

Step 3: A menu drops down. Click “Settings.”

Step 4: In the left sidebar that appears, make sure “General” is selected. It usually is by default.

Step 5: Now look at the box called “Project details” and read the last two rows.

They are called “Messages count” and “AI edits count.”

That is it. That is the whole bill.

Mine said 482.

Four hundred and eighty two times I typed something into that box and pressed enter.

And 312 of those turned into an edit to my code.

Now here is the maths that ruined my evening.

On Lovable, one message is roughly one credit.

If you run out and buy more, top up credits cost twenty cents each.

So four hundred and eighty two messages, priced at the top up rate, is somewhere around ninety six dollars.

For one app.

That nobody is currently using…

If your number is worse than mine, I would love to hear it. Reply and tell me. Misery loves a comment section.

Leave a comment

2. What a credit actually buys (this is the bit nobody reads).

Here is where I stopped being annoyed and started being genuinely uncomfortable.

I went to Lovable’s own pricing page and opened the little question that says “What is a credit?”

I am going to quote their answer, because it is their words and it is completely honest.

Credits let you build apps, run deployed apps, and power AI features, all from one balance.

Read that again slowly.

One balance.

Three completely different jobs.

Let me translate that into plain English, because the words are small but the meaning is enormous.

The same pot of money pays for you building your app.

It also pays for your app being used once it is live.

And it also pays for any AI feature inside your app when a real customer touches it.

So if your thing takes off, your bill goes up.

That is normal. Every cloud service works that way, and there is nothing sneaky about it.

But here is the part that is genuinely strange.

Your success and your mistakes are being drawn from the same wallet.

Which means a bad week of debugging and a great week of new signups look identical to your balance.

3. You are not paying to build. You are paying to fix.

Now put those two facts together, because this is the actual argument.

Out of my 482 messages, the vast majority were not me asking for new things.

They were me saying some version of “no, not like that.”

Move it left. No, the other left. That broke the other page. Put it back. Why is the button gone.

If you have built anything real this way, you know exactly the loop I mean.

And every single one of those corrections costs the same as the thing I originally asked for.

Think about how odd that is for a second.

The AI misunderstood me.

The AI wrote the wrong thing.

And then I paid, at full price, to have the AI fix the AI.

I want to be careful here, because there is a fair counter argument and I should say it out loud.

A lot of that correction loop is my fault, not the tool’s.

Vague asks make vague apps.

If I had written sharper instructions, I would have burned fewer messages, and that is true of every AI tool on earth.

But here is the thing I keep coming back to.

The tool charges me for my learning curve.

And that quietly teaches you the worst possible habit, which is to hesitate before you experiment.

You start batching your requests. You start not trying the weird idea. You start leaving the ugly bit ugly, because fixing it costs actual money.

That is the moment the tool stopped being fun for me.

Not when it got expensive.

When it made me cautious.

So that is the case.

Now here is the part you actually came for.

Below this line, I am going to walk you out, click by click, in about twenty minutes.

Nothing gets deleted. Nothing breaks. And you can walk straight back in if you decide I am wrong.

Here is exactly how I did it, starting now.

4. Take your code out. It takes two clicks.

Good news first, and I want to give Lovable real credit for this.

They do not hold your code hostage.

A lot of builders in this category do. Lovable does not, and that is genuinely to their credit, so let us use the door they left open.

You have two ways out, and I will show you both. Pick one.

Step 1: Open the project you want to take with you.

Step 2: Click the small arrow next to your project name, top left.

Step 3: Click “Settings.”

Step 4: In the left sidebar, click “Git.” (it sits right under “General,” you cannot miss it)

Step 5: Look at the page. There are exactly two options on it.

Here is how to choose between them, in one line each.

Option A, Download codebase. You get a ZIP file of your entire project. One time, no accounts, nothing to connect. Your Lovable project carries on exactly as it is and does not know you did it.

Option B, GitHub sync. Your project gets connected to a GitHub repository and the two stay in step, both directions. Better long term. Slightly more setup, and you need a GitHub account.

If you have never used GitHub, take Option A today.

Seriously. Take the ZIP.

You can always do the GitHub thing next week, and I would rather you finish this article with a folder on your desktop than a half finished account somewhere.

Step 6: Click “Download.”

Step 7: Your browser downloads a ZIP file. Find it in your Downloads folder and double click it to unzip.

Step 8: You now have a folder. Open it and look inside.

You will see folders called src, and public, and a file called package.json.

That is a completely normal web app.

Not a Lovable thing. Not a magic locked format. A normal, boring, standard React project that any developer on earth could open.

5. Open the copy somewhere fixing is free.

Now the folder is on your computer, and it is doing nothing.

We are going to give it somewhere to live where corrections do not cost you anything extra.

I use Claude Code for this. I have written about it before, so I am not going to re-teach the whole thing, just the part that matters today. (Read it here)

I am also going to be straight with you about the money, because this article would be dishonest otherwise.

Claude Code is not free.

You need a paid Claude plan, and the cheapest one that includes it is twenty dollars a month.

So this is not “escape to free.”

This is escape to a flat number instead of a metered one.

That distinction is the entire point, and it is worth one more diagram.

Here is how you open your folder.

Step 1: Open Claude Code. (if you use the desktop app, it is the same thing, just prettier)

Step 2: Point it at the folder you just unzipped. In the desktop app you pick the folder. In the terminal you navigate into the folder first, then start Claude Code there.

Step 3: Wait for it to say it is ready.

Step 4: Now, before you ask it to change a single thing, ask it to understand the thing.

PS: if you don’t have claude desktop app, download it from here.

This is the one prompt in this whole article, and it earns its place, because it saves you from an hour of the AI guessing.

Paste this in:

You are helping me take over a web app I built with an AI builder and exported.
My goal: understand what is actually in this project before I change anything.

Here is what I am working with:
1. A React project I exported as a ZIP. I did not write this code by hand.
2. I am the founder, not the engineer. Explain things plainly.

Before you start, ask me 3 quick questions about what the app is meant to do.
Then give me a short written tour: what each main folder is for, which file
controls each screen, and where the app connects to a database or an outside service.

Keep everything in plain language. Explain anything technical clearly enough that a
beginner could follow, without dumbing it down.
Do NOT change, add, or delete any files yet.
Start by listing the top level folders.

Read what it gives you back.

That tour is the thing you have never had before, and it is genuinely the moment the app stops feeling like a black box you rent and starts feeling like something you own.

6. Plug your data back in.

Here is the trap, and I want you to see it before you fall in it.

The ZIP contains your code.

It does not contain your database.

Your users, your saved records, your uploads, all of that lives in a database somewhere else and it stayed exactly where it was.

That is actually good news, because it means nothing was lost.

But it does mean your copy will start up looking empty until you reconnect it.

Most Lovable apps that store anything are using Supabase underneath. If yours is, this takes about four minutes.

Step 1: Go to supabase.com and sign in to the account your app already uses.

(Click here to learn more about this Supabase setup)

Step 2: Click into your project.

Step 3: In the left sidebar, go to Project Settings, then find the section with your API details. You are looking for two things: your Project URL and your anon public key.

Step 4: Copy them somewhere safe for a second.

Step 5: Go back to your exported folder. Look for a file whose name starts with .env. If there is not one, make a new file and call it .env.

Step 6: Paste your URL and key into that file, using the same names the code is already looking for. (if you are not sure what those names are, ask Claude Code “what environment variable names does this project expect” and it will tell you exactly)

Step 7: Save the file.

7. Run it once, and then break something on purpose.

Step 1: In Claude Code, ask it to start the app. Say exactly that, in those words. It will work out the command.

Step 2: It will give you a local address, something like localhost:5173. Open that in your browser.

Step 3: Look at your app.

It should be identical. Same screens, same colors, same everything.

If it is, you are done with the hard part.

Now do the thing I want you to actually feel.

Step 4: Pick something small and slightly wrong in your app. A label, a spacing, a color you never liked.

Step 5: Ask Claude Code to fix it.

Step 6: Do not like the fix? Ask again. And again. And a fourth time, just because you can.

Nothing is counting.

That is the whole feeling I am trying to hand you today.

Not a cheaper tool. A quieter head.

I know “come join my Discord” is exactly the kind of line you have learned to scroll straight past. Completely fair.

But this one step, the first time your exported app runs on your own machine, is where people get stuck most, and it is nearly impossible to debug alone at eleven at night.

So the door is open and it costs nothing. Come sit in the Prompts2Products Discord, bring the half migrated project, and we will get it running together.

8. The three places this goes wrong (and the fix for each).

I have now done this with several projects, and it has gone sideways in exactly three ways.

It starts up completely blank, white screen, nothing.

Nine times out of ten this is the .env file.

Either it is named wrong, or it is in the wrong folder, or the variable names do not match what the code expects.

Ask Claude Code to read the project and tell you exactly what it is looking for, then match it letter for letter.

It runs, but everything is empty.

Your code found the database but is not allowed to read from it.

This is a permissions setting on the database side, not a code problem. Go into Supabase and check the access rules on your tables.

It will not start at all, and there is a wall of red text.

Do not read the red text.

Copy all of it, paste it into Claude Code, and say “explain this in plain English and fix it.” That is genuinely the whole technique, and it works nearly every time.

Where this falls short (being honest).

I would be selling you something if I stopped here, so let me tell you what I am not showing you.

Lovable is still faster for hour one. If you are starting a brand new idea from nothing this afternoon, Lovable will get you to a working screen quicker than anything I have described. That is not close. Use it.

Claude Code costs money too. Twenty dollars a month minimum. I am not moving you from paid to free. I am moving you from a bill that surprises you to a bill that does not.

You have to be slightly comfortable with a folder. Not with code. With a folder. If the words “unzip this and open it” made you tense, do this one with someone.

The ZIP does not take your database. I said it above and I will say it again, because it is the single thing people panic about. Your data is safe, it is just somewhere else, and you have to introduce them again.

Two way sync cuts both ways. If you go the GitHub route and then keep editing in Lovable too, you can absolutely get yourself into a mess. Pick one place to work. Live there.

Nobody paid me to argue with my own article.

Lovable did not do anything to me.

They did not wrong me, they did not change the deal, and they did not hide anything, because I found every single fact in this article on their own public pages.

I just outgrew the shape of it, and it took me four hundred and eighty two messages to notice.

If this saved you from finding that out at message eight hundred, then it did its job.

The nicest thing you can do for me costs nothing at all: send this to one person who is about to buy another pack of credits.

Share

And if a stranger forwarded you this one, go and thank them, then subscribe so the next one finds you on its own.

Subscribe now

Save this. The five things that matter.

1. Your real bill lives in Settings, then General. Two rows. Go and read it.

2. One credit balance pays for building, running, and the AI inside your live app.

3. Corrections cost exactly the same as creations. That is what drains you.

4. Settings, then Git, then Download. Your code comes out as a normal folder.

5. The ZIP is your code, not your data. Reconnect your database and nothing is lost.

PS: I am going to keep the Lovable article up, unedited, with all its December optimism intact. Changing your mind in public is the job. Quietly deleting the evidence is not.

PPS: if you get stuck halfway through the export, do not sit there alone with it. Everything else I have written on building this way is at prompts2products.com.

Not a question you ask an AI.

A whole job.

New here? Subscribe so the next build lands in your inbox. It is free.

Here is what almost nobody does with Claude, including people who use it every single day.

They open it.

They type.

They wait.

They close the tab, and everything stops.

Which means the work only ever happens when you personally show up and start it.

Today we are building the version where you do not show up at all.

It goes like this:

1. You pick one job you already do every week (the boring one, not the fun one)

2. You go to claude.ai and open the Routines page

3. You type the job into one box, in plain English, like you are texting a colleague

4. It drafts the whole thing for you. Name, instructions, schedule

5. You check the connectors, and this is the step that actually matters (section 5, do not skip it)

6. You click Create, then Run now once while you are watching

7. You close the laptop

8. From then on it starts itself at 7am, in the cloud, and leaves the work waiting for you

I will show you every step, with screenshots from the real thing.

But first, here is what it looks like once it is running.

Two things before we start:

1. Save this, then block fifteen minutes and actually build one.

2. Send it to one founder who keeps saying they will get to it on the weekend.

Sharing is free, and it is how this newsletter grows.

Share

The 7am problem I stopped trying to fix by hand.

I am an engineer.

I have written cron jobs. I have left a machine awake overnight for a task that took ninety seconds.

So when I built my own weekly content system, I did the sensible thing.

I wrote the instructions down properly, as files, so Claude could pick up the whole job.

No re-explaining it every Monday.

And it worked.

Except for one small human problem.

I still had to open the laptop and start it.

Every Monday the system sat there, perfectly written, doing nothing, waiting for me to click.

Some Mondays I was on a call at 7am.

Some Mondays I just did not feel like it (I am allowed, and so are you).

The instructions were never the bottleneck. I was.

Before we build one, you should know there are three different things people call “scheduling Claude,” and picking the wrong one is how this goes sideways.

1. So what actually is a routine?!

A routine is a job you write down once, plus a clock that starts it.

That is it. That is the whole idea.

You are used to a chat where you type and Claude answers.

A routine is a session that starts itself, reads your instructions, does the work, and leaves the result behind for you to find.

Nobody is sitting there to answer its questions (so it must not have any, which is section 4).

There are two flavors, and in the app they are called Cloud and Local.

Cloud runs on Anthropic’s machines. Your laptop can be shut in a bag on a train. The shortest gap between runs is one hour, and it starts fresh each time rather than looking at your desktop folders.

Local runs on your own computer. It can open your real folders and save into them, but it only fires while the app is open and the machine is awake. Closing the lid stops it.

We are doing Cloud, because “it works even when my laptop is off” is the entire reason you are reading this.

Here are the boxes you are about to fill in. There are four that matter.

Let me get you to the right screen, because it takes about eight seconds and it makes all of this feel real.

Step 1: Open a browser and go to claude.ai.

Step 2: Open Claude Code, and look for “Routines.”

(Or go straight there with claude.ai/code/routines, which is what I do.)

Step 3: Look at the box that says “What do you want automated?”

Step 4: Do not type anything yet. Just look at it.

Underneath it you will see templates: Briefing, Email triage, System health check, Issue triage, PR review digest, Dependency update check, Release notes drafter, Flaky test tracker.

Half of those are for engineering teams and you can ignore them.

But read the first two properly. “Briefing: summary of your calendar, emails, and messages.” “Email triage: categorize and prioritize your inbox, with draft responses for urgent items.”

Briefing and Email triage are somebody's Monday morning, not an engineering task.

Here is exactly how I built mine, box by box, including the part where the app did something I did not expect.

2. Pick the one job first, because this is where people choose wrong.

Everyone’s instinct is to automate the fun job.

The creative one. The one with the interesting output.

Do not.

The fun job is the one you actually want to be present for, and you will rewrite whatever it produced (ask me how I know).

Automate the boring one that happens on a clock.

The one with a clear ask, a clear output, and no taste involved.

Notice what they have in common.

Each one has a clear number attached. Three ideas. One page.

Each one ends with something written down that you can read later.

None of them needs your opinion halfway through.

That last one is the real filter. If the job needs you to make a judgment call in the middle, it is not ready to run alone at 7am.

3. Now let’s build it together, click by click.

We are building the morning brief, because it is the one I actually wanted.

Step 1: Click into the box that says “What do you want automated?”

Step 2: Type the whole job, in normal words. Here is exactly what I typed:

Every weekday at 7am, write me a short morning brief. Give me three ideas
worth writing about this week for non-technical founders who build with AI.
For each one: a one line hook, three bullets of substance, and one sentence
on who it is for. Keep the language plain and spoken. If you have nothing
solid to work from, say so in one line instead of inventing things. Do not
ask me any questions.

Read that back and notice there is nothing clever in it.

No special formatting. No magic words. I said the time, the job, the shape of the answer, and what to do if the week is thin.

Step 3: Click “Draft routine,” on the right.

Step 4: Wait about ten seconds. Do not click anything else.

And now the part I liked.

It does not just save what you typed. It turns it into a proper routine, and it fills in every field for you.

It named it “Morning brief.” It rewrote my paragraph into five numbered instructions. It read “every weekday at 7am” and set the trigger to Runs weekdays at 7:00 AM.

Step 5: Read the instructions it wrote and check they say what you meant.

Mine came out as five steps. Identify three ideas, give each one a hook and three bullets and who it is for, keep the language plain, say so if there are not three solid ideas, and do not ask follow-up questions.

That is my paragraph, tidied. Which is what I wanted.

Step 6: Look at the model picker, sitting in the bottom right of the instructions box.

Mine says Opus 5. Leave it unless you have a reason.

Step 7: See the field that says “Select a repository”?

Leave it empty.

(This is the bit that scared me off routines for a month. I assumed a repository was required, because everything written about this feature is aimed at engineers. It is not required. If your job is writing rather than code, skip it entirely.)

Step 8: Look at the trigger. Mine says Runs weekdays at 7:00 AM EDT.

If yours is wrong, click it and change it. There is also “Add another trigger,” which is how one routine can run on a clock and also fire when something calls it.

Do not add a second trigger today.

Now stop, because the next screen is the one people skim and should not.

4. Write the instructions like nobody is coming to help.

Before we go near the Create button, one section on wording, because it decides whether this thing is useful or just something you built once.

Here is the difference between a normal chat and a routine.

In a chat, if Claude is unsure, it asks you, you answer, everyone is happy.

In a routine at 7am, if it is unsure, there is nobody there.

So it either guesses, or it produces something thin, and neither is what you wanted.

Your instructions need four things a normal prompt does not bother with.

A number. Three ideas. Not “some.” Not “a few.”

A shape for the output. A hook, three bullets, one sentence on who it is for. So every run looks the same and you can read it fast.

A rule for a thin week. Tell it exactly what to do when there is not enough to work with, so it writes you one honest line instead of padding.

Permission to not ask. Say “do not ask me any questions” out loud. It removes the failure mode where a run sits waiting for a human.

If your drafted instructions are missing any of those four, click into the box and add them now, before you create it.

It is much easier to fix wording here than to work out later why every brief reads like mush.

5. The screen everyone skims. Read this one slowly.

Look at the bottom of that draft screen again.

Under a tab called Connectors, there were four things attached to my routine that I never asked for.

Expedia. Google Drive. Lovable. And visualize.

And underneath them, in orange, this:

Claude can use all tools from these connectors, including writes, without asking for permission during runs. Remove any you don’t want the agent to access.

Read that twice.

Including writes. Without asking for permission.

My routine writes three content ideas. It has no business touching a travel booking tool at 7am while I am asleep.

So here is what to do, and there is a catch coming.

Step 1: On the draft screen, find the Connectors tab.

Step 2: Look at what is attached. It will be whatever you have connected to your Claude account.

Step 3: Click the small x next to every single one your job does not need.

Step 4: For a writing job like this, remove all of them. It does not need a connector to think.

Step 5: Check the orange warning has disappeared. That is how you know the list is empty.

Step 6: Click Create.

Now here is the catch, and it is the reason this section exists.

I removed them. It created the routine with them attached anyway.

I do not know whether that is a bug or a draft that got saved before my clicks landed. Either way, the fix is the same and it takes twenty seconds.

Step 7: On the routine’s page, click the pencil icon at the top right to edit it.

Step 8: Scroll to Connectors. They will be sitting there.

Step 9: Remove each one again, with the x.

Step 10: Click Save.

Step 11: Look at the routine page again and confirm the Connectors row is gone entirely.

The lesson is small and it applies to every unattended thing you will ever set up.

After you save, reopen it and check what you changed actually changed.

The tool is not bad.

But nobody is watching at 7am, and an unattended job with more access than it needs is the kind of mistake that stays quiet.

6. Run it once with your eyes open.

Do not go to bed yet.

There is one step between “I built it” and “it works while I sleep.”

Step 1: On the routine page, click “Run now,” top right.

Step 2: A message appears saying the run started, and a row appears under Runs, tagged MANUAL.

Step 3: Wait. A cloud session takes a few minutes, and it will sit there spinning while it works.

(Mine was still going when I got bored and went to write this section. That is normal. It is not stuck.)

Step 4: When it finishes, click the run to open it and read what it actually did.

Step 5: Read it like a colleague’s work, not a demo. Where did it hesitate? What did it assume?

The Runs list also has tabs for All, Scheduled, Manual, API and Webhook.

The clock is only one way in. The same routine can be started by something calling it, which is how people wire these to alerts. Not today.

7. The Friday loop that keeps this worth having.

A routine is not something you set up and forget.

Well. It is, and that is the point.

But the good ones get ten minutes once a week.

That is what separates the routine you still use in November from the one you delete.

Here is my Friday loop, and it takes about as long as making tea.

Step 1: Open the routine and read the Runs list top to bottom. Look for anything that failed or took much longer than usual.

Step 2: Open the two most recent results and read them properly.

Step 3: Find the one sentence in the instructions that caused the weakest part.

Step 4: Rewrite only that sentence.

Step 5: Click Run now to check the fix, then let it go back to sleep.

One sentence a week. After a month, it is properly tuned to how you work.

Two small powers worth knowing while you are in there.

The Status toggle pauses it instead of deleting it, which is what you want before a holiday.

And the trash icon deletes it outright, which is what you want when you built one to try it and never used it again (no shame, I have done this three times).

One more thing, and it connects to Tuesday.

Your instructions are just text with a small header on top. A name, a description, and the body telling it what to do.

If that shape sounds familiar, it is because it is the same shape as a skill.

(Tuesday's piece and this one are closer than I realized.)

Here is where I will say the quiet part, since you paid to be in here.

Everything above is a job small enough for one person and one box, and you can absolutely run it yourself.

Some jobs are not that. Some need a system your clients touch, with real accounts, a database, and someone responsible when it breaks at 3am.

A 7am brief writer will never get you there, and I would rather say that plainly than sell you a workaround.

That is the sort of thing my team at Arehsoft builds, and if it is where you are, book a free call with me and we will work out what it would take.

Where this falls short (being honest).

It is a research preview. Behavior, limits and screens can change. Do not put anything load bearing on it this month.

It runs with nobody approving anything. No permission prompts mid-run, by design. That is the power and it is also the risk, which is the whole of section 5.

The connector list did not stay cleared the first time. I had to remove them twice. Until that is fixed, treat “I removed it” as a claim to verify rather than a fact.

It cannot see your own files. A cloud routine starts fresh. If the job needs to read a folder on your desktop, you want the Local kind instead, and then your laptop has to stay awake.

One hour is the floor. If you need something every five minutes, this is the wrong tool and you want a real script.

The runs use your allowance. These are real sessions. A heavy job running hourly all day will eat into your limits the same way you would.

It will not fix a vague job. If you cannot describe the work in a few plain steps, a clock does not help. It just does the vague thing on time.

The 7am version of me was never coming.

Nobody paid me to write this. Anthropic has no idea I exist.

I write about what I actually put into my own week, and this one replaced a habit I had failed to keep for about a year.

The AI did not get smarter. It just stopped needing me to be awake and motivated at the same moment.

If this saved you a morning, the kindest thing you can do costs nothing. Pass it to one person who keeps saying they will get to it on the weekend.

Share

And if a stranger forwarded you this one, go on and thank them. Then subscribe, so the next build finds you on its own.

Subscribe now

Save this.

One job, the boring one you already do every week.

Type the whole thing into one box. It drafts the name, the steps and the schedule for you.

Give it a number and a shape for the output.

Add a rule for what to do on a thin week, and tell it not to ask you anything.

Strip every connector the job does not need. It can write, and nobody will ask you first.

Save, then reopen it and check the connectors actually went.

PS: Mine is called “Morning brief” and it fires tomorrow at 7am whether I am ready or not. If you build one, reply and tell me what job you handed over. The boring ones are my favorite.

Not a Claude thing. Not a Cursor thing.

One folder, and any app that speaks the standard picks it up and knows what to do with it. It takes about ten minutes and it costs nothing.

New here? Subscribe so the next build lands in your inbox. It is free.

It goes like this:

1. Understand the actual problem (your instructions are trapped in one app)

2. Make one folder on your computer

3. Put a two line file in it called plugin.json

4. Drop your existing skill inside the skills folder

5. Add your tools too, if you have any

6. Hand the whole folder to someone else and watch it just work

I will show you every step. But first, here is the thing you are building:

And here is who already reads that folder, checked this morning:

Two things before we start:

1. Save this, then block ten minutes and actually build the folder.

2. Send it to one person who keeps re-explaining themselves to AI every morning.

Sharing is free, and it is how this newsletter grows.

Share

Why this one annoyed me enough to write about it

I have been a software architect and full-stack engineer for over seven years, and I have written the same instructions more times than I want to admit.

Not different instructions. The same ones.

Once for Claude, then again for the coding tool, then again in a slightly different folder shape because that tool wanted it laid out its own way.

Every copy drifted.

I would fix a mistake in one and forget the other two, and three months later I could not tell you which copy was the good one.

This is exactly the article I wish someone had handed me back in January when I wrote about skills for the first time, which is roughly the moment I started making three copies of everything, and it is the kind of small structural fix the Thursday and Sunday pieces go much deeper on.

Then on the sixth of August, this got fixed.

A group of companies who normally compete published one shared shape for it.

Amazon, Cursor, Microsoft, OpenAI and Vercel maintain the standard, and Google joined them as a maintainer the same day.

That almost never happens.

When rivals agree on a file layout, it is because every single one of them was sick of the same problem.

1. First, what a plugin actually is.

Forget the word.

A plugin is a folder.

That is not me simplifying for you. That is the literal definition in the spec, and the fact that they kept it that boring is the best thing about it.

Inside the folder there are three things that matter, and you will not need all three today.

plugin.json. A tiny text file that says “this is a plugin, and here is its name.” Two lines of real content.

A skills folder. Your written instructions. If you have ever written a SKILL.md file, you already have this part done.

mcp.json. Only if your plugin needs to reach out and touch something, like a database or an app you use. Skip it entirely if you are just packaging instructions.

Here is the important bit, and it is the reason this works at all.

The locations are fixed.

You cannot put your skills somewhere clever and then tell the app where you hid them.

Skills go in skills/.

Tools get declared in mcp.json.

Always, in every plugin, in every app. (This sounds like a limitation. It is the entire feature. Fixed locations mean nobody has to guess, which means nobody has to write a special version for each app.)

One more thing worth knowing before you build.

If one piece breaks, the rest still loads.

If your tool config fails to start, the app skips it, loads your instructions anyway, and tells you what went wrong.

(Anyone who has watched one broken line take down an entire config file will understand why I care about this so much.)

2. Now build one, and yes it really takes a minute.

We are going to make the smallest real plugin that exists.

It does one silly thing.

That is on purpose, because once the shape is in your hands, the useful version is just typing.

Step 1: On your computer, make a new folder. Put it somewhere you will find again, like Documents. Name it my-first-plugin.

Step 2: Open that folder. Make a new plain text file inside it. Name it exactly plugin.json.

(Watch the file extension. If your Mac saved it as plugin.json.txt, rename it. This trips up almost everyone once, including me.)

Step 3: Open plugin.json and put this inside it:

Step 4: Save it and close it. That is the whole manifest. There is nothing else to fill in.

(I stared at it for a while, waiting for more fields to appear. There are none.)

Step 5: Back in my-first-plugin, make a new folder called exactly skills.

Step 6: Inside skills, make another folder called greet.

Step 7: Inside greet, make a plain text file called exactly SKILL.md, and put this in it:

Step 8: Save it. You are done.

That folder is now a valid plugin, and every app in that list further up understands it. Read that again, because that is the part that is new. Six months ago the same folder only meant something to one company’s app.

Know someone who has rewritten the same AI instructions five times this month? Send this over.

Share

3. Add your tools, if you have any.

Skip this whole section if your plugin is just instructions. It will still work perfectly.

Read on if your plugin needs to actually reach something, like your calendar, your notes, or a service you already pay for.

Those connections are called MCP servers. You have probably used one already without knowing it had a name.

They go in a file called mcp.json, sitting right next to plugin.json, and there is one rule that matters.

Old setups let the app work out the connection type from the shape of your config, which failed in quiet, maddening ways.

Now you say it plainly, and it either works or it tells you why not.

And here is the honest advice the spec authors give themselves, which I appreciated.

Do not reach for a plugin if you do not need one. One skill on its own does not need a plugin. One tool connection on its own does not need one either.

A plugin earns its place when you have pieces that belong together and need to travel together.

(A company telling you when NOT to use their new thing is rarer than the new thing.)

Where this falls short (being honest).

Claude and Antigravity do not read it yet. Seven clients do, and that list is genuinely impressive for something four days old, but the two tools I use most are not on it. If you build a plugin and Claude ignores the folder, the folder is not broken. Check the live list on the day you try, because it is moving fast.

There is no install button. Version one is only the box, not the delivery van. No app store, no one-click install, no update mechanism. Right now you move the folder yourself. The authors say this out loud rather than hiding it, which I respect, but it does mean sharing a plugin today is still “here, take this folder.”

Nothing checks whether a plugin is safe. No permissions model, no sandbox, no way to verify who wrote it.

It will not fix bad instructions. A portable copy of a vague instruction is a vague instruction that now travels further. The folder shape is the easy part. Writing instructions clear enough that an agent gets it right first time is still the actual work, and it always will be.

I did not expect to write about a folder layout.

Nobody paid me for this. None of these companies know I exist.

I wrote it because the fix here is unglamorous and small, and unglamorous small fixes are the ones that quietly give you your Mondays back. The exciting announcements rarely change how my week runs. This one did, and it did it by deleting work rather than adding a tool.

And the nicest thing you can do for me costs nothing. Send this to one person who is on their fourth copy of the same instructions and does not know they can stop. This newsletter grows one forward at a time.

Share

If someone forwarded you this one, thank them, then subscribe so the next one finds you too.

Subscribe now

Save this. The whole thing in six lines.

1. A plugin is a folder. That is not a simplification, it is the definition.

2. plugin.json is two lines. A schema line and a name. Nothing else.

3. Instructions live in skills/, one folder each, with a SKILL.md inside.

4. Tools live in mcp.json, beside plugin.json, and every entry states its type.

5. Fixed locations are the feature. You cannot get clever, and that is exactly why it travels.

6. One skill on its own does not need a plugin. Pieces that travel together do.

PS: If you build one, reply and tell me what your first skill was. Mine greeted me by the wrong name for two days because I typed the description badly. Small mistake, easy fix, still funny.

You explain who you are.

You explain how you write.

You paste the same three things you pasted yesterday.

Today we end that, with one folder and four folders inside it.

If this is your kind of thing, hit subscribe. It is free.

It goes like this:

1. Make one folder called cowork, with four inside it (this takes ninety seconds)

2. Fill about-me/ first, with three prompts that interview you

3. Drop one thing into reference/

4. Build one template/ for something you write every week

5. Write your standing orders once, so you stop repeating yourself

6. Connect the folder and hand Claude a real job

7. Pick how closely it checks with you before it acts

8. Make it a project, so it remembers

9. Type /schedule and stop doing the job by hand

I’ll show you every step, with screenshots.

But first, here’s what it looks like once it works:

Two things before we start:

1. Save this. Ten minutes today, then four minutes a week forever.

2. Send it to one founder who retypes their bio into Claude every single week.

Sharing is free, and it’s how this newsletter grows.

Share

The Saturday that changed how I work.

Wise froze my account with $14,000 sitting inside it.

I sent them everything I could think of. They kept saying no.

What they actually wanted was years of proof I had never put together.

Five years of bank statements, all over the place. Invoices with numbers that did not match. Four years of taxes I was behind on.

I looked at that pile and had no idea where to start.

So on a Saturday I sat down and handed the whole mess to Claude.

I uploaded my raw statements and let it read and sort them. I did not type a single number in by hand.

It pulled five years into a clean summary.

Then it rebuilt my invoices so the numbers finally lined up.

Then it got my records clean enough that I could file four years of back taxes.

Four hours. That was it.

By hand that was days of work. Probably a full week, if I even got through it.

I sent Wise the clean proof and got my account back.

Most people are still typing one question into Claude and closing the tab.

The real shift is when you stop asking it things and start handing it the job.

That Saturday I got lucky, because I happened to explain everything properly on the way in.

What I wanted next was for it to already know all that, every time, without me typing it again.

So I built a folder structure to fix it, and I now teach it in my Master Claude workshop. This article is that structure, start to finish.

My honest claim, up front.

This will not make Claude smarter.

It will make Claude stop guessing at you, which is a different thing and worth more than it sounds.

1. Make the folders. Ninety seconds.

Do not open Claude yet. Open Finder.

Step 1: Go to your Desktop.

Step 2: Right click, then New Folder. Call it cowork. Lowercase, no spaces.

Step 3: Open it and make four folders inside, named exactly:

• about-me: who you are, so Claude gets you

• reference: source material Claude can pull from

• templates: starter shapes Claude fills in

• outputs: where finished work lands

Step 4: Stop. Do not add a fifth.

(Every extra folder is a decision you will have to make again later. Four is enough for a year.)

Here is why this shape and not your existing mess.

You are about to give an agent write access, and the folder you connect is the entire world it can see.

A small tidy world is a safe world.

So never put these in cowork: bank statements, passwords, signed contracts, anything with a client’s private data.

If a task genuinely needs one of those, copy the single file in, do the task, then take it out again.

2. Fill about-me/ first. Three files, three prompts.

This is the folder that pays off fastest, so it goes first.

Each prompt below interviews you, one question at a time, then writes the file. You save the file into about-me/.

You are not writing these yourself. You are being asked good questions and answering them.

bio.md, who you actually are

Open a normal Claude chat and paste this:

I want you to help me write my bio.md file for my cowork folder. This file will help you understand exactly who I am, so every time we work together you already have the context.

Interview me by asking me 6 to 8 short, specific questions, one at a time. After each answer, ask one quick follow-up if you need clarity, then move to the next question.

Cover:
- What I do (role, company, what I actually spend my time on)
- The businesses or projects I run on the side
- The people who matter in my day-to-day (co-founder, family, team)
- Where I am based
- What I am known for or want to be known for
- Anything else that would help you understand me

When you have enough, write my bio.md as clean markdown I can save directly. Keep it in first person, keep it real, and do not make me sound like a LinkedIn profile.

Start with question one.

Answer honestly, including the unflattering bits. Then save what it writes as bio.md in about-me/.

(That last line about the LinkedIn profile is doing more work than it looks like. Without it you get “passionate about leveraging innovation” and you will hate it.)

voice-and-tone.md, how you sound

This is the file that matters most, and the one people skip.

I want you to help me write my voice-and-tone.md file for my cowork folder. This file will make sure every time you write something for me, it actually sounds like me.

I am going to paste 2 to 3 samples of my writing at the end of this prompt. Read them carefully.

Then interview me by asking me 5 to 7 short questions, one at a time. Cover:
- What tone I use (cheeky, warm, blunt, playful, direct. Describe it in my own words)
- Words and phrases I use often
- Words and phrases I would NEVER use
- How I open something I write
- How I close
- Anything that makes my writing sound unmistakably like me

When you have enough, write my voice-and-tone.md as clean markdown. Include:
1. A short voice profile in my own words
2. A list of 10 phrases I use naturally
3. A list of 10 "banned phrases" that would immediately break the voice
4. One sample paragraph you write in my voice, to prove you got it

Here are my writing samples:

[PASTE 2 TO 3 OF YOUR WRITING SAMPLES HERE, SEPARATED BY --- BETWEEN EACH ONE]

Use your best writing as the samples. Not your most recent. Not your most professional. The ones that sound most like you talking.

The banned-phrases list is the secret weapon. Mine has “leverage”, “unlock”, “game-changer” and “seamless” on it, and the difference is immediate.

goals.md, what you are actually working toward

I want you to help me write my goals.md file for my cowork folder. This file will make sure every time you help me on something, you know what I am actually working toward.

Interview me by asking me 5 to 7 short, specific questions, one at a time.

Cover:
- What I am working on right NOW (this month, this quarter)
- The bigger goals I am moving toward this year
- What "winning" would look like for me by the end of the year
- What is in my way, honestly
- What kind of help I want from you when I ask for it

When you have enough, write my goals.md as clean markdown, in first person, split into three sections:
1. Right now (this month or quarter)
2. This year
3. How I want you to help me get there

Keep it short and honest, not aspirational fluff. This is a working file.

Start with question one.

Three files. Maybe twenty minutes of answering questions.

You will never type your bio into a chat box again.

Doing this today? Send it to one person who would use it too.

Share

3. Put one thing in reference/.

You do not have to fill this folder today.

Read more

No Figma.

No designer.

No code editor.

New here? Subscribe so the next build lands in your inbox. It is free.

It goes like this:

1. Write four ugly lines about your idea (ugly is the point)

2. Open Claude Design and start from Blank

3. Get the whole page in one prompt

4. Fix what you hate by clicking on it, not coding

5. Build a one-question form so the button collects real emails

6. Wire both buttons to that form

7. Publish the page to the web in one click

8. Or export it as one file and host it yourself

9. Send the link to five people, then change one thing next week

I’ll show you every step, with screenshots.

But first, here’s what it looks like once it works:

Two things before we start:

1. Save this, block an hour this week and actually do it.

2. Send it to one founder who has been “about to make a landing page” since March.

Sharing is free, and it’s how this newsletter grows.

Share

Why I quit opening Figma for this.

I have been a software architect and full-stack developer for over seven years.

I can build a landing page from an empty folder.

That is exactly why I stopped doing it.

Because the page was never the hard part.

The hard part was the four days between “I have an idea” and “somebody can look at it.”

Four days of picking fonts.

Four days of nudging a box eleven pixels left while the idea got colder.

The page you just looked at took me under an hour, and most of that hour was me being fussy.

Here is the honest version of what I am claiming.

Claude Design will not replace a designer on your brand.

It will absolutely replace the four days.

1. First, what this thing actually is.

Claude Design is a canvas that lives inside Claude, at claude.ai/design.

You type what you want on the left.

A real page appears on the right.

Not a picture of a page.

An actual working page, built out of real web code (the same stuff every website on earth is made of).

That difference matters more than it sounds.

A picture of a page cannot collect an email.

A real page can.

Two things on that screen deserve a second look.

The template grid. Blank, Slides, Document, Wireframe, Mobile app design, UI mockups, Animation, Résumé, 3D object, Research, HTML email. For a landing page you want Blank.

The design system chip. Mine says “Prompts2Products Design System.” That is my colors and type, saved once, applied to everything I make from now on. It is the single reason my pages come out looking like mine instead of looking like a template.

If you have never set one up, you can point Claude at your website or your files once and let it build the system. Then forget about it forever.

That menu is worth reading once so you know what is possible:

• Attach file or Attach folder, for a document, a screenshot, a sketch

• Reference another project, to reuse something you already made

• Connect GitHub or Link local code, if you have code somewhere

• Upload .fig file, if you are coming from Figma

• Design system and Skills, the two settings that make everything after this look like you

Now the honest bit, right up front, because I hate finding this out on step six.

Claude Design is not on the free plan.

You need a paid Claude plan, and heavy design work draws from the same usage pot as your normal Claude chats.

It is also still labelled Beta in the header, so buttons move sometimes.

If you are on free and you were about to get annoyed at me, this is your exit.

2. Before you touch the tool, write four ugly lines.

This is the step everyone skips, and it is the reason most AI-built pages look like a page about nothing.

Do not open Claude yet.

Open your notes app.

Write these four, in your own words:

1. My page is for [who], who is stuck on [problem], and when they click the button they [exact thing that happens].

2. The button says: [exact words on the button].

3. My one piece of real proof is: [a number, a name, a credential, anything true].

4. What must NOT be on this page: [list it].

That is it.

Make it ugly.

Here is the shape of one:

“for solo founders who keep rebuilding their pricing page, who are stuck comparing themselves to competitors, and when they click the button they join a waitlist for a teardown.”

Nobody will ever read that sentence.

It just stops Claude from guessing.

If you write “no pricing table, no team photos, no five-tier comparison,” Claude will not put them there.

Most bad first drafts are not wrong.

They are just crowded.

I know exactly what the hesitation is here.

“Why would I pay for a newsletter when there are free YouTube videos about this.”

Fair, and the free half of this article already gets you to a page.

The paid half is where the button collects real emails and the page goes live at a link you can text someone, which is the only version that has ever changed anything for me.

Subscribe now

Know someone with an idea and no link to send? This one’s for them.

Share

3. Open the canvas and get your whole page in one prompt.

Now we build. One small action per step.

Step 1: Open a new browser tab.

Step 2: Go to claude.ai/design and sign in with your Claude account.

Step 3: Look at the template grid under the message box. Click Blank.

Step 4: Check that your design system chip is showing next to the message box. If it is not, click the plus button, choose Design system, and pick yours.

(Skip this and your page will come out looking like everybody else’s. This one click is the difference.)

Step 5: Click into the message box.

Step 6: Paste this, with your own four lines swapped in.

This is the only prompt in the whole article, so make it count:

Build a single-scroll landing page. No navigation menu, no footer links, no pricing table.

Who it is for: [paste your ugly sentence here]

The page needs exactly these sections, in this order:
1. A headline that names the problem, not the product
2. One sentence under it saying what happens when they click
3. One button labeled "[your button words]"
4. Three short blocks explaining how it works, six words each maximum
5. One proof block containing this real thing: [your real proof]
6. The same button again at the bottom

Rules: plain English only, no marketing language, must look right on a phone first.

Do NOT invent testimonials, logos, statistics, or customer names. Leave out every claim I did not give you.

Show me one version and I will tell you what to change.

Step 7: Press the send arrow and watch the right side of the screen.

Now here is the moment I did not expect, and it is the best argument for that “do NOT invent” line.

Claude added two small things I never asked for: a little wordmark at the top, and a line under the last button reading “Free. Unsubscribe any time.”

Then it told on itself. Unprompted.

Then it ran its own check, said “found issues, fixing,” and removed the invented line by itself.

(An AI that flags its own additions and then deletes them is genuinely new. Two years ago you had to catch that yourself.)

Read what it says back to you, every time.

It will tell you what it invented, and you get to say “cut that.”

4. Now make it yours, by clicking on things.

Here is where most people go wrong.

They read the first draft, decide it is 80% right, then type a giant paragraph asking for fifteen changes at once.

You get back a page that is 60% right and differently wrong.

Instead, use the edit tools, because Claude Design has real ones.

Step 1: Click Edit in the top right of the canvas.

Step 2: A panel opens on the left with four tabs: Simple, Pro, Code, and Tweaks.

Step 3: Read the line it gives you, because it explains the whole model: click any element on the canvas to edit it, repeated elements are edited together, shift-click to select more.

(Repeated elements edited together is the useful bit. Change one of your two buttons and both change. That is a feature, not a bug.)

Step 4: Click straight onto the thing you dislike and change it.

Do this for anything in quotes, any name, any number.

Never let an AI write the one sentence your reader will actually judge you on.

(You know your customer’s exact words. Claude is guessing at them. Use yours.)

Step 5: Now open the Tweaks tab. This is the part nobody tells you about.

Claude builds custom controls for your specific page.

On mine, it had made a toggle called showEmailField. I never asked for it. It offered it in the chat, then put a switch at the top of the canvas.

Step 6: Flip it on and watch the page.

Note the two buttons that appear on the right when you touch a tweak: Reset and Save as defaults.

Reset puts everything back.

Save as defaults means this is now how the page always looks.

Step 7: When one section finally looks right, say this in the chat:

“Apply that same spacing and type treatment to the whole page.”

One good section becomes the whole page.

That is the move.

Step 8: Click Save at the top of the edit panel, or Discard if you were only poking around.

If this is saving you an afternoon, send it to one founder who is still nudging boxes.

Share

5. Make the button collect real emails.

A beautiful page with a dead button is a poster.

We are going to make the button collect real email addresses, the boring reliable way.

Step 1: Open a new tab and go to docs.google.com/forms.

Step 2: Start a new blank form.

Step 3: Click the big form title inside the card. Select the words “Untitled form” and type over them. Mine says “Join the waitlist.”

(Careful, this does not rename the file. Mine is still called “Untitled form” in Drive, which is going to confuse me in three weeks.)

Step 4: Click on the question card underneath. The words “Untitled Question” get highlighted. Type “Your email” straight over them.

Step 5: Open the question type dropdown on the right, currently saying “Multiple choice.” Choose Short answer.

Step 6: Delete every other question. One field. I mean it.

(Every extra field costs you sign-ups. Nobody ever regretted asking for less.)

Step 7: Click Publish in the top right. A box appears saying who can respond. Check it says “Anyone with the link,” then click Publish.

(A form you did not publish will not open for anyone. This step is new-ish and it catches people.)

Step 8: Click the link icon in the top bar to open the share box.

Step 9: Check that Responder view says “Anyone with the link.”

Step 10: Click Copy responder link.

One warning that cost me nothing but could cost you something.

The link you just copied has extra junk on the end, after a question mark.

Part of that junk is an identifier tied to your Google account.

Before you paste that link anywhere public, or screenshot it, cut everything from ?usp= onward.

You want the part that ends in /viewform and nothing more.

Step 11: Go back to your Claude Design tab.

Step 12: Click into the chat box and type this, then paste your trimmed link on the end:

“Make both buttons open this link in a new tab: “

Step 13: Send it, and wait about thirty seconds.

Is a Google Form the prettiest option? No.

Does it cost nothing, work everywhere, never go down, and drop every email into a spreadsheet you already know how to open? Yes.

Pretty comes in version four.

6. Get it online. There are two doors, and they are different.

Right now your page lives inside Claude.

Fine for you, useless for everybody else.

You have two ways out, and I am going to be straight about the trade because the fast one has a catch.

Door one: publish it in one click.

Step 1: Click Share in the top right.

Step 2: In the panel, click Publish as artifact.

Step 3: A preview box appears. It tells you plainly that anyone with the link will be able to view this, even without signing in to Claude.

Step 4: Click around in the little preview and make sure nothing is broken. There is an “Ask Claude to fix” button right there if something is.

Step 5: Click Publish to web.

Step 6: A new tab opens with your live page at its own link. That link is yours to send.

Now the catch, and it lands on the exact click you care about most.

When someone on your published page clicks your button, they do not go straight to your form.

They get a grey box first: “Open external link. You’re leaving Claude to visit an external link.”

Then they have to click “Open link” again.

It works. I tested it. But that is a speed bump sitting directly in front of your sign-up.

So: door one is free, instant, and perfect for showing five people. If the click matters, keep reading.

Door two: export one file and host it yourself.

Step 1: Click Share again.

Step 2: Under Export, click Project HTML.

Step 3: A box appears with two choices, and the difference is not obvious:

• Project archive, marked Instant. Every project file, zipped. Free.

• Standalone HTML, marked Uses Claude. Claude combines the page into one self-contained file that opens anywhere, even offline. It counts toward your usage limits.

Step 4: Choose Standalone HTML and click Export.

Step 5: Wait. This one is not instant. Mine took about forty seconds and ran as a proper Claude turn, reading the files and inlining everything.

Step 6: When it finishes, a Download button appears in the chat, plus a line confirming what you got.

Mine said the file works offline, fonts and styles are inlined, and both buttons still open the form.

Step 7: Click Download. A small box says your HTML will download now. Click Download again.

Step 8: That single file is now yours. Drop it on any host that takes a file, and there is no interstitial, because it is not living inside Claude anymore.

Step 9: Whichever door you took, open your link on your phone.

Step 10: Click your own button. Make sure the form opens.

Step 11: Send the link to five people who match your ugly sentence. Not fifty. Five.

Five people who fit will tell you more than fifty being polite.

7. Five things that will trip you, and the fix.

Your project has a ridiculous name, and it is on your live page.

Mine got auto-named from Claude’s first reply, so the top bar of my published page read “# Founders Stuck Without Shipping Here’s the single-scroll landing page: ---”.

Fix it before you publish. Click the little arrow next to the project name in the top left, choose Rename, give it two words.

(I published first and noticed after. Learn from me.)

It looks like every other AI page.

Soft gradients, one serif headline, three rounded cards in a row.

The fix is not a better prompt. It is your design system, attached before you send anything. Mine was attached and the page came out in my purple on the first try. (Yes, I like purple).

If you have not built one, do that once and never think about it again.

The standalone export ate your usage.

It warns you, in small text, and it is easy to miss.

If you just need the files and you know what to do with them, take Project archive instead. Instant and free.

Your button opens a warning box.

That is the published-artifact interstitial from section 6. It is not broken.

If the extra click bothers you, take door two and host the file yourself.

Your project suddenly has extra pages in it.

Mine went from one page to three after exporting, because the export created files inside the project.

Harmless. Just do not panic when the page count changes, and check you are still looking at the right file.

8. The weekly loop, once the page exists.

The page is not the project. The page is the instrument.

Here is the loop, and it takes about twenty minutes:

1. Open your form responses. How many opened, how many signed up?

2. Change one thing. The headline, usually. Only one.

3. Republish, or re-export and re-upload.

4. Send it to five new people.

One change per week. Fifty two changes a year.

That beats a redesign every time, and a redesign is what you do instead of this when you are scared.

Where this falls short (being honest).

It costs money. Claude Design needs a paid plan, and design work draws from the same usage as your chats. The form and the publishing are free. The canvas is not.

It is still Beta. The header says so. A button you found last Tuesday may have moved by next Tuesday. If you need a tool that never changes under you, this is not that tool yet.

The one-click host adds a click. Publishing as an artifact is genuinely one click, and it puts a confirmation box in front of every outbound link. Free things have edges.

Your data is in a spreadsheet, not a product. Google Forms collects emails. It does not send them anything. That is a separate job and I am not going to pretend it is one click. (You can try diff alternatives like Tally instead of Google forms)

It will not fix a weak offer. A beautiful page in front of an idea nobody wants gets you a clearer no, faster. Useful. Not the win people are hoping for.

It is not a website. One page, one job. The moment you want five pages, a blog, real login, and a database, you have outgrown this, and you should know that going in.

I am not here to sell you a canvas.

Anthropic does not pay me. Nobody does. Sadly.

I build things and tell you which parts actually worked, and I ran every step above on my own account before I wrote it down, which is why you got the ugly bits too: the junk project name, the usage warning, the extra click.

The four days are gone. That is the only claim I am making today.

Somebody forwarded you this, probably. That is how anyone finds anything worth reading.

So do that job for one person who has been “about to make a landing page” for five months.

Share

And if a stranger sent you this one, thank them, then subscribe so the next build finds you on its own.

Subscribe now

Save this.

1. Write four ugly lines first: who it’s for, the button words, your one real proof, what must NOT be there.

2. claude.ai/design. Pick Blank. Check your design system chip is attached.

3. One prompt for the whole page. Ban invented testimonials inside the prompt.

4. Read the reply. It will confess what it added. Cut that.

5. Edit mode, four tabs. Click elements to fix them. Open Tweaks for the switches Claude built you.

6. One good section, then “apply that to the whole page.”

7. Google Form, one short-answer field, Publish, then Copy responder link. Trim everything after ?usp=.

8. Paste it in chat: “make both buttons open this link in a new tab.”

9. Rename the project before you publish. It shows on the live page.

10. Share, then either Publish as artifact (free, one click, adds an external-link box) or Project HTML, Standalone (uses your usage, one clean file, host it anywhere).

11. Open it on your phone. Click your own button. Send it to five people who fit.

PS: If you build one this week, reply and send me the link. I open every one of those, and I will tell you the one thing I would change.

No Android Studio. No SDK download. No cable of shame, and no six hour setup.

By the end of this you will be holding your own app (and yes, that feels different from a link).

New here? Subscribe so the next build lands in your inbox. It is free.

It goes like this:

1. Switch AI Studio from web to Android with one picker

2. Describe the app in one plain sentence

3. Watch it write real Kotlin and open a phone emulator inside your browser

4. Fix things by talking, exactly like the web version

5. Plug your actual phone into your computer and press Install on Device.

6. Watch your app launch on the phone in your hand

7. Push it to the Play Store internal testing track so up to 100 people can install it

8. Learn what does not work on this path, before it wastes your Saturday

I’ll show you every step, with screenshots.

Two things before we start:

1. Save this, and do it on a day when your phone charging cable is nearby.

2. Send it to one founder who has been quoted a fortune for a mobile app.

Sharing is free, and it is how this newsletter grows.

Share

Why I stopped telling founders “web first, always”

For years my honest advice was to build on the web and only go native when you had proof people wanted it.

That advice existed because Android development was genuinely expensive to start. You installed a large program, waited, configured a device, and usually gave up on a Tuesday.

At Google I/O in May of this year, that starting cost mostly disappeared.

AI Studio now generates native Android apps in Kotlin with Jetpack Compose, previews them in a phone emulator that runs in the cloud and streams into your browser, and installs them on a real device over your USB cable.

I still think web first is right for most products. I just no longer think “native is too hard to try” is a real sentence.

1. Flip one picker, and you are building a phone app.

This is genuinely the whole entry point, and it is easy to miss.

Step 1: Go to aistudio.google.com/apps in Chrome.

Step 2: Find Build mode using the navigation panel on the left.

Step 3: Look for the platform picker near the prompt box.

Step 4: Select Android. Not web. Android.

Step 5: Now type your app in one plain sentence, for example: “Create a daily task tracker that saves my tasks on the phone.”

Step 6: Send it, and wait while the agent generates the project.

Step 7: A phone shaped emulator will appear and your app will launch inside it.

What just happened underneath: it wrote a full Kotlin project using Jetpack Compose and Material 3 styling, with a single screen architecture, and it managed the build dependencies itself.

(you never have to learn what Gradle is today, but that is what was quietly handled).

That is the app existing. Now here is how it gets onto a real phone, and into other people’s hands, every step, starting now.

2. A phone inside your browser, and what it will lie to you about.

The emulator is a real convenience and a real trap, so let us handle both.

The good part: it behaves like a Pixel. You can tap, scroll, and interact with your app as though you were holding it. You can rotate it between portrait and landscape. And when the agent changes your code, the app rebuilds and the emulator refreshes itself.

Step 1: Tap around your app inside the emulator, using your mouse like a finger.

Step 2: Rotate it to landscape and see what breaks (something usually does, this is free QA).

Step 3: Ask the agent to fix whatever looked wrong, in plain words, in the chat panel.

Step 4: Watch it rebuild and refresh on its own.

Now the honest part. The emulator does not do everything a phone does. Camera and photo capture are not available in it. NFC and Bluetooth are not available. Location is simulated rather than real. And Google Play services, which includes Google Sign-In and Maps, work on a real device but not in the emulator.

So if you build something that takes photos or signs people in, the emulator will make you think you are broken when you are not. Test those on the real phone in step 3.

3. Now put it on your real phone. This is the good bit.

Everything up to here happened in a browser. This step makes it real.

You need three things: Chrome or Edge on your computer, a USB cable, and Developer Options with USB Debugging turned on on your phone.

Step 1: On your phone, turn on Developer Options and USB Debugging. If you have never done this, search your phone’s settings for “Build number” and tap it several times until it tells you developer mode is on, then find USB Debugging in Developer Options and switch it on.

Step 2: Plug your phone into your computer with the cable.

Step 3: Back in AI Studio, find Install on Device in the preview panel and click it.

Step 4: Your browser will open a USB device picker. Choose your phone from the list.

Step 5: If your phone shows an “Allow USB debugging” prompt, accept it. It appears the first time you connect.

Step 6: Wait while the app file transfers and installs.

Step 7: The app launches on your phone by itself.

No local install of any developer tool was needed for that. The browser talked to your phone directly (this is done through a browser capability called WebUSB, and it is the reason you did not need to set anything up).

4. Let other people install it, without launching to the world.

You do not need a public launch. You need five people to actually use it and tell you the truth.

AI Studio can publish your app to the Google Play internal testing track, which lets you distribute to up to 100 testers.

Before you start, you need a Google Play Developer account. Google charges a one-time registration fee, listed as $25 at the time I am writing this, and you also need a completed developer profile in the Play Console.

⚠️ Confirm the current fee on Google’s signup page, these things change.

Step 1: In AI Studio, open Settings, then Publish.

Step 2: Click Publish to Play Store.

Step 3: Sign in with your Google Play Developer account when it asks.

Step 4: Let it work. AI Studio signs the app file for you using a managed key, creates the listing or uploads a new version, and publishes to the internal testing track.

Step 5: Copy the link it gives you.

Step 6: Send that link to your testers. They install like they would any app.

One important limit: this path publishes to internal testing only. A real public release still has to be managed directly in the Play Console. Which is honestly fine, because internal testing is where you belong until people actually like the thing.

If someone you know has been quoted an eye watering number for a simple mobile app, send them this.

Share

5. What this path cannot do, learn it now not at midnight.

I am putting this before the pretty ending because it is the most valuable section in the article.

Android apps built this way are client side only. That means the whole Thursday article does not apply here. No Firebase database, no Firebase sign in, no secrets storage, no Google Workspace connections, and no multiplayer. Those live on the web side of AI Studio.

So an Android app built here can save things on the phone itself, and it cannot yet share data between two people’s phones through this path.

The other limits, plainly:

One screen architecture only. Single activity, single module projects.

Kotlin and Jetpack Compose only. No Java, no old style XML layouts.

No native C or C++ code. If you do not know what that means, you do not need it.

Phones and tablets only. No watches, no TV.

Export is a ZIP file only. You can download the whole project and continue in Android Studio, but pushing an Android project straight to GitHub is not available on this path yet.

That last one matters more than it sounds. It means when your app outgrows this, the exit is a download, then a real editor.

6. So what would I actually build on this path?

Given those limits, here is where this shines, from real client conversations.

A tool for one person’s own use. A tracker, a calculator, a checklist, a converter, something that keeps its data on the phone and never needs anyone else’s.

An internal tool for a small team, where everyone installs from the tester link and each person’s copy stands alone.

A demo you hand to someone in a meeting. Not a slide of an app. An app.

And a proof of appetite. Ten testers using something for two weeks tells you more than any survey, and now it costs you an afternoon to find out.

This is also the version of the story where the harder parts are already handled: the database that syncs between people, the sign in, the scaling, the bit where two hundred users show up at once.

If you would rather hand that part off than learn it, book a free consultation call with me and we will work out what it would actually take.

Where this falls short (being honest).

The emulator will mislead you. Camera, Bluetooth, real location and Google sign in behave differently there than on a real phone. Test on the phone before you trust anything.

Client side only is a real ceiling. The moment your app needs to share data between people, this path stops and the web path starts.

Internal testing is not a launch. One hundred testers is a great start and it is not the Play Store. Production still goes through the Play Console properly.

A developer account costs money. Small, one time, and still a real barrier for someone testing an idea on a weekend.

Speed is not judgement. You can now build a mobile app in an afternoon, which means you can now build the wrong mobile app in an afternoon, faster than ever.

The cable was the surprise, not the code.

Nobody paid me to write this, and I have no relationship with Google beyond being a very frequent user of their free tier. (I pay sometimes too).

The thing that actually changed my mind was not the generated Kotlin. It was plugging in a cable and watching an app I described in one sentence open on the phone in my hand, with nothing installed on my laptop.

This newsletter grows one forward at a time. If this one earned it, send it to the person who told you a mobile app was out of reach this year.

Share

And if someone forwarded this to you, subscribe here so the next build arrives on its own.

Subscribe now

Save this.

1. Build mode, platform picker, choose Android. That is the entry point.

2. One plain sentence gets you real Kotlin and a browser emulator.

3. The emulator cannot do camera, Bluetooth, real location, or Google sign in.

4. Developer Options plus USB Debugging plus a cable plus Install on Device equals your app on your phone.

5. Settings then Publish then Publish to Play Store gets you internal testing, up to 100 testers.

6. Android on this path is client side only. No database, no sign in, no multiplayer.

7. Outgrowing it means downloading the ZIP and moving to Android Studio.

PS: If you follow this today, take the photo of your own app on your own home screen. You will want it later, and it is a much better founder photo than a laptop and a coffee.

A note on this one: it’s a paid-tier post. I’m leaving it open to everyone today because I want people actually building, not reading about it. This is the kind of thing that normally sits behind the paywall.

Type something in. Hit refresh. It is gone.

Today we give it a real memory, and a real front door, by asking for both in plain English.

New here? Subscribe so the next build lands in your inbox. It is free.

It goes like this:

1. Prove the amnesia with a five second test (it stings, do it anyway)

2. Ask the agent, in one sentence, to add a database

3. Watch it set up Firebase for you, no console tabs, no config files

4. Save one thing, then refresh, then find it still sitting there

5. Ask for Sign in with Google so each person sees only their own stuff

6. Lock the doors so strangers cannot read your data (this is the step people skip)

7. Run the three tests I run before I show anything to a client

I’ll show you every step, with screenshots.

Two things before we start:

1. Save this, block an hour this week and follow it click by click.

2. Send it to one founder whose demo keeps resetting mid pitch.

Sharing is free, and it’s the nicest thing you can do for a newsletter.

Share

Why this is the step I get asked about most

I have been building software for over seven years, and I now build with AI every day, and the wall is always the same wall.

People get something beautiful running in the preview pane, then someone asks “can two people use it?” and the whole thing quietly falls over.

Because a preview app keeps everything in the page’s short term memory (which is wiped the moment the page reloads, like a whiteboard cleaned by a very enthusiastic cleaner).

A database is different. A database is the filing cabinet in the corner that nobody wipes.

Until May of this year, wiring one up meant a Firebase console, a config object, some copy and paste, and a small prayer.

Now the agent inside AI Studio does the provisioning and writes the code for it, because you asked it to in one sentence.

1. First, prove your app has amnesia.

Do not skip this. It changes how carefully you do the rest.

Step 1: Open your app’s live preview in AI Studio.

Step 2: Add something. A task, a note, a name, whatever your app collects.

Step 3: Look at it. Feel good.

Step 4: Press refresh in your browser.

Step 5: Watch it vanish.

That empty screen is what every visitor to your shared link would see, every single time.

Two seconds of silence. That is the sound of the data leaving.

So that is the problem, and it takes one sentence to start fixing it.

Here is exactly how I do it, every step, starting now.

2. Ask for the filing cabinet. Literally just ask.

You are not going to open the Firebase console today. Not once.

Step 1: Go to your app in Build mode at aistudio.google.com/apps.

Step 2: Click into the chat panel at the bottom, where you normally type your build prompts.

Step 3: Type this, in plain words: “Add a database to my app so the items I save are still there after I refresh the page.”

Step 4: Send it.

Step 5: Wait, and read what comes back. The agent will tell you it is setting up Firebase and Firestore for your app (Firestore is the database, Firebase is the family it belongs to, that is all you need to know today).

Step 6: If a card appears in the chat asking you to confirm or connect something, read it and confirm it.

Step 7: Let the preview finish rebuilding on the right.

What you are watching happen: the agent provisions the database, writes the code that talks to it, and wires that code into the screens you already built.

You did not configure anything. You described an outcome (and yes, this is still slightly funny to me, and I do this for a living).

3. Now the refresh test, for real this time.

This is the moment that makes the whole hour worth it.

Step 1: In the preview, add one item to your app.

Step 2: Add a second one, so you can see order.

Step 3: Press refresh in your browser.

Step 4: Count to two.

Step 5: They are both still there.

If they are not, do not panic and do not start over. Go to the chat and type:

That sentence fixes it most of the time, because the writing half often lands before the reading half.

4. A front door, so people are not sharing one big pile.

Right now your app remembers things, but it remembers them for everybody at once.

Every visitor sees every item. Including the ones they did not add.

You fix that with sign in, and you fix it the same way as before.

Step 1: In the chat panel, type: “Set up Sign in with Google so each user only sees the items they created.”

Step 2: Send it, and let the agent handle the setup.

Step 3: Read what it does. It will add Firebase Authentication and a Sign in with Google flow, and it will change your data so each item belongs to the person who made it.

Step 4: Let the preview rebuild.

Step 5: Click the new sign in button in your own app and sign in with your Google account.

Step 6: Add an item, so there is something attached to you.

Step 7: Open the app in an incognito window and sign in with a different Google account.

Step 8: Your first item should be nowhere in sight. That is correct. That is the whole point.

5. Lock the doors. Please do not skip this one.

Here is the part that gets people, and it got me once, years ago, on something small that I still think about.

A database that has been switched on quickly is often open. Meaning code that is not your app can read what is inside it.

Nothing looks wrong. Your app works perfectly. That is what makes it dangerous.

Step 1: In the chat panel, type: “Add Firestore security rules so only signed in users can read and write their own items, and nobody can read anyone else’s.”

Step 2: Send it and read the reply carefully.

Step 3: Ask a follow up, in the same chat: “Show me the security rules you set, and explain each line in plain English.”

Step 4: Read that explanation. Slowly. This is the single most useful five minutes in this article.

Step 5: Test it. Sign out entirely, then try to load the app. You should see the sign in screen, not data.

Nobody joins a community before they have shipped something. I know, because I felt exactly that way for years.

But the step you just did, security rules on a live database, is precisely the step people bring to the calls inside Prompts to Products, half finished and slightly worrying.

You already get the written playbooks. The community is where you get me, live, looking at your actual rules on your actual app.

Come sit in the room

6. Three things that go wrong, and what I type to fix them.

These are the three I hit most, in the order I hit them.

It saves, but nothing comes back after a refresh. The write worked and the read did not. Type:

“The app writes to Firestore but does not load existing items when it starts. Fix the load on startup.”

A shared link shows an access error. If someone opens your shared app and gets a 403 Access Restricted message, two things cause it. A privacy extension in their browser blocking the app, or a build problem in the current code. For the second one, type:

“Fix any build issues with the current code,” then reshare the link.

Everyone can still see everything. The auth landed, but the data was never tied to the user. Type:

“Every item should store the ID of the user who created it, and the app should only show items belonging to the signed in user.”

7. Do this once a week and your app stops being a demo.

The build is done. Here is the loop that keeps it healthy, and it takes about ten minutes.

Step 1: Sign in as yourself. Add one item. Refresh. Confirm it survived.

Step 2: Sign in as a second account. Confirm you cannot see account one’s items.

Step 3: Sign out completely and try to reach the data. Confirm you cannot.

Step 4: In the chat, ask: “Are there any security rules or data issues I should know about in the current version?”

Step 5: Fix whatever it names, then run steps 1 to 3 again.

Two accounts, one refresh, one signed out check. That is the whole ritual, and it catches almost everything before a stranger does.

Where this falls short (being honest).

This is web only. The Firebase integration, secrets, and the Workspace connections live on the web side of AI Studio. If you go build a native Android app there, none of this comes with you. That gap is Sunday’s article, and it matters.

Free has edges. Firebase lets you start without paying and scale later if you need more room. Quotas and paid tiers change, so check the current numbers yourself rather than trusting any article, including mine.

Sharing your app uses your allowance. When you share an app that calls Gemini, those calls count against your own usage. Fun to forget. Less fun to discover.

The agent is confident, not infallible. It writes real security rules and it explains them well, and it can still make an assumption you did not want. Reading the explanation is not optional.

A database will not fix a vague product. Now your app remembers. Whether it remembers anything worth keeping is still entirely on you.

The refresh button is a better critic than I am.

Nobody paid me for this. Firebase does not know my name, and Google has never sent me so much as a sticker.

I wrote it because I have watched too many good demos die on someone else’s laptop, and the fix was always this, one sentence and an hour.

The nicest thing you can do for me costs nothing: send this to the one founder whose app keeps forgetting things mid pitch. They will know exactly who they are.

Share

And if this landed in your inbox from a friend, subscribe so the next build comes straight to you.

Subscribe now

Save this.

1. Prove the amnesia first. Add, refresh, watch it vanish.

2. “Add a database to my app so items survive a refresh.” One sentence.

3. Refresh test. Then a new tab. Both must pass.

4. “Set up Sign in with Google so each user only sees their own items.”

5. Ask for security rules, then make it explain every line to you.

6. Test with two accounts and one signed out browser, weekly.

7. Firebase in AI Studio is web only. Android is a different path.

PS: If step 5 made your stomach drop a little, good. That reaction is the difference between a demo and a product, and it means you are paying attention.

Same centered card. Same rounded buttons. Same lonely gradient in the header.

Google noticed too, and in June they shipped a button for it.

New here? Subscribe so the next build lands in your inbox. It is free.

It goes like this:

1. Open your app in Google AI Studio Build mode (the tab where you actually build things)

2. Give it real content first, not an empty page

3. Click Design Variations

4. Look at the layouts it offers you

5. Pick one, apply it, and watch your app change shape

6. Then point at the one thing you still hate and fix it by hand (no code)

   

I’ll show you every step, with screenshots.

But first, here’s what it looks like once it works:

Two things before we start:

1. Save this, block 20 minutes this week and actually do it.

2. Send it to one founder whose app looks a little sad.

Sharing is free, and it’s how this newsletter grows.

Share

Why I care about this more than I should

I build software for a living, and I have shipped things that worked perfectly and still looked cheap.

My logo background tester and QR code generator is a good example.

The first version did the job. It also looked like a school project, and I knew it the second I opened it on my phone.

I fixed it the slow way back then, prompt after prompt, describing spacing in words like a person trying to describe a smell.

That is the part Google just deleted, and I am not being paid to say so, I just want more of you to actually ship, which is also why I would love you to subscribe rather than buy anything from me today.

Subscribe now

1. First, stop asking it to redesign an empty page.

This is the part most people get wrong, so we do it before anything else.

Design Variations works from what is already on your screen.

An empty page gives it nothing to reorganize.

A page with real headings, real buttons and real content gives it something to actually rearrange (think of it as a room, it can only move the furniture that is in there).

Step 1: Go to aistudio.google.com/apps in your browser.

Step 2: Open the app you already built, or start a new one from the input box.

Step 3: In the chat panel, ask it to fill your app with realistic sample content. Not “lorem ipsum.” Real sounding names, real prices, real headings, six or seven rows of them.

Step 4: Wait for the preview on the right to rebuild.

You will know it worked when the preview looks busy instead of empty.

2. Now the button. This is the whole trick.

Google announced Design Variations on June 26, 2026, and the pitch was refreshingly blunt: describing a look in words is hard, so they made a button for it.

Step 1: Look at the layout options inside Build mode, around your app preview.

Step 2: Find Design Variations and click it.

Step 3: Wait. It generates several different layout proposals from your current app.

Step 4: Click through them one at a time and compare.

Step 5: Pick the one you like and apply it.

That is it. Your app keeps every feature and changes its whole shape.

The bit I love: you are not re-prompting from scratch, so nothing breaks while it gets prettier (which is exactly the trade people were making before, and it hurt).

If this is saving you an afternoon, send it to one founder who’s still stuck.

Share

3. Okay, but you will still hate one thing.

You always do. For me it is usually a heading that is too big and too proud of itself.

You do not need a new variation for that. You point at it.

AI Studio has a mode that lets you highlight any part of your app’s interface and describe the change you want, in plain words, right there on the element (the docs call it annotation mode, and in the app you may see it labelled Annotate app).

Step 1: Turn on annotation mode from the controls above your preview.

Step 2: Click directly on the thing you hate. The heading. The button. The card.

Step 3: Type what you want in normal human language. “Half this size.” “Move this under the image.” “Make this the quietest thing on the page.”

Step 4: Send it, and watch only that piece change.

This is the difference between telling a builder “the kitchen feels wrong” and pointing at one cupboard.

One change. Nothing else broke. This is the good part.

Here is the honest shape of the whole thing.

Content first, then variations for the big structure, then annotations for the small fixes.

That order matters more than any single feature, and it is the order I use on real client work.

Where this falls short (being honest).

It cannot save a confusing idea. A pretty layout of a muddled product is a muddled product with better spacing.

It is a creative director, not a decision maker. The most dramatic layout is rarely the most useful one. A checkout page should reduce hesitation, not win an award.

The rollout is gradual. Features like this land in accounts at different times, so if you do not see the button yet, you are not doing it wrong.

Themes are not here yet. Color and type presets have been talked about, but layout is what shipped. So your palette is still your job.

The button is not the point. Shipping is.

Nobody at Google knows I exist, and no one paid for a word of this.

I wrote it because “it looks AI made” is the reason a lot of good little apps never get shown to anyone, and that reason just got a lot cheaper to fix.

People read this because someone they trusted sent it to them. If it earned that, pass it to one person whose app deserves better than a lonely gradient.

Share

And if a stranger sent you this one, thank them, then subscribe so the next build finds you too.

Subscribe now

Save this.

1. Real content before variations. Empty pages get lazy layouts.

2. Design Variations for the whole shape, one click, nothing breaks.

3. Annotation mode for the one element you hate.

4. Big first, small second. Never the other way round.

5. If the button is not there yet, it is the rollout, not you.

PS: Thursday’s article is the next thing this app needs, a real memory, so it stops forgetting everything the second someone refreshes the page.

Not “open a chat, ask a robot, copy the answer, paste it back.”

I mean the cell itself writes.

You type a small instruction inside the box, you hit one button, and words appear.

New here? Subscribe so the next build lands in your inbox. It is free.

It goes like this:

1. You open a normal Google Sheet. (the one you already know)

2. You type AI(...) in a cell and tell it what to write.

3. You press one button and it writes.

4. You drag it down a whole column, and now it writes a hundred rows at once. (this is the fun part)

5. You end up with a week of content sitting in a spreadsheet, ready to copy.

I’ll show you every step, with screenshots.

But first, here’s what it looks like once it works:

Two things before we start:

1. Save this. Block twenty minutes this week and actually do it once.

2. Send it to one founder who is still copying and pasting from a chat window all day.

Sharing is free, and it’s how this little newsletter grows.

Share

Why I trust a spreadsheet with my words.

I build software for a living.

I have shipped real products, and I run the content for them too.

So I have written the “post about the new feature” message more times than I can count.

Here is the honest truth about content for a small team.

The hard part is almost never the writing.

The hard part is the doing it again.

Every week. Same formats. Same fifty little tasks. (you know the ones)

So when Google put a real writing model straight inside a spreadsheet cell, I paid attention.

Because a spreadsheet is a machine for doing the same thing a hundred times.

That is the whole job of a spreadsheet.

And now one of the things it can do a hundred times is write.

1. First, what this actually is.

Let me explain it like you have never opened a spreadsheet in your life. (no shame if that is true)

A spreadsheet is a grid of little boxes.

Each box is called a cell.

Normally you type numbers or words into a cell, and that is that.

Sometimes you type a formula, which is just an instruction that starts with an equals sign.

You have probably seen =SUM(...) which adds numbers up.

Well, now there is a new instruction.

It is called =AI(...) and instead of adding numbers, it writes words.

(an instruction that starts with = is called a formula. That is the only jargon word here, I promise.)

You put your request inside the brackets, in quote marks.

Something like =AI("write a friendly instagram caption about our new pricing page").

You press one button.

The AI reads your request and types the answer right into that box.

That is the entire idea.

It is Gemini, Google’s AI, living inside your spreadsheet instead of in a separate window.

2. Let’s make one cell write.

Okay. Hands on the keyboard now.

We are going to make one single cell write one single thing.

Small on purpose. We build up from here.

Step 1. Open a new tab in your browser.

Go to sheets.google.com and open a blank sheet.

Step 2. Click on cell A1 once.

Type a plain topic. Something like: our new pricing page went live.

Press Enter.

Step 3. Now click on cell B1, the box right next to it.

Type this, exactly:

=AI("write a short, friendly LinkedIn post about this update", A1)

That little A1 at the end is you pointing at the box next door and saying “here’s what it’s about.”

(the part in quotes is your instruction. The A1 after the comma is the thing you’re talking about. That’s the only pattern you need.)

Step 4. Press Enter.

You will see a small button pop up that says Generate and insert.

Click it.

Wait a second or two. It is thinking.

Then your LinkedIn post appears, right there in the cell.

Do not like what it wrote?

There is a button called Refresh and insert.

Click it and it writes a fresh version.

Keep clicking until one feels right. (it is like asking a friend to try again, no awkwardness)

If this is already saving you time, send it to one founder who’s drowning in captions.

Share

3. Now make it do a whole list at once.

This is where it stops being a party trick and starts being useful.

One cell writing one post is cute.

One sheet writing thirty posts while you get coffee is a different feeling entirely.

Here is the move.

Step 1. In column A, type a list of topics, one per row.

Row 1: our new pricing page.

Row 2: a client just hit their first big win.

Row 3: why we built the product.

Keep going. Ten rows if you want.

Step 2. Click cell B1 and write your AI formula again, pointing at A1:

=AI("write a warm, plain-English social caption about this. Keep it under 40 words.", A1)

Press Enter, click Generate and insert. One caption appears.

Step 3. Now the magic drag.

Click cell B1 once so it is selected.

See the tiny blue square at the bottom right corner of the cell?

That is called the fill handle.

Click it and drag it straight down, all the way to the bottom of your list.

(the fill handle is that little corner dot. Grab it and pull. That’s it.)

Every row now has its own formula, pointed at its own topic.

Step 4. Select that whole column of new formulas, then press Generate.

Sit back.

One by one, every row writes its own caption.

Now, here is the honest boundary of today.

What you just built is a starter.

It writes one format, from a plain list, one client’s voice.

The full thing, the real content machine, is bigger.

It holds a whole client’s brand voice.

It writes five formats at once from a single topic. (post, caption, email subject, ad line, hook)

It even makes the on-brand image to go with each one.

And it does a month in one pass.

I am building that full engine with you this Thursday, step by step, in the paid edition.

Today’s sheet is genuinely useful on its own though.

You can go run your whole week’s captions off it right now. No upgrade needed to get value today.

Where this falls short (Here is me being honest).

It might not be on your account yet.

This lives on eligible Google Workspace, Google AI Pro, or Google One AI Premium plans, plus Google’s free tester program.

It rolled out in the US and in English first. If typing =AI does nothing, that is why, not you. ⚠️ Check your plan before you blame yourself.

It writes a snapshot, not a live feed.

The words it writes sit there as plain text.

Change the topic later and the caption does not update on its own. You click generate again.

It has a daily limit.

Push it hard enough and it asks you to wait a bit before more.

Fine for a normal week, worth knowing before you try to write a thousand rows at midnight.

It is a first draft, not a final one.

It gets you eighty percent there fast. Your taste is the last twenty. Read every line before it goes out with your name on it.

The nicest twenty minutes you’ll spend this week.

Nobody paid me to write this.

Google does not know I exist.

I just build with these tools every day, and this one quietly changed how my week starts.

The pricing-page caption used to be a fifteen minute chore, and now it is a cell.

That is the small thing I wanted to hand you today.

And here is my only ask, the honest non-pitch version.

You do not need to pay me a cent to use everything above.

But if you want the next build, the full content machine, to just show up in your inbox on its own, subscribing is free and takes one tap.

Subscribe now

People read this because a friend forwarded it to them.

If this saved you an hour, be that friend for someone else who is still stuck in the copy-and-paste loop.

Share

Save this five line recap

1. In a cell, type =AI("your instruction", A1), pointing at your topic cell.

2. Press Enter, then click “Generate and insert”.

3. Don’t like it? Click “Refresh and insert” for a new take.

4. Grab the little corner dot (the fill handle) and drag down to copy it to a whole list.

5. Select the column and Generate to write the whole batch at once.

PS: if a stranger sent you this one, hi, welcome. Thursday we turn this little sheet into a real content machine for a whole agency. It’s a good one.

A link you text to a friend.

A link a stranger can open on their phone in another country, right now, while you sleep.

And you can do it in about the time it takes to make coffee.

New here? Subscribe so the next build lands in your inbox. It’s free, and I mean actually free.

Last time, we gave your app a memory (that was the Supabase piece, the one where your data finally stopped vanishing on refresh).

Today we give it a front door.

Because a memory is lovely, but nobody can walk into a house that has no address.

It goes like this:

1. We find the one button in Google AI Studio that does the whole thing. (it’s hiding in plain sight, top right)

2. We click it, and I walk you through every little box that pops up.

3. Your app gets a real https:// link that anyone can open.

4. I show you the free part (Cloud Run gives you two million visits a month before a cent is due).

5. We set up the “redeploy” habit, so every future change goes live with one more click.

6. Then the two things that go wrong for beginners, and the exact fix for each.

I’ll show you every step, with screenshots.

But first, here’s what it looks like once it works:

Two things before we start:

1. Save this one. Block twenty minutes this week and actually publish something, even something silly.

2. Send it to one founder you know who has a beautiful app trapped on their laptop.

Sharing is free, and it’s genuinely how this newsletter grows.

Share

Why your app is stuck in that little window (and why that’s not your fault)

Here’s the thing nobody says out loud.

When you build in Google AI Studio, your app runs in a preview panel on the right side of the screen.

It looks real.

It is real, sort of.

But it’s living inside your editor, like a goldfish in the bag from the pet store.

Alive, yes. Swimming, yes. But not in a pond anyone else can visit.

To move it from “the bag” to “a pond with an address,” you have to do a thing that used to be genuinely hard.

I want to be honest about how hard it used to be, because it explains why so many good apps die on people’s laptops.

Two years ago, putting an app online meant renting a server.

It meant a tool called Docker, and a thing called a container, and words like “port” and “environment variable” and “reverse proxy.”

It meant a terminal, that black screen with the blinking cursor that makes normal humans close the laptop and go for a walk.

I know this because I’ve spent more of my life than I’d like inside that black screen (7-plus years as a developer and architect will do that to a person).

I once deployed a broken version of an app to 40 people at once because I fat-fingered one setting in that terminal.

We do not talk about that week.

So when I tell you the whole thing is now one button, I need you to feel how strange and wonderful that is.

The scary black screen is still down there somewhere, doing its job.

You just never have to look at it.

Watch: it works for me, and it doesn’t work for a stranger. That gap is the entire reason this article exists.

Okay.

Now let’s close that gap.

1. First, let’s find the one button that changes everything.

Before we click anything, I want you to just look at it.

Finding the button is half of the fear, so let’s kill the fear first.

Step 1: Open a browser tab and go to aistudio.google.com.

Step 2: Sign in with your Google account (the same one you’ve been building with).

(If you’ve never been here, that’s fine, you can build a tiny app in five minutes and still follow along. Everything is free to start, and there’s no credit card to sign in.)

Step 3: Click “Build” in the menu on the left, then open any app you’ve already made.

If you don’t have one yet, make the smallest possible thing so you have something to publish today.

Here’s the only prompt in this whole article:

Build me a simple one-page app with a big friendly button in the center.
When I click the button, show a random encouraging message for a founder.
Use the gemini-3.5-flash model. Keep the design clean, lots of white space, one accent color.

Paste that into the Build box, hit build, and wait a couple of minutes while it makes your little app.

(Yes, that’s a real app. Silly, but real. Perfect for a first publish.)

Step 4: Now look at the top right corner of the screen.

See the button that says “Publish”? That’s it. That’s the whole magic trick.

(Google likes to rename this. For a while it said “Deploy App.” If yours says something slightly different but lives in that same top-right spot, you’ve got the right one.)

Notice we haven’t done anything risky yet.

We just found a button and looked at it.

The palms-sweating part is next, and I promise it’s smaller than your brain is telling you it is.

Here’s exactly how it goes, click by click, starting now.

2. Click Publish. Here’s exactly what happens.

Take a breath.

You’re going to click Publish, and a little window is going to open with a few boxes.

I’ll stand next to you for each one.

Step 1: Click Publish in the top right.

A panel slides in. This is the deploy window. It will not bite.

Step 2: The first time, it may show a short welcome with a “Get Started” button. Click Get Started.

(This only shows up the very first time you ever publish. After that, it skips straight to the good part.)

Step 3: You’ll see a button that says “Publish App.” Click Publish App.

That’s the real trigger. You just told Google: take my little goldfish and put it in a pond.

Step 4: Now you wait.

A progress indicator appears. It usually takes a few minutes.

(This is a great time to refill the coffee. Do not refresh the page. Let it cook.)

Behind that little spinner, a lot is happening.

Google is packing your app into a container (think of it as a lunchbox that has everything your app needs to run, no matter whose computer opens it).

It’s placing that lunchbox on something called ==Cloud Run==, which is Google’s “just run my thing and don’t make me think about servers” service.

And here’s the part I love, the part that would’ve saved me that terrible 40-person week: your secret Gemini API key never gets shipped to the visitor’s browser.

It stays locked on the server side, where strangers can’t peek at it or run up your bill.

You didn’t have to configure any of that. AI Studio did it for you, quietly, in the background.

Step 5: When it’s done, AI Studio hands you a Cloud Run URL.

It’ll look something like

https://your-app-name-xxxxx.run.app

It is ugly.

It is also the most beautiful thing you’ll see all week, because it’s yours, and it works for everyone.

3. Your URL is live. Now let’s make sure it stays basically free.

Let’s talk about the question every founder whispers at this exact moment.

“Wait. Is this going to cost me money?”

Fair question. I asked it too, the first time, with my thumb hovering over the button like it might explode.

Here’s the honest answer.

The app itself now lives on Cloud Run, and Cloud Run is built to be nearly free for small apps.

You get two million requests every month before you owe a single cent.

(Two million. For a new app with, say, you and forty friends poking at it, you will not come close. Not for a long, long time.)

And it does something clever called “scaling to zero.”

When nobody’s using your app, it goes to sleep and costs you nothing.

When someone opens the link, it wakes up in a few seconds and serves them.

(That few-second wake-up is called a “cold start.” It’s the one small tax you pay for the app being free while it naps. We’ll deal with it in a minute.)

So for most people reading this, the real-world cost of your first published app is: nothing.

You still get a live, professional, HTTPS link.

Now, the second half of this section is the part that turns a one-time trick into a superpower: the redeploy loop.

Because your app isn’t done.

It never is. You’ll want to change the wording, fix a color, add a feature.

Here’s the beautiful part.

Step 1: Go back into AI Studio and change whatever you want (just tell it, in plain English, like always).

Step 2: Click Publish again.

Step 3: That’s it. Your live URL updates with the new version.

Same link. New app. Nobody has to do anything on their end.

(This is the loop I run every single week on my own products. Change something, hit Publish, it’s live. Change, publish, live. It stops feeling scary around the third time.)

This is also the honest moment to tell you where the deeper help lives.

You now have the method: build it, give it a memory, publish it, redeploy it. That’s the written playbook, and you get every one of these playbooks as a paid subscriber.

The community is the other thing. It’s the room where you bring your half-published app to a live call and we get it unstuck together, the redeploy that failed, the cold start that annoyed you, the feature you can’t word right.

You already have the playbooks. The community is where you get me, live, on your actual project. If that’s the help you want, the door is here.

Know someone who published today and can’t stop grinning? Send them this.

Share

4. Two things that go wrong, and the exact fix for each.

I’d be doing you dirty if I ended at the happy path.

Here are the two snags real beginners hit, and how to walk right through them.

Snag 1: It won’t give you the free “Starter Tier,” and asks you to add billing.

Here’s the sneaky rule nobody explains.

That lovely free Starter Tier (the one that lets you publish without a credit card) is only for Google accounts that have never turned on Google Cloud billing before.

If you, or a version of you two years ago, ever switched on Google Cloud billing for some forgotten project, you’re not eligible for the free Starter Tier.

(I know. It feels backwards to punish the people who tried things before. But that’s the rule right now.)

The fix is not scary: you deploy to your own Google Cloud project instead, which just needs a billing account attached.

And remember, thanks to Cloud Run’s free allowance and scale-to-zero, “billing attached” does not mean “you’re being charged.”

It means the meter exists but likely reads zero for a small app.

(Set a spend cap if it helps you sleep. AI Studio and Google Cloud both let you cap spending so a surprise can’t happen. Belt and suspenders.)

Snag 2: Your app is slow the very first time someone opens it after a while.

This is the “cold start” I mentioned.

Your app went to sleep to save you money. The first visitor wakes it up, and that wake-up takes a few seconds.

To the visitor it can feel like the page is being lazy.

The honest fix for a brand-new app: don’t worry about it yet.

A few seconds of wake-up is a completely fine trade for “free while nobody’s using it,” and for your first published thing, it truly doesn’t matter.

(When you have real, constant traffic, there are settings to keep it awake. That’s a good problem to have, and a later article. Cross that bridge when strangers are actually lined up on it.)

There’s one more piece worth knowing exists, even though we won’t set it up today.

Google baked Firebase support right into this same build flow.

Firebase is Google’s kit for the grown-up stuff: real logins, a database, file storage, all from inside AI Studio.

(You already met this idea with Supabase. Firebase is Google’s own flavor of the same thing, and now it sits right here in the same screen. We’ll give it its own week, because it deserves one.)

I’m flagging it now so that when you’re ready to add “sign in with Google” to your published app, you know the door is already in the room.

Where this falls short (being honest).

I don’t like tutorials that pretend everything is perfect.

So here’s the real stuff.

The free tier reads your prompts. On the free Gemini tier, Google may use your prompts to improve their models. For a silly encouragement app, who cares. For anything with private or sensitive data, don’t put it on the free tier, use a paid, privacy-guaranteed path instead. Know this before you publish something personal.

“Live” is not the same as “a business.” A published link means the world can open your app. It does not mean the app is safe, tested, or ready for a thousand real users with real money. Publishing is the start of the responsibility, not the end of it.

Buttons will move. Google renames and relocates these things every few weeks. If a label in this article doesn’t match your screen exactly, the spirit is still right: find the publish action in the top right, follow the boxes, get your URL.

Cold starts are real. Free-while-sleeping is a genuine trade, and for busy apps you’ll eventually pay to keep it awake. That’s fine. It just isn’t free-forever-at-any-scale, and I won’t pretend it is.

None of these should stop you from publishing today.

All of them should stop you from thinking a live URL means you’re done.

The link is the easy part. Sending it is the brave part.

Nobody paid me to write this.

Google doesn’t know I exist, and Cloud Run isn’t slipping me a check for every founder who clicks Publish.

I just build these things every week, and getting the app to a real link used to be exactly where I watched good people quit.

Now it’s a button and a coffee.

If this got your app out of the goldfish bag and into a pond with an address, do the one thing that keeps a small newsletter alive.

People read this because someone they trusted forwarded it to them. Be that someone for a founder whose best app is still trapped on their laptop.

Share

And if a stranger sent you this one, thank them, then subscribe so the next build finds you too.

Subscribe now

Save this: your publish checklist.

1. Open aistudio.google.com, sign in, open your app.

2. Find “Publish” in the top-right corner.

3. Click Publish → Get Started (first time only) → Publish App.

4. Wait a few minutes. Do not refresh.

5. Copy your

https://...run.app

1. link. Text it to one person.

2. To update: change the app in plain English, click Publish again. Same link, new version.

3. Free tier = ~2 million requests a month and it sleeps when idle. If it asks for billing, you deploy to your own project (still basically free for a small app). Set a spend cap for peace of mind.

PS: If you publish something today, even the silly encouragement-button app, reply and send me the link. I open every one. There’s a specific kind of joy in clicking a stranger’s very first live URL, and I’m not too cool to admit I collect them.

Not a page that just sits there.

A thing that does a job, that you and other people actually use.

New here? Subscribe and the next build lands in your inbox. [Subscribe]

On Tuesday I showed you what Claude Code is, and made you build a silly “hello” page so the fear would leave.

Today we build something you’ll keep.

I’ll be honest about what it is, because I already made it.

It’s called LogoGrid, and it drops any logo onto 20 real backgrounds at once, so you can see where the logo dies before your customers do.

(you can play with the finished one right now: https://logogrid.prompts2products.com/ )

It goes like this:

1. Open the desktop app and start a fresh folder. (thirty seconds)

2. Describe the tool in plain English. (one paragraph, I’ll give you mine)

3. Watch Claude write the whole thing as one file.

4. Open it and drop in a logo. (the first “whoa” moment)

5. Add the backgrounds that actually break logos, the 50% gray, the busy photo, the gradients.

6. Add live sliders so you can tune size and padding and watch every tile update.

7. Make it private and portable, one file, nothing uploaded, works offline.

Every step has a picture.

I’ll point at the screen the whole way.

But first, here’s what it looks like once it works:

Here is an example with a different logo:

Two things before we start:

1. Block twenty minutes this week and actually do it. Reading isn’t building.

2. Send this to one founder or designer who’s ever approved a logo on a plain white square.

Sharing keeps this newsletter alive. It’s the one free thing that helps me most.

Share

Why I trust this exact build

I didn’t pick a random demo for you.

I built LogoGrid because I kept approving logos on a clean white artboard, then watching them fall apart on a dark hero image or a yellow ad.

So I made the thing I wished existed, in one sitting, with Claude.

Then I put it online at logogrid.prompts2products.com so anyone can use it. (go drop a logo in, it’s free and nothing you upload ever leaves your browser.)

The version we build together today is the heart of it.

Not the fancy final polish, the core that makes it useful.

Once you can build this, you can build almost any small single-purpose tool you’ve been wishing for.

That’s the real gift here.

Not one tool.

The knack for making your own.

1. Open the app and start a clean folder.

Let’s set the table before we cook.

Step 1: Open the Claude desktop app on your computer.

Step 2: Along the top, find the tab that says “Code.” Click it.

Step 3: It will ask which folder to work in. On your desktop, make a brand new empty folder called logogrid, and choose that one.

(brand new and empty, always. Claude can touch everything in that folder, so we keep it boring on purpose. It’s a seatbelt, not a rule someone made up.)

Step 4: You’ll see an empty session with a chat box at the bottom. That chat box is your whole control panel.

That’s the setup.

Took longer to read than to do.

2. Describe your tool like you’re texting a designer.

Here’s where people freeze, so let me hand you the words.

You don’t need fancy language.

You need to say what the tool does, and what you should be able to do with it.

Step 1: Click into the chat box.

Step 2: Paste this in. You can use it exactly as is.

Paste this into the Code tab:

Build me a single-page tool as one HTML file called index.html.

The tool is a "logo background tester". It lets me test how a logo looks on many backgrounds at once.

How it works:
1. There is a drop zone where I can drop or select an image file (a PNG or SVG logo).
2. Once I add a logo, show that same logo repeated across a grid of 20 tiles.
3. Each tile has a different background, so I can see how the logo holds up on each one.
4. For now use these backgrounds: white, off-white, light gray, 50% gray, dark gray, black, and a few brand colors.

Keep it clean and modern, lots of white space, tidy grid.
Everything must run 100% in my browser. Do NOT upload the image anywhere. No servers, no accounts.
Keep all the code in one file so it is easy to open.

Step 3: Read it once, then hit enter.

(read what you’re sending. You’re the one with taste here. Claude just has hands.)

Step 4: Watch the panel. Claude will think out loud, then write a file.

You’ll see it create index.html in your folder.

3. Open it and drop your first logo.

This is the good part.

Step 1: Open your “logogrid” folder on your desktop.

Step 2: Find the file called index.html.

Step 3: Double-click it. It opens in your browser.

Step 4: Drag a logo file onto the drop zone, or click to pick one. (a transparent PNG or an SVG works best, but any image is fine to test with.)

Watch the grid fill with your logo, sitting on every background at once.

Now, it probably isn’t perfect yet.

Some tiles might be too plain.

The logo might be too big or too small.

Good.

That’s exactly what the next steps are for.

4. Add the backgrounds that actually break logos.

A logo looks fine on white.

That’s not the test.

The test is the mean backgrounds, so let’s add them.

Go back to the Code tab and type these, one at a time, refreshing your tool after each.

After each one, switch to your browser and refresh. (just the normal refresh button, same as any website.)

You’ll watch the grid get more honest with every addition.

(one change at a time is the secret. Ask for ten things at once and you won’t know which one broke something. Slow is smooth.)

5. Add live controls so you can tune it.

Right now the logo is one fixed size.

Real testing means nudging it and watching everything react.

Step 1: In the Code tab, type this:

Step 2: Refresh, drag the slider, watch all 20 tiles resize together.

Step 3: Add a second control.

Step 4: One more, for how the logo fits.

Refresh after each and play.

You now have the working core of LogoGrid.

This is the exact kind of half-built, “I made a real tool and I want it to feel finished” project people bring to the live Claude workshop in the community, and we polish and ship it together on the call, on your actual tool, not a demo one.

Grab your early bird seat

6. Make it private and portable.

Here’s a quiet feature that matters more than it sounds.

Your unreleased logo never leaves your computer.

Because everything runs right there in your browser, nothing gets uploaded anywhere.

Let’s make sure, and make it easy to keep.

Step 1: In the Code tab, type:

Step 2: Ask it to travel well.

Step 3: Refresh and read that little line at the bottom.

That line isn’t just decoration.

It’s the reason a designer will trust it with a brand that hasn’t launched yet.

7. Three upgrades that make it look expensive.

The core works.

Now let’s make it feel like a product a studio shipped.

These are three asks, one at a time, in the Code tab.

Upgrade 1: click a tile to zoom in.

Now you can really inspect the tricky ones.

Upgrade 2: download a single tile.

That turns a test into a shareable mockup in one click.

Upgrade 3: a “remove background” helper.

(this one is the fanciest, so if it gets fussy, leave it for the workshop. It’s a great “let’s do the hard bit together” piece.)

A gentle warning so you don’t fall down a hole.

You could keep tweaking this forever.

Don’t.

Pick a moment, decide it’s good enough, and go test a real logo with it.

A tool used once beats a perfect tool used never.

(I have lost whole evenings to “just one more tile.” Learn from my evenings.)

When things go sideways (the three I see most).

You’ll hit a bump. Everyone does. Here’s the fix for the common three.

The grid is empty after I drop a logo. Go back to the Code tab and type, plainly:

Then refresh. It reads its own work and repairs it nine times out of ten.

You asked for ten changes and now it looks worse. Type:

Then go back to one change at a time. Batching is what bit you, not you.

It “finished” but you don’t see the file. Make sure you’re looking inside the exact “logogrid” folder you picked at the start, not your general Desktop. The file is named index.html. If it truly isn’t there, ask:

Where this falls short (being honest).

This is a real tool, but let me keep it straight with you.

The remove-background trick is basic. It knocks out a solid color, not a messy photo behind your logo. For a clean PNG or SVG it’s fine. For anything fancier, you’ll want a proper cutout first.

It lives on your computer, not the internet. Right now only you can open it. Putting it at a real link a stranger can visit is a separate step. (that’s the natural next build.)

It can drift if you over-ask. Long sessions and giant requests are where it gets sloppy. Small, clear, one-at-a-time requests keep it sharp.

It costs to run. Claude Code needs a paid Claude plan, so there’s a monthly cost behind all this. (the entry paid tier.)

None of that takes away from what you just did.

You built a real, useful tool by describing it.

That was science fiction a couple of years ago.

The tool is real. Go put a logo in it.

Nobody pays me to point you at Claude, or at my own tool.

I build software for a living and I teach founders who don’t, and the honest truth is I made LogoGrid because I needed it, then realized how fast it came together.

A tool like this used to mean a brief, a freelancer, and a week of back and forth.

This morning it was a paragraph and a few opinions.

If that lands for you, the kindest thing you can do is forward this to the one designer or founder who’s ever shipped a logo that vanished on a dark background.

Share

And if someone forwarded you this one, welcome, go drop a logo into the real thing at https://logogrid.prompts2products.com/ , then subscribe so the next build shows up for you too.

Subscribe now

SAVE THIS, the tool recipe:

1. Open the Code tab, pick a new empty “logogrid” folder.

2. Describe the tool in one paragraph (steal mine).

3. Open index.html, drop in a logo.

4. Add the mean backgrounds: 50% gray, photos, gradients.

5. Add size and padding sliders and a contain/cover toggle.

6. Keep it local: nothing uploads, one file, works offline. (Bonus: click to zoom, download a tile, remove-background toggle.)

PS: Go test one real logo in it before you close the tab. Preferably one you already approved on a white artboard. If it survives the 50% gray tile, it’s a keeper. If it doesn’t, you just saved yourself an embarrassing billboard.

Not a mockup.

A thing that runs, that opens in a browser, that a stranger can actually use.

New here? Subscribe so the next build lands in your inbox. It’s free.

The tool almost every list crowned as the best builder of 2026 has a slightly scary name.

Claude Code

For two years it lived in a black box on a screen that looked like something only hackers touch.

That part is over.

It goes like this:

1. Claude Code is the same Claude you already chat with, just pointed at the files on your computer. (yes, the same one)

2. It used to live only in the terminal, that black text screen that scares normal people. (it scared me too)

3. In 2026 it got a proper desktop app with buttons and panels, so you never have to see the scary screen.

4. You type what you want in plain English, the way you’d text a friend who happens to build software.

5. It writes the actual files, saves them on your computer, and you open the result.

That’s the whole idea.

I’ll show you what it looks like, with screenshots, and I’ll be honest about where it’s still rough.

But first, here’s what “I built this with Claude” actually looks like:

Two things before we start:

1. Save this, you’ll want it when you finally open the app yourself.

2. Send it to one founder who keeps saying “I’d build it if I could code.”

Sharing is free, and it’s the nicest thing you can do for a small newsletter (and for me).

Share

First, why I avoided this thing for a year

I’m a developer.

I’ve been shipping software for years, and building products is the work I do every day.

So when Claude Code landed, it was an easy yes for me. (developers ran toward this thing.)

That’s not the part I avoided.

The part I avoided was telling you about it.

Because every single screenshot of Claude Code was a black screen covered in file paths and little green text, and I teach founders who don’t write code.

I knew exactly what that screenshot would do to you.

It would make you quietly close the tab.

It looked like a cockpit.

(It’s the same reason half the founders I work with still believe building is “not for them.”)

Here’s the thing those screenshots never told you.

The person typing into that scary screen often isn’t writing code either.

They’re typing plain sentences, the same way you talk to Claude in a normal chat.

Everything technical on the screen is just Claude narrating its own work as it goes, the way Artifacts already do when you watch them build something live.

(I wish someone had put it that plainly a year ago, before a thousand intimidating screenshots taught a thousand founders to look away.)

So I waited until the tool caught up to the people I teach.

In 2026, it finally did.

If you’ve ever thought “that’s clearly a developer thing,” this newsletter is me leaning over and whispering that you don’t have to be one anymore, and that the live Claude workshop I run inside the community is the room where I sit next to founders while they cross that exact line for the first time (I’ll drop the date at the end, so keep reading).

1. So what is Claude Code, in human words?

Claude Code is an agentic tool.

That word sounds expensive, so let me translate it.

(agentic just means it can take actions on its own, not only answer questions. It can open files, write them, and run things, instead of just talking back.)

Regular Claude lives in a chat window.

You ask, it answers, and anything it builds sits inside that chat until you close the tab.

Claude Code lives on your computer instead.

You point it at a folder, the same way you’d hand someone a drawer and say “work in here.”

From that moment, it can see the files in that folder, create new ones, and change them for you.

So when you say “build me a simple page with a signup box,” it doesn’t just describe the page.

It writes the real file, drops it in your folder, and you double-click it to open it.

That’s the leap.

Regular Claude gives you the recipe.

Claude Code cooks the meal and leaves it on your counter.

2. The thing that changed in 2026 (and why I’m writing this now)

Claude Code launched back in early 2025, and for a long time it was terminal only.

That’s why every screenshot looked like a hacker movie.

Then, in April 2026, a fully redesigned desktop app landed for Mac and Windows.

This is the part that matters for people like us.

Inside that app there’s a tab called Code, and it gives you panels, buttons, and a normal chat box.

You type your request into the chat box.

You watch it work in a panel.

You never have to memorize a single command.

A designer who openly calls himself a non-coder tried it recently, asked it to build a small color tool, and a working file appeared in his folder a minute later.

No code typed.

That’s the whole reason this is worth your Tuesday.

The tool stopped being a developer-only thing and quietly became a “anyone with an idea” thing.

(And honestly, it’s the same shift that happened with Artifacts last year, just with the results landing on your actual computer instead of inside a chat.)

Fifteen seconds of me typing a sentence and a real file showing up. I still find this a little magic.

3. Okay, but what would a founder actually build with it?

Not everything needs to be the next big SaaS.

The best first builds are small and boring and useful.

Here’s the kind of thing real founders make in a sitting.

A simple landing page for an idea you want to test this week.

A little internal tool, like a calculator that does your weird pricing math so you stop doing it in your head.

A quick form that collects answers from your first ten customers.

A tiny dashboard that shows you one number you care about.

None of these need a developer.

All of them used to.

That’s the gap that closed.

(I’m a little sorry for the freelancer I would have paid for the pricing calculator. Only a little.)

4. Your tiny first step (do this one thing today)

I’m not going to make you build the whole app today.

That’s Thursday’s job.

Today I just want you to make friends with the tool, so the scary feeling is gone before we start.

Here’s the smallest possible step.

Step 1: If you have a paid Claude plan, open the Claude desktop app. (if you don’t yet, no rush, just read along today.)

Step 2: Look along the top for the tab that says “Code.” Click it.

Step 3: When it asks for a folder, make a brand new empty folder on your desktop called “claude-test” and pick that one. (empty on purpose, so nothing important is ever at risk.)

Step 4: In the chat box at the bottom, type this exact sentence:

Step 5: Watch the panel. When it’s done, find the new file in your “claude-test” folder and double-click it.

That’s it.

You just made a webpage by typing one sentence.

It’s a silly page.

That’s the point.

The silly page is how the fear leaves.

Where this falls short (being honest).

I’d be a bad friend if I only showed you the magic.

It needs a paid Claude plan. Claude Code isn’t on the free tier, so there’s a monthly cost to use it at all. (it’s the entry paid plan, and I flagged the exact price for myself to keep current.)

It can make a mess if you let it. It has real access to the folder you give it, so I always start it in a brand new empty folder. There are real stories of people pointing an AI agent at something important and losing work. A throwaway folder is your seatbelt.

It’s confident even when it’s wrong. It’ll happily build the wrong thing with total enthusiasm. You stay the boss. You check.

It’s not always the simplest path. For a lot of small things, plain Claude with Artifacts does the job inside a chat with even less fuss. Claude Code shines when you want the result to be a real file on your computer that you’ll keep building on. (which is exactly where Thursday is headed.)

None of these are dealbreakers.

They’re just the honest fine print.

If the scary screenshot kept you out too, we’re even now.

Nobody pays me to say nice things about Claude.

I just build with it every day as a founder, and the black-terminal screenshot is the single thing that kept me out the longest.

So if it kept you out too, that’s the whole reason this one exists.

People read these because someone they trust forwarded it.

If this lifted the lid for you, be that person for someone still staring at a cockpit screenshot thinking “not for me.”

Share

And if a stranger sent you this, hi, thank them, then subscribe so Thursday’s build finds you too.

Subscribe now

SAVE THIS, the five-second version:

1. Claude Code is just Claude, pointed at a folder on your computer.

2. It writes real files for you, you don’t write code.

3. The 2026 desktop app means you skip the scary terminal (Mac and Windows).

4. Always start it in a brand new empty folder.

5. Your first step today: make the silly “hello” page. That’s it.

PS: The live Claude workshop where we do this together, in the same room, at the same time, is happening this week inside the community.

Master Claude Part 1: The Foundation

Master Claude Part 2: The Power Tools

If “I’d build it if I could” has been your line for a year, that’s the room where the line finally changes.

“Firebase Studio is sunsetting.”

That word, sunsetting, is a very calm way of saying “this is going away.”

And if you built your little app inside Firebase Studio, your first thought was probably the same as mine: wait, is my whole thing about to vanish?

Short answer: no.

Your app is fine.

Your data is fine.

But there is one small thing worth doing this week, and I am going to walk you through all of it in plain words.

It goes like this:

1. What is actually closing (it is smaller than the panic suggests)

2. The three dates that matter (one already passed)

3. The one thing to do today: back up your work

4. Where you go next (your two doors, both from Google)

I will walk you through each one, with screenshots, like we are sitting at the same table.

But first, here is the thing that caused all the worry in the first place:

Two things before we start:

1. Save this email. You will want the dates in one place.

2. Send it to one friend who built something in Firebase Studio and is quietly freaking out.

Sharing costs nothing, and it is how this little newsletter keeps growing.

Share

Quick, who am I to tell you not to panic.

I have been building things for seven years, and the last two of those without writing real code, just describing what I want to AI and shipping it.

I have lived through a lot of “this tool is going away” emails.

The first one I ever got, years ago, I genuinely thought I had lost a client project.

I sat there refreshing the page like that would help.

(It does not help. I can confirm.)

Here is the honest reason I am writing this one.

When that Firebase Studio email went out, the people who messaged me were not developers.

They were the exact people I teach: a bakery owner who built a little booking tool, a coach with a habit tracker, a mom running a tiny shop.

People with 400 unread emails and no time to “learn cloud infrastructure,” who just want the thing they made to keep working.

That is the whole reason I wrote a small book this month, called Hey Claude, for that exact person: the one who opens AI, gets one weird answer, and closes the tab.

It starts at the very first screen, no account yet, and walks you up to building a small tool just by describing it.

If a scary Google email is what brought you here, that book is the warm, no-tech-speak place I wish I could hand every one of those people.

(It is short, and it is cheap, and it is linked at the very bottom.)

Okay. Deep breath. Let me show you what is really going on.

1. First, what is actually closing (it is smaller than the panic suggests).

Here is the part nobody explained clearly, so people assumed the worst.

There are two different things that both have “Firebase” in the name, and only one of them is going away.

Think of it like a workshop and a warehouse.

Firebase Studio is the workshop.

It is the room where you described your app to the AI and watched it get built in your browser.

That workshop is the thing closing.

Firebase (the regular one) is the warehouse.

It is where your app’s data lives, your users’ logins, the actual hosting that keeps your app online.

That warehouse is staying open.

Google said it plainly: core services like the database (Cloud Firestore), the login system (Authentication), and the hosting (App Hosting) will keep working normally

So if you built an app in Firebase Studio, the building you did it in is being torn down.

But the app itself, and everything it remembers, lives somewhere else, and that somewhere else is staying.

You just need to move your project out of the workshop before the doors lock.

If a friend of yours is panicking right now, this section alone will calm them down. Send it.

Share

2. The three dates that matter (one already passed).

I am going to give you three dates and nothing else, because three is all you need

Let me say each one like a human.

March 19, 2026. Google announced it and turned on the tools to move your stuff out. That is the starting gun.

June 22, 2026. New people can no longer sign up for Firebase Studio. If you already have a workspace, it still opens and works.

(This one already passed, by the way, so if you tried to make a brand new Studio project and could not, that is why. It is not you.)

March 22, 2027. This is the one to circle. On this day Firebase Studio shuts off, and anything still left inside is permanently deleted and cannot be recovered.

So you have months, not minutes.

This is not a fire drill where you sprint.

It is a “do the small safe thing now so you are not doing it stressed in March” situation.

3. The one thing to do today: back up your work.

Everything above was so you would not panic.

This is the one small action that means you never have to panic again, even if you do nothing else for months.

You are going to make a copy of your project and save it to your computer.

That is it.

A backup is just a “if all else fails, I still have my stuff” insurance file.

(And it is free, and it takes about two minutes.)

Here is the whole thing, click by click.

Step 1: Open your Firebase Studio workspace in your browser. Sign in if it asks.

Step 2: Look at the very top of your workspace. You are looking for a button that says Move now. Click it

Step 3: A window pops up with options. Look for the choice that says Zip and Download. Click it.

(A “zip” is just a single packed-up folder with all your files inside, like putting everything in one suitcase. Easy to carry, easy to keep.)

Step 4: Your browser downloads a file.

It might land in your Downloads folder. That packed-up file is your backup. Drag it somewhere you will remember, like a folder called “My App Backup.”

The whole backup, start to finish. It really is just two clicks and a download.

Now, one gotcha, because I would rather you hear it from me than get stuck.

Sometimes you click and nothing happens.

That is almost always your browser blocking a pop-up.

Look at the right side of your address bar for a little “pop-up blocked” icon, click it, choose “always allow,” and click the button again.

(Ask me how I know. We do not talk about that afternoon.)

There is one bonus backup if you want it: your chat history with the AI agent.

Your conversations are not inside that zip by default.

To grab them, in Firebase Studio go to File, then Open Folder, accept the default folder it offers, then right-click the folder named .idx/ai and choose Zip and Download.

If it asks to rebuild, click Cancel.

(Totally optional. Skip it if you never need to re-read your prompts.)

That is the whole job for today.

You are now safe no matter what happens next.

4. So where do you actually go next.

Backing up is the safety net.

Actually moving your app to its new home is the next step, and Google gives you two doors.

I am only going to introduce them today, because each one deserves a full walk-through, and that is what the rest of this week is for.

Door one is Google AI Studio. It lives in your browser, there is nothing to install, and it is the gentlest path. If you built your app by just describing it and watching it appear, this is almost certainly your door.

Door two is Google Antigravity. It is a free app you download onto your computer, and it gives you more control and more power. It is the path for when you want to keep building something serious.

You do not have to decide this second.

You just need to know both doors exist, and that I am walking you through each one.

The full step-by-step for door one (AI Studio) is this Thursday.

The full step-by-step for door two (Antigravity) is this Sunday.

Both are paid, because they are the complete “do this and your app is safely living in its new home” walk-throughs, every click, every gotcha.

Today, free, you got the part that matters most: don’t panic, and back up.

Where this falls short (being honest).

A few real things, because I would rather you trust me than think this is magic.

It is still a move, and moves are annoying.

Even the easy door has a few steps. I am not going to pretend you click one button and you are done. (That said, it is closer to that than you fear.)

Shared workspaces are trickier.

If someone else made the Firebase Studio project and just shared it with you, only the original owner can use that “Move now” button. You can still save a copy of the code, but the login and database settings will still point at their account, not yours. If that is your situation, flag it now, it needs an extra step.

This is Google, and Google moves things.

I will be honest, the reason we are all here today is that Google closed a tool. The two doors I am sending you toward are also Google. I think they are the right call right now, and they are free and well supported, but nothing in tech is forever, which is exactly why backing up is a habit, not a one-time thing.

You did the scary part already.

I am not here to sell you a panic.

The whole internet is very good at selling you panic, and I would rather hand you a calm next step.

The truth about that Firebase Studio email is boring in the best way: your app is fine, your data is fine, you have months, and the only urgent thing was a two-minute backup you just learned how to do.

People read this because someone they trust forwarded it to them in a small moment of stress.

If it calmed you down, be that person for someone else who got the same email.

Share

And if a friend sent you this one, thank them, then subscribe so the next “wait, what do I do now” guide finds you before the worry does.

Subscribe now

SAVE THIS (the whole thing in five lines):

1. Firebase Studio (the workshop) is closing. Firebase (your data, logins, hosting) is staying.

2. The date that matters: March 22, 2027. After that, anything left is deleted.

3. Today’s only job: open your workspace, click “Move now,” click “Zip and Download.” That is your backup.

4. If the download does nothing, allow pop-ups and try again.

5. Two doors out, both free: Google AI Studio (easy, browser) and Google Antigravity (powerful, app). Walk-throughs this week.

PS: If a scary tech email is the reason you are reading this, and you have been quietly avoiding “learning AI” because every guide is written for engineers, my little book Hey Claude is the opposite of that.

It starts before you even have an account and walks you up one tiny step at a time. It is short on purpose, because you are busy, and I know.

Link is on my profile and in the shop. No pressure, it will be there when you want it.

Get one now

Firebase Studio is shutting down, and Google is funneling everyone toward Google AI Studio.

So this week, a lot of people are going to open a tool they’ve never really used and try to build something in it.

I’ve been in there since the I/O updates dropped.

I want to save you the fumbling.

This is the full walk.

Idea to a live URL, in the browser, free to start.

Five steps.

Every prompt written out.

Every place I’ve watched people get stuck, marked.

Let’s build.

1. The whole thing, before we touch anything.

Here’s the shape of what we’re doing, so you’re never lost:

Step 1: Describe the app so Studio builds the right thing the first time

Step 2: Iterate in plain language until it works the way you meant

Step 3: Add a backend so the app actually remembers things

Step 4: Deploy so it lives at a real URL anyone can open

Step 5: The weekly loop so you can keep improving it without breaking it

The tool that makes this possible now: after I/O 2026, Google AI Studio takes you from an idea to a production-ready application without leaving the browser, with one-click deploy to Cloud Run and Gemini 3.5 Flash under the hood.

That last year’s version couldn’t do this.

This one can.

That’s why it’s worth learning now and not later.

2. Describe it right, or rebuild it three times.

This is the part that decides everything.

The single biggest reason AI-built apps come out wrong: the description was vague.

Vague prompts produce clever-looking code that does not do what you meant.

So we don’t start with “build me a habit tracker.”

We start with a real description.

Here’s the exact prompt structure I open Studio with.

Fill in the brackets and paste the whole thing into the Build tab:

Build me a web app. Here is exactly what it is and who it's for.

WHAT IT IS:
A [one-sentence description of the app].

WHO USES IT:
[Describe the one person who uses this. What's their day like? 
Why do they open this app?]

THE SCREENS:
1. [First screen, what they see when they land]
2. [Second screen, where they go next]
3. [Third screen, settings, history, profile, whatever applies]

WHAT IT NEEDS TO DO:
- [Action 1 in plain language: "let me add a thing"]
- [Action 2: "show me my list of things"]
- [Action 3: "let me delete a thing"]

WHAT IT SHOULD LOOK LIKE:
- Clean and simple. Lots of white space.
- [One reference: "like a notes app" / "like a simple dashboard"]
- Works well on a phone.

DO NOT:
- Add features I didn't ask for
- Add a login system yet (we'll do that later)
- Use complicated language in the interface

Build the simplest version that does these things. 
We'll improve it after I see it.

Notice the last two lines.

“Simplest version” and “we’ll improve it after I see it.”

That stops the AI from over-building and handing you a tangle you can’t follow.

Read more

About 5,000 of them were leaking real data. Medical records. Bank financials. Customer chat logs.

A hospital app with doctor-patient conversation summaries sitting open on the public internet.

None of those founders meant to do that.

That’s the part that keeps me up.

Not the hackers.

The fact that the people building these apps had no idea anything was wrong.

They shipped, they celebrated, and the door was open the whole time.

This article is about why that happens to people who aren’t developers, and the one thing you can check today so it doesn’t happen to you.

1. Nobody told you the door was open.

Here’s what the scan actually found.

In early May 2026, an Israeli cybersecurity firm called RedAccess found about 380,000 publicly accessible applications created with tools like Lovable, Base44, Netlify, and Replit, and around 5,000 of them were leaking sensitive corporate and private data, including medical records, financial information, and business documents.

Read that again. Publicly accessible. Not hacked. Not broken into.

Just open.

The reason is almost stupid in how simple it is.

Privacy settings on some of these tools were set to make the apps publicly accessible unless users manually changed them to private.

So the default is “anyone can see this.”

And if you don’t know that setting exists, you never flip it.

The mistake most people make:

They think shipping the app is the finish line.

You describe what you want.

The AI builds it.

You get a live link.

It works.

You send it to a friend, a client, a few early users.

But “it works” and “it’s safe” are two completely different checks.

The app working means the right people can use it.

The app being safe means the wrong people can’t.

Most tutorials only teach you the first one.

And it’s so common it’s almost not even your fault.

2. Why this hits non-technical founders hardest.

A developer has a reflex.

Before they ship, a little voice asks: who can see this, who can change this, what happens if a stranger finds the link?

You weren’t trained to have that voice.

That’s not a flaw in you.

It’s just not the muscle you built.

The RedAccess CEO said something that stuck with me.

He said his own mother is vibe coding with Lovable, and he doesn’t expect her to think about role-based access control.

He’s right.

And that’s exactly the problem.

The tools were built for people who don’t think about that stuff, and then they ship with the unsafe option turned on.

There was a real example this year.

An app called Moltbook launched, built entirely with AI prompts, no code written by hand.

Within three days, researchers found a Supabase API key exposed in client-side JavaScript without Row Level Security enabled, and that single oversight granted unauthenticated access to the entire production database.

One setting.

The whole database, open.

If you read my Supabase article, you already know what Row Level Security is.

This is why it matters.

It’s not a nerdy extra step. It’s the lock on the door.

3. The good news: this is fixable in an afternoon.

I don’t want you to close this article scared.

Fear isn’t useful.

A checklist is.

The reason these leaks happen is that the safe steps are invisible.

So let me make them visible.

There are five things that protect almost any app a non-technical founder ships.

I’ll walk you fully through the first one right now, because it’s the one that catches the most leaks.

The first step: turn your app private, then prove it.

This is two moves, not one.

Setting it private is the move everyone thinks they did. Proving it is the move that catches the times you were wrong.

Here’s a prompt I use to make the AI builder check its own work instead of just telling me it’s fine.

You are acting as a security reviewer for an app I built without writing code.

I am not a developer. Explain everything in plain language, no jargon, 
and assume I will not understand any term you don't define in one sentence.

Here is what I need you to do, in this exact order:

1. Tell me whether this app is currently set to PUBLIC or PRIVATE, 
   and exactly where in the settings I can see that myself.

2. Tell me whether someone who is NOT logged in can see any of my data. 
   If yes, list exactly which data is exposed.

3. If my app uses Supabase or Firebase, tell me whether Row Level Security 
   (or Firebase Security Rules) is turned ON for every table that holds 
   user or private data. List any table where it is OFF.

4. Give me a simple before-and-after: what a stranger can see right now, 
   versus what they should be able to see.

5. Then give me the exact steps, click by click, to lock down anything 
   that is currently exposed. Number the steps.

Do NOT reassure me that it's "probably fine." 
Assume I made a mistake somewhere and your job is to find it.
Start with item 1.

Paste that into whatever you built your app in, Lovable, AI Studio, Firebase Studio… and make it audit you.

If this is useful, send it to one founder who’s about to launch something.

Share How to Vibe Code With AI

4. The other four pieces.

Going private is step one. It’s the biggest one. But a real lockdown has five parts, and I want you to at least know the map even if today you only walk the first road.

Here are the five, named plainly:

One: Private by default. What we just did. The app and its data are not visible to logged-out strangers.

Two: Row Level Security on every table. Even logged-in users should only see their own rows. Not everyone else’s. This is the Moltbook lesson.

Three: Keys in the right place. Your secret keys live on the server side, never pasted into anything a visitor’s browser can read. The Moltbook leak was a key in the wrong place.

Four: Auth that actually gates. “Sign in” should mean something. A login screen that doesn’t truly block the data behind it is just a costume.

Five: A pre-launch check you run every single time. Not once. Every ship. The same way you’d lock your front door every night, not just the night you moved in.

I’ll show you piece one fully: you have it above.

The complete walkthrough of all five, with the exact prompts for each, the Supabase and Firebase specifics, and the failure modes I’ve personally hit, is the kind of thing I take apart slowly with the community every week.

That’s where we actually build this together, not just read about it.

This isn’t me holding back the good stuff.

Going private genuinely protects you from the most common leak.

The rest is depth, and depth is what the community is for.

The thing I want you to remember.

You are not reckless for not knowing this.

The tools shipped with the unsafe option on.

The tutorials skipped it.

You did exactly what you were taught and the door was open anyway.

That’s not a character flaw.

It’s a gap in what anyone bothered to tell you.

Now you know.

Go check the one setting.

It takes an afternoon and it’s the difference between a hospital’s patient notes sitting safely in a database and sitting on the open web with a Google-indexable link.

You can build without code.

You can also protect what you build without code.

Both are learnable.

You just learned the first half.

Two ways to take this further, depending on what you need.

If you want to build this yourself, and lock down your apps properly alongside other non-technical founders going through the exact same thing, the community is where we do this every week.

We walk through the full five-part security check together, with the prompts and the real examples.

→ Join Prompts2Products

If you’d rather have someone build it for you, secured the right way from the start, my agency Arehsoft works with founders who want to go from idea to working, safe product.

→ Schedule a free consultation call

Both paths work. Just different timelines and different involvement.

Here’s the one I’d have killed to have when I started.

It’s the pre-launch security check from piece five, the thing you run before every single launch.

It just got added to the vault.

You are my pre-launch security checklist. I built this app without writing code.
I am about to make it live. Walk me through these checks one at a time, 
in plain language, and wait for me to confirm each before moving on.

App description: [paste what your app does and what data it stores]
Built in: [Lovable / Google AI Studio / Firebase Studio / other]
Database: [Supabase / Firebase / none / not sure]

Check 1 — Visibility: Is the app private? Can a logged-out stranger reach it?
Check 2 — Data access: Can a logged-in user see other users' data, or only their own?
Check 3 — Secret keys: Are any API keys or secrets visible in the browser? 
          Where should they be instead?
Check 4 — Login: Does signing in actually block the data behind it, 
          or is it decorative?
Check 5 — Indexing: Could Google or another search engine find and list this app?

For each check: tell me how to verify it MYSELF in my dashboard, 
what a PASS looks like, what a FAIL looks like, 
and the exact steps to fix a fail.

Be skeptical. Assume at least one check will fail. Find it.
Start with Check 1 and wait for my answer.

I’m not here to scare you into buying anything.

I share what I actually build with, what I actually check, what actually keeps founders who don’t write code out of a headline they never wanted to be in.

100s of founders read this because someone they trusted sent them an article.

If this one was useful, be that person for someone else.

Share

If someone sent you this, you can subscribe here:

Subscribe now

It was the most powerful model Anthropic had ever released to the public.

Launched on a Tuesday.

Free on the paid plans for a couple weeks.

By Friday it was gone.

Not slowed down.

Not quietly retired.

Switched off… for every single user on earth… three days after it launched.

I’m glad I didn’t hit publish.

But the real story here is better than the one I was going to write.

Because what happened to Fable 5 is the clearest lesson I’ve seen all year for anyone building a product without code.

And almost nobody is talking about that part.

1. What actually happened.

The plain-language version:

Anthropic released Fable 5 on June 9.

Their best, most capable model… the kind they’d kept locked away because it was too powerful to hand out freely.

Three days later, the U.S. government stepped in.

The Commerce Department issued an export-control order, citing national security.

The order blocked the model from being used by any foreign national, anywhere in the world, inside the U.S. or out.

Here’s the catch.

Anthropic had no way to check, in real time, who counted as a “foreign national” on every request.

So the only way to actually obey the order was to shut the model off for everyone.

Which they did, within hours.

The reported trigger?

Another company claimed it had broken through the model’s safety limits.

That spooked the government.

The order followed.

Anthropic says it disagrees with the decision.

It doesn’t matter.

The model is still gone.

And the detail that should stop you cold: every other Claude model still works.

Opus, the others, all fine.

Only the two most powerful ones vanished.

Read that twice.

The more powerful the tool, the faster it disappeared.

2. Why this should matter to you (and it’s not the reason you think).

You weren’t going to use Fable 5 for most of what you build.

I told you that last time and it’s still true.

Most of what a non-technical founder builds runs perfectly on free or cheap models.

So why does this matter?

Because of what it proves.

It proves that the model your product depends on can disappear overnight.

Not because it broke.

Not because the company chose to retire it.

Because of something completely outside anyone’s control, a government order, a legal fight, a policy that changes on a Friday.

Now imagine you’d built your app around Fable 5 over the weekend it launched.

Hardcoded it in.

Told your users it was the brain behind your product.

By Monday, your product is broken.

And not because of anything you did.

This is the quiet risk almost nobody warns founders about.

When you build with AI, the smartest part of your product is something you’re renting from someone else.

And renters can lose access without warning.

That’s the lesson.

Not “Fable 5 was cool.” It’s “never let one model be your single point of failure.”

3. The one habit that protects you.

The fix is simpler than it sounds.

You don’t need to be technical to do it.

You just need to build with one rule in mind:

Stay swappable.

Build so that if your model disappears tomorrow, you can switch to another one in minutes, not rebuild your whole product.

Here’s what that looks like in practice, for someone who doesn’t write code:

One: never marry your prompts to one model.

Write your prompts so they’d work with any capable model.

Don’t lean on quirks that only one model has.

If your whole product only works because of one specific model’s one specific trick, you’ve built on sand.

Two: always know your backup before you need it.

For every model you use, know the one you’d switch to if it vanished.

When Fable 5 went dark, the people who were calm already knew their answer: fall back to Opus, or to Gemini’s free tier in Google AI Studio, and keep moving.

The ones who panicked had never thought about it.

Three: keep your free option warm.

Gemini’s free tier didn’t get pulled.

Free, widely available models are the most resilient thing you can build on, precisely because there’s nothing dramatic to take away.

I keep one in every project as the floor I can always drop to.

Here’s a prompt to pressure-test your own setup right now:

I'm a non-technical founder. I want to find the single points of
failure in the product I'm building with AI.

Here's how my product works: [describe it in plain language —
what it does, and where AI is involved]
Here's the AI model or tool I'm currently relying on: [name it]

Tell me:
1. If that one model disappeared tomorrow, what exactly in my
   product would stop working?
2. Which parts depend on something only that specific model can
   do — versus things any capable model could handle?
3. What's the simplest free or low-cost model I could fall back
   to, and what would I lose by switching?
4. The 3 changes I should make now so a single model going away
   never takes my whole product down.

Keep it in plain language. No jargon. Assume I don't write code.

Run that today.

Whatever it flags is the work worth doing this week… far more than chasing whatever model is newest.

If this is useful, send it to one founder who’s building everything on a single model right now.

Share

4. The part everyone’s getting wrong.

There’s a loud reaction to all this.

“See? AI isn’t safe to build on. Wait until it settles down.”

That’s the wrong lesson, and it’ll cost you.

AI isn’t going to “settle down.”

Models will keep launching, changing, and occasionally disappearing.

That’s the weather now.

You don’t stop building because of weather.

You build for it.

The founders who win in this environment aren’t the ones who pick the perfect model.

They’re the ones who build so that no single model can hurt them.

Swappable prompts.

A known backup.

A free floor underneath everything.

That’s a full system, how to structure a product so it survives any one tool vanishing, how to keep your prompts portable, how to wire in a fallback without touching code.

The single-point-of-failure prompt above is the first piece of it.

The complete version, mapped onto a real product, is what we work through in the community every week.

Two ways to take this further, depending on what you need.

If you want to build this yourself: alongside other non-technical founders thinking through the same risks, the community is where we do this every week.

→ Join Prompts2Products: ($29.99/month)

If you’d rather hand it off, my agency Arehsoft builds products for founders the resilient way from the start, so a model going dark is never your problem.

→ Schedule a free consultation call

Both paths work.

Just different timelines and different involvement.

I don’t share things I haven’t tested.

This next prompt is my “model exit plan”, the one I now run on every project so I’m never caught flat.

It just got added to the vault.

Help me build a model exit plan for my product, so I'm never
stranded if an AI model disappears.

My product: [describe it]
The AI model I currently rely on: [name it]
My budget reality: [free only / a little / flexible]

Give me a simple one-page plan with:
1. PRIMARY — the model I use day to day, and why.
2. BACKUP — the next model I'd switch to immediately if the
   primary vanished, ranked by how close a replacement it is.
3. FREE FLOOR — the free model I can always fall back to, even
   if it's slower, so my product never fully stops.
4. SWITCH STEPS — the exact, plain-language steps to swap models,
   written so I could do it in under an hour under pressure.

No jargon. Assume I don't write code. Make it something I can
print and tape to the wall.

I’m not here to scare you off building with AI. The opposite.

I share what I actually build with, what I actually test, and what actually keeps founders safe when the ground moves, and last week, the ground moved.

People read this because someone they trusted sent them an article.

If this one was useful, be that person for someone else.

Share

If someone sent you this, you can subscribe here:

Subscribe now

In the spring, Google quietly moved its Pro models behind billing.

The free tier in Google AI Studio now covers the Flash and Flash-Lite models only.

If your app’s “brain” was calling a Pro model on a free key, it’s the kind of change that breaks quietly, and then you get a bill, or a wall of errors, at the worst possible moment.

Then in May, at Google I/O, they shipped Gemini 3.5 Flash.

And here’s the twist that makes this whole thing okay: the new Flash is so good it beats the old Pro on a lot of real work.

So the move isn’t “Google took away your good model.”

It’s “the cheap model got good enough that you don’t need the expensive one.”

This article is the practical version of that.

Which exact model to put in your app right now, what the free limits really are, and how to swap it in without breaking anything.

1. The two words that decide your whole bill: Pro and Flash.

Every Gemini model is one of two flavors.

• Pro = the big, deep-thinking brain. More expensive. Now paid-only on the API.

• Flash = the fast, cheap brain. Still free (with limits). Now shockingly capable.

For most things a non-technical founder builds, summaries, chat features, classifying things, pulling data out of messy text, answering questions about your own content.

Flash is the correct answer. Not the compromise. The answer.

People reach for Pro the way they reach for the large coffee: out of habit, “to be safe.”

Then they pay Pro prices to do Flash-sized jobs.

The new Gemini 3.5 Flash launched in May at roughly $1.50 per million words in and $9 per million words-out, and on coding benchmarks it actually edged out the previous Pro model.

It carries a huge context window (over a million tokens), so it can read a whole big document in one go.

Translation: the cheap one got smart. Stop overpaying.

2. What “free” actually means now (read this before you build).

“Free tier” is doing a lot of quiet work in that sentence.

Here’s the real shape of it.

• The free tier in Google AI Studio covers Flash and Flash-Lite only. Pro is paid.

• No credit card required to start.

• Free Flash usage runs in the neighborhood of ~1,500 requests per day… plenty for prototyping, a class project, a small app, or your first users.

• The catch worth knowing: free-tier traffic gets logged by Google to improve their products. Paid keys are not logged.

That last point is the one that actually matters for a real business.

Free is perfect while you’re building and testing.

But the day your app handles anything you wouldn’t want logged, customer data, private documents, anything regulated, that’s the day you move to a paid key.

Not because you ran out of free requests.

Because of privacy.

So the honest rule: build and launch your first version on free Flash.

Switch to a paid key the moment real private data flows through it.

3. Which exact model to pick (just tell me).

Fine.

Here’s the cheat sheet, current as of June 2026.

• Default for almost everything → Gemini 3.5 Flash (model id gemini-3.5-flash). Smart enough to replace last year’s Pro for most jobs.

• Highest-volume, dead-simple tasks (tagging, short classifications, quick rewrites) → a Flash-Lite model. Cheaper and faster still, and you won’t feel the quality drop on simple work.

• Genuinely hard reasoning where Flash visibly struggles → that’s the only time you reach for a paid Pro key.

  And test first, you’ll be surprised how rarely you need it.

Notice what’s not on this list: starting with Pro “to be safe.”

That habit is what turns a $0 app into a surprise invoice.

Start on Flash.

Earn your way up to Pro only when a real task proves you need it.

4. How to swap the model your app uses (without breaking it).

This is the part people are scared of.

It’s genuinely small.

Somewhere in your app there’s a line that names the model, it’ll say something like a model id in quotes.

Changing which brain your app uses is usually changing that one string.

But don’t go hunting by hand.

Have your AI builder do it safely:

My app calls the Google Gemini API. I want to switch the model
it uses to gemini-3.5-flash (Google's current free-tier Flash model).

1. Find every place in this project where a Gemini model is named.
2. List each one and tell me which file it's in.
3. Change them to gemini-3.5-flash.
4. Tell me if any of them were using a Pro model that is no longer
   on the free tier — those are the ones that would have started
   failing or charging me.
5. Confirm my API key is read from an environment variable (.env),
   not hardcoded.
6. Tell me how to test that each feature still works after the swap.

Don't change anything else. Show me a before/after for each line.

Run it. Test the features it lists. Done.

If you’ve got a friend running an AI app on Google’s free tier, send them this, they may not know the rules changed.

Share

5. The mistake that wastes free requests.

Here’s where founders burn through their daily limit and think “free tier is too small.”

It’s usually not the limit.

It’s waste.

Three things quietly eat your requests:

• Re-asking the same thing. If ten users ask your app the same common question, you don’t need ten model calls.

• Cache the answer once and reuse it.

• Sending the whole haystack every time. Stuffing a giant document into every single request burns your budget and slows everything down.

  Send only the relevant slice.

• Using a big model for a small job. A one-word “is this spam, yes or no?” doesn’t need your smartest brain.

Have your AI add a simple cache so repeated questions don’t each cost a request:

Add a simple caching layer to my app's Gemini calls.

1. Before calling the Gemini API, check if I've already answered
   this exact (or near-identical) request recently.
2. If yes, return the saved answer instead of calling the model.
3. If no, call the model, then save the answer for next time.
4. Keep it simple — store cached answers in my existing database
   (Supabase) with a sensible expiry.
5. Explain in plain English how much this will cut my API usage,
   and how to clear the cache if I need fresh answers.

Caching is the single highest-leverage thing you can do to stay inside the free tier longer.

Most apps repeat themselves far more than founders expect.

6. A free bonus most builders forget: the images are free too.

While we’re in the free-Google corner, your app’s pictures can come from here too.

Google’s image model, Nano Banana, is available free inside the Gemini app, and image generation is part of the same ecosystem you’re already in.

App icons, marketing graphics, placeholder images, social posts, you don’t need a separate paid design tool for the first version.

It’s the same principle as Flash: the free option is now good enough that paying is a choice, not a requirement.

Build the whole first version, brain and visuals, for close to nothing.

Pay when something specific earns it.

7. Now you own this.

The whole system, every time you build:

• Default to Flash (gemini-3.5-flash).

  Pro only when a real task proves you need it.

• Start on the free key.

  Move to a paid key the moment private data flows through.

• Cache repeated calls so the free tier lasts.

• Pull your images from the same free ecosystem.

Old way: reach for the biggest model, build on a key you don’t understand, get surprised by a bill or an outage.

This way: cheapest model that does the job, free until privacy says otherwise, waste designed out from the start.

You’re not cutting corners. You’re building exactly the way the people who watch their costs build.

Two ways to take this further, depending on what you need.

If you want to build this alongside other non-technical founders watching their costs the same way… the community is where we wire these up together every week.

→ Join Prompts2Products: the community ($29.99/month)

If you’d rather have a team build the whole thing for you, model, app, and all, my agency Arehsoft does exactly this.

→ Schedule a free consultation call

Both work. Just different timelines and different involvement.

“What should this feature cost?” prompt I run before wiring any model into an app:

Help me pick the cheapest Gemini model that will do this job well.

Here's the feature I'm building:
[describe what the feature does in 2-3 plain sentences]

1. Tell me whether this needs Flash, Flash-Lite, or genuinely
   needs a paid Pro model — and why, in plain English.
2. Estimate roughly how many API requests this might use per day
   at small scale, and whether that fits the free tier.
3. Tell me whether caching would meaningfully cut that usage.
4. Flag whether this feature will handle private user data — and
   if so, remind me to use a paid (unlogged) key, not the free one.

Default to the cheapest option that still does the job well.
Don't recommend Pro unless this clearly needs it.

I don’t recommend tools I’m not actually using.

I share what I build with, what I test, and what works for founders who don’t write code, especially the free stuff, because most of you don’t have a dev budget.

People read this because someone they trusted sent it to them.

If this one helped you keep your costs near zero, be that person for someone else.

Share

If someone sent you this, you can subscribe here:

Subscribe now

He said so publicly. Proudly.

Then security researchers found the database wide open.

Reports put it at around 1.5 million authentication tokens and tens of thousands of email addresses, readable by anyone who knew where to look.

The app was called Moltbook.

The breach wasn’t a clever hack.

It was a setting nobody turned on.

I’m telling you this not to scare you off vibe coding, I build this way every day.

I’m telling you because the exact mistake that took Moltbook down takes about fifteen minutes to prevent.

And almost nobody does it.

This is that fifteen minutes.

The minimum security review for any app you’re about to put on a real URL.

1. Why your AI builds things that leak.

Here’s the uncomfortable truth about the tools we love.

Your AI is optimizing to make the app run. It is not optimizing to make the app safe.

So it does the fastest thing.

It hardcodes your secret keys right into the code.

It sets your database to “anyone can read and write.”

It ships.

And it all works, which is exactly why you never notice.

Research on AI-generated code keeps landing in the same scary range: somewhere between 40% and 62% of it ships with a security flaw.

One scan of more than 1,600 apps built on a popular vibe-coding platform found roughly one in ten exposed real user data, names, emails, even financial records, because of one missing setting.

The setting has a name.

We’ll get to it.

The point for now: the bug isn’t you.

It’s that AI builds for “does it work,” and security only shows up when someone goes looking.

So you have to be the one who looks.

This is the part the AI assistant will never volunteer.

2. Step one: get your secrets out of the code.

A “secret” is any key, password, or token that proves your app is allowed to use a paid service.

Your AI loves to paste these straight into the code.

Especially into the part of the code that runs in the user’s browser, which means anyone can right-click, “inspect,” and read your key in about four seconds.

If that key controls billing, someone can run up your bill.

If it controls your database, someone can read everything.

Here’s the rule: secrets live in environment variables, never in the code.(Write it on a sticky note and post it to your computer)

An environment variable is just a labelled box your app reads from at runtime, kept separately from the code itself.

The file that holds them is usually called .env.

Use this prompt to make your AI do it properly:

Audit this entire project for hardcoded secrets.

Find every API key, token, password, database URL, or
credential that appears directly in the code.

For each one:
1. Tell me which file and line it's in.
2. Move it into a .env file as an environment variable.
3. Replace the hardcoded value in the code with a reference
   to that environment variable.
4. Confirm .env is listed in .gitignore so it is never
   uploaded to GitHub.

Pay special attention to anything in front-end / browser code,
and to any variable prefixed with NEXT_PUBLIC_ or VITE_ that
contains a real secret — those are exposed to the browser and
must NOT hold sensitive keys.

Show me a before/after for each change.

One thing this catches that people miss: in a lot of frameworks, any variable starting with NEXT_PUBLIC_ or VITE_ is deliberately shipped to the browser.

If your AI tucked a real secret behind that prefix, it’s not hidden at all.

The prompt above flushes those out.

3. Step two: the setting that sank Moltbook.

This is the one. Write it down.

It’s called Row Level Security, RLS, and it lives in Supabase (and any Postgres database).

Here’s RLS in plain English.

By default, when your AI sets up a database table, it can leave the door set to: anyone with the public key can read and write every row.

That’s fine while you’re the only user.

The second you have real users, it means User A can read User B’s private data.

Or a stranger can read everyone’s.

RLS is the rule that says: you can only see and touch your own rows.

The Moltbook database was left permissive.

The big platform scan found the same thing across hundreds of apps.

It is, by a distance, the most common way vibe-coded apps leak.

Turn it on with this:

I'm using Supabase. I want you to enable and configure
Row Level Security (RLS) for every table that holds user data.

For each table:
1. Turn RLS ON.
2. Write a policy so a logged-in user can only SELECT, INSERT,
   UPDATE, and DELETE their own rows (matched on their user id).
3. Block all access for anyone who is not logged in, unless I
   explicitly tell you a table should be public.
4. List every table, tell me whether it now requires login,
   and flag any table you left public so I can confirm that's
   intentional.

Do not assume any table should be public. Ask me if you're unsure.

After it runs, do the human check: read its list of “tables I left public.”

If your users, profiles, orders, or messages table is on that list, stop and fix it.

Those should never be open. (If you only do one thing from this whole article, do this one.)

4. Step three: stop using the master key.

Supabase gives you two keys.

One is the anon (public) key.

It’s designed to be seen, it’s basically a project name tag.

Safe to use in the browser as long as RLS is on.

The other is the service role key.

This is the master key.

It bypasses RLS entirely and can do anything to your database.

Your AI sometimes grabs the master key because it’s the easy way to make something work.

If that key ever lands in browser code or gets pushed to GitHub, your RLS doesn’t matter, the master key walks straight past it.

Search this entire project for the Supabase service role key
(the secret key that bypasses Row Level Security).

1. Tell me everywhere it appears.
2. Confirm it is ONLY ever used in server-side code, never in
   the browser / front-end, and never committed to the repo.
3. Anywhere the front-end is talking to Supabase, make sure it
   uses the anon/public key instead.
4. If the service role key was ever exposed, tell me clearly so
   I can rotate (regenerate) it immediately.

If it tells you the key was exposed: go to Supabase, regenerate it, and update your .env or Secrets.

A leaked master key is the one thing on this list you have to fix today, not later.

If this is saving you from a 2 a.m. “we got breached” email, send it to one founder who’s about to launch.

Share

5. Step four: scan for leaks with free tools.

You don’t have to trust your own eyeballs.

Free tools do this better.

Three I’d reach for, all free:

• gitleaks: scans your project and your history for anything that looks like a secret.

• TruffleHog: similar, and good at catching keys buried in old commits.

• GitGuardian: watches your GitHub repo and emails you the moment a secret slips in.

If the words “command line” make you nervous, you don’t have to run these by hand. Ask your AI to do it:

I want to scan this project for leaked secrets using a free tool.

1. Recommend ONE free secret-scanning tool that fits this project
   (e.g. gitleaks or TruffleHog).
2. Give me the exact commands to install it and run it, written
   for someone who has never used a terminal. Explain each line
   in plain English.
3. After it runs, help me read the results: which findings are
   real secrets I must rotate, and which are false alarms.
4. Set it up as a pre-commit hook so it checks automatically every
   time I save changes — so a secret can never sneak into GitHub
   again.

The pre-commit hook is the quiet hero here.

It means the tool runs before anything gets uploaded.

A leaked key that never reaches GitHub is a leak that never happened

Quick GitGuardian setup:

6. Step five: make the AI grade its own homework.

Here’s a move that costs nothing and catches a surprising amount.

After your app is built, make the same AI that built it switch hats and review its own work as a paranoid security engineer.

You are now a senior security engineer reviewing this codebase
before it goes live. Be skeptical. Assume nothing is safe.

Find and list:
1. Injection risks (SQL, command, cross-site scripting)
2. Authentication or authorization gaps (can a user reach data
   that isn't theirs?)
3. Sensitive data exposed in responses or in the browser
4. Insecure default settings
5. Missing input validation
6. Any hardcoded secrets or credentials

For each issue: rate severity (high / medium / low), explain it
in one plain sentence, and give me the exact fix.

Then do a second pass: re-read your own findings and tell me
what you missed the first time.

That last line, the second pass, matters.

Models catch more when you ask them to critique their first answer.

It’s free.

Use it every time.

This won’t replace a real audit if you’re handling money or medical data.

But for a normal MVP going live, it clears out the obvious landmines.

7. The pre-launch checklist (screenshot this).

Before any vibe-coded app touches a public URL, walk this list:

• [ ] No API keys, passwords, or tokens anywhere in the code

• [ ] .env file exists and is listed in .gitignore

• [ ] Supabase RLS is ON for every table with user data

• [ ] No table is public unless you chose for it to be

• [ ] The service role (master) key is server-side only, never in the browser

• [ ] A free scanner (gitleaks / TruffleHog) ran clean

• [ ] The AI did a security self-review and you fixed the highs

• [ ] If the app holds private data, the URL requires login to reach it

Eight checkboxes. Maybe fifteen minutes with the prompts above.

That’s the entire gap between you and a Moltbook headline.

8. Now you own this.

Run this every single time, before every launch. It becomes muscle memory.

The loop is always the same: pull secrets out, turn RLS on, lock the master key, scan, self-review, check the list.

Old way: build fast, ship, pray, find out you leaked when a stranger emails you.

This way: build fast, and spend fifteen minutes proving it’s not wide open.

Same speed. Wildly different outcome.

You don’t need to become a security engineer.

You just need to stop being the person who left the door open.

Two ways to take this further, depending on what you need.

If you want to build this the right way alongside other non-technical founders going through the same launches, the community is where we run these checks together every week.

→ Join Prompts2Products: the community ($29.99/month)

If you’d rather have a team handle the build and the security review for you, my agency Arehsoft does exactly this.

→ Schedule a free consultation call

Both paths work.

Different timelines, different involvement.

I don’t share things I haven’t run myself.

This next one is the prompt I keep pinned and paste before every launch, the whole review in one shot:

Run a full pre-launch security review on this project. Go in
this order and report on each:

1. SECRETS — find any hardcoded keys/tokens/passwords, move them
   to .env, confirm .env is gitignored, flag any secret exposed
   to the browser (NEXT_PUBLIC_ / VITE_).
2. DATABASE — confirm Supabase RLS is ON for every user-data
   table, each user can only access their own rows, and list any
   public table for me to confirm.
3. MASTER KEY — confirm the Supabase service role key is server-
   side only and was never committed; if exposed, tell me to rotate.
4. SCAN — recommend and run one free secret scanner; help me read
   results.
5. SELF-REVIEW — review the code as a paranoid security engineer,
   rate issues by severity, give fixes, then do a second pass.

Finish with a single GO / NO-GO verdict for launch, and the exact
list of things I must fix before NO-GO becomes GO.

I’m not here to scare you out of building.

I share what I actually do, what I actually test, and what actually works for founders who don’t write code.

People read this because someone they trusted sent it to them.

If this one saved you a headache, be that person for someone else.

Share

If someone sent you this, you can subscribe here:

Subscribe now