How To Architect A Feature In 5 Minutes Before Talking To AI

This post has been originally published on my Substack publication VSL

Yesterday I opened my server logs and saw my API costs had spiked for no obvious reason.

I was building a new feature and thought I'd be clever. I told the AI: "Just reuse the logic from the other generator." The AI said "Sure!" The UI worked perfectly when I tested it.

But I never looked at what was happening underneath.

The AI had built something that made three separate calls to my server every time a user clicked one button. The feature worked on my screen, but it was costing me money with every click and making users wait longer than they should.

AI Will Make Anything Work Even if It's Wasteful

One of the first things you’ll learn building with AI tools is that they'll make anything work on the surface, even if it's wasteful underneath.

When you ask AI to build a feature, it assumes everything will go perfectly. It assumes your backend is already set up exactly right. That you don't care how many times it calls your database or how long users have to wait.

It assumes you know what you’re doing.

AI is incredibly fast at writing code but it doesn't think about what happens when that code runs in the real world, with real users.

That’s why you have to treat AI like a brilliant junior developer who will take shortcuts whenever you aren't watching. Here’s what you need to know to actually make it work.

The 5-Minute Sketch That Saves Hours

Spend 5 minutes thinking before you start typing prompts.

Before you ask AI to build anything, draw what you actually want to happen. I’m talking about the data flow, basically what information moves where, and in what order.

When I saw those cost spikes, I stopped. I grabbed a piece of paper and drew what the AI had actually built. It was a mess of arrows going back and forth.

Then I drew what I actually wanted:

1. Browser calls the API;
2. Server gets the request;
3. Server computes and routes my message;
4. Server calls the AI and saves the result in the database;
5. The browser polls my database and shows the new information.

Once I saw it on paper, the problem was obvious. The AI was calling the save step twice and re-fetching data that was already in database. It tried to reuse logic from an old feature that worked differently.

This Is The Classic "Reuse this code" Trap

I was building a Meta Description generator for Yahini. I already had a Brief Generator that creates meta titles and descriptions along with a bunch of other content analysis and writing the brief.

I thought I'd be smart. I told the AI: "Repurpose the Brief Generator logic, but just return the meta title and description."

The AI obliged. The feature worked. Users could generate meta information.

But here's what I didn't notice: the AI kept all the calls from the Brief Generator, then throwing all of it away and only showing the meta title/description.

I was paying for a full brief generation every single time someone just wanted a meta description. That's like ordering a full meal at a restaurant, eating only the dessert, and throwing the rest away.

My prompt started with *reuse this to…* without thinking about what this actually did.

This is why the 5-minute sketch matters. If I'd drawn what I wanted before prompting and share it with the AI, it would have seen immediately that the Brief Generator did 10 steps and I only needed 3 of them.

4 Questions to Ask Before You Prompt

Run through these 4 questions for 5 minutes before you prompt and your AI code will most certainly be more reliable.

Think of these as your architecture checklist. I use these symbols to mark my sketch:

• 🚩 Red flag: What will break your feature
• ✅ Green flag: What makes it production-ready

1. What goes in?

Be specific about what data you're sending and what format it's in.

🚩 Red flag: Vague descriptions like "user data" or "form values" leave too much room for AI to guess wrong.

✅ Green flag: Write exactly what the user provides: "A URL (text), a tone choice (dropdown with 3 options: professional, witty, casual), and their user ID (number)."

Example: Instead of telling AI "handle the signup form," say: "User enters email (must include @), password (minimum 8 characters), and checks a newsletter opt-in box (yes/no)."

2. What happens to it?

Trace the complete path your data takes from start to finish.

🚩 Red flag: Skipping steps like "validate" or "check permissions" because they seem obvious—AI won't assume them.

✅ Green flag: Map every hop: "Browser → Server validates URL format → Server scrapes website → Server sends scraped text to AI → AI returns description → Server saves to database → Server responds to browser."

Example: For a contact form, map the full path: "Server checks email is valid → Server checks for spam → Server saves to database → Server sends confirmation email → Server responds 'Message sent' to browser."

3. What could slow this down?

Think about external dependencies and what happens if they're slow or unavailable.

🚩 Red flag: Assuming external services (website scraping, AI APIs, payment processors) will always respond instantly.

✅ Green flag: Identify each external dependency and set realistic timeout expectations: "Scraping might take 5-10 seconds. AI call usually takes 2-3 seconds but could take up to 10."

Example: For a feature that checks if a domain is available, note potential delays: "Domain lookup calls an external API—it might take 3 seconds or fail completely if the service is down."

4. What happens when it breaks?

Think through (almost) every way this could fail and what the user should see.

🚩 Red flag: Only planning for the "happy path" where everything works perfectly.

✅ Green flag: List specific failure scenarios and responses: "If scraping fails → show 'Couldn't access that website, try another URL' and don't charge credits. If AI times out → show 'Taking longer than expected, try again' and don't save partial results."

Example: For a file upload feature, plan for: "File too large → 'Maximum 5MB.' Wrong file type → 'Only PDF, DOC, or TXT files.' Upload interrupted → 'Upload failed, please try again' and clean up partial files."

Example time

Let's say you're building a feature that generates social media posts from a blog URL.

Before you prompt AI, spend 5 minutes on this:

Draw your data flow on paper:

• User pastes blog URL and picks platform (Twitter, LinkedIn)
• Your server fetches the blog content
• Your server sends content + platform to AI
• AI returns optimized post
• Your server saves it and shows it to the user

Mark your 4 questions on the sketch:

1. What goes in? Blog URL (text, must start with http), platform choice (dropdown: Twitter/LinkedIn), user's account ID
2. What happens? Browser → Server validates URL → Server scrapes blog → Server sends to AI with platform context → AI returns post → Server saves → Server responds
3. What could slow it down? Blog scraping might take 5-10 seconds if the site is slow. AI usually responds in 2-3 seconds. Total: plan for 15 seconds max.
4. What breaks? Blog URL invalid → show "Please enter a valid URL." Scraping times out → show "Couldn't access that blog, try another." AI fails → show "Generation failed, try again" and don't save anything.

Now you're ready to prompt AI. Your prompt might look like:

"Create an action plan on how to build an API endpoint that takes a blog URL and platform choice (Twitter or LinkedIn). First validate the URL format. Then scrape the blog content with a 10-second timeout. Send the scraped content to OpenAI with context about which platform. Return the generated post. If scraping fails, return error message without calling OpenAI. If AI fails, return error without saving. Only save successful results to database."

The AI will build exactly what you sketched because you thought through the flow first.

**IMPORTANT -* Use this kind of prompt to generate a more comprehensive action plan and only then start coding. I use an Architect mode in Kilo Code that creates a To Do list and then my other agents implement each item from that list.*

Show AI a Picture, Not a Paragraph

Here's how I fixed my expensive feature in 10 minutes.

I grabbed my rough sketch and uploaded the photo to the AI.

My sketch showed:

• Brief Generator (full flow with 10 steps) ← crossed out
• New simple flow: URL → Scrape → AI → Save → Return
• Notes in the margin: "Only need meta description and title, skip other stuff."

My prompt was simple: "Rebuild this to match my sketch. Remove the extra steps."

The AI understood immediately. It rewrote the code, removed the wasted calls, and cut the delay in half.

💡 The pattern: A rough sketch beats a detailed text explanation every time.

What to include in your sketch:

• Boxes for each major step (Browser, Server, Database, External API)
• Arrows showing what data moves where
• Notes about what to validate or check
• Cross-outs showing what NOT to do
• Timing notes ("10 sec timeout here")

You don't need perfect diagrams. You need clarity about what talks to what and in what order.

Architecture Means Deciding Before Building

When developers talk about "architecture," it sounds intimidating.

Architecture means deciding how the pieces of your feature will talk to each other before you build them.

No-code platforms make these decisions for you, usually poorly, especially when your prompts are vague. It’s up to you to orchestrate everything, and it’s easier than you think.

When you skip the architecture sketch, you end up debugging in production. A user clicks a button, something breaks, and you're digging through server logs trying to figure out which of the five database calls failed.

When you sketch first, you know exactly what should happen. When something breaks, you can trace the flow on your sketch and find the problem in minutes.

The sketch becomes your debugging map.

✅ The test: If you can draw it on paper in 5 minutes, you're ready to build it. If you can't draw it, you don't understand it well enough yet.

This Week's Discovery: tldraw

I usually just use pen and paper, but when I need to share my sketch or save it for later, I use tldraw.

It keeps that hand-drawn feel, which stops you from obsessing over making it perfect. And when you need to share your architecture with AI, you can export the sketch and paste it directly into your prompt.

The hand-drawn style actually helps by keeping you focused on the flow instead of making it pretty.

Let's Connect

Next time AI-generated code isn't working the way you expected, stop. Step away from the screen. Draw what you actually want to happen.

Did you discover a loop or redundancy you didn't know existed? Reply and tell me.

Build smart,

Dan

This post has been originally published on my Substack publication VSL