Measure twice, prompt once: why business requirements still come before the code

My dad used to build furniture in the garage on weekends. Nothing fancy, bookshelves and side tables mostly. He had this rule he repeated constantly: measure twice, cut once. I thought it was just a dad thing. Turns out it applies to software too, and people building with AI coding tools right now are learning that the hard way.

Tools like Cursor, Replit Agent, and Lovable can build websites, web apps, and internal tools from a text prompt. You type what you want, the agent writes the code, and within an hour you’ve got something on screen. I’ve watched business owners light up when they see it working. That excitement usually lasts until someone asks “wait, does this handle refunds?” and the room goes quiet.

The prompt is not the plan

I had a client last year who spent a weekend building a customer portal with an AI agent. He was genuinely proud of it, and fair enough, it looked good. Clean layout, forms worked, data saved to a database. Then I asked him what happens when a customer cancels their subscription midway through a billing cycle. He stared at me for about five seconds and said “I didn’t think of that.”

That’s the thing. He’s not stupid. He just didn’t write down all the stuff his software needed to handle before he started prompting. The AI didn’t ask him about cancellation flows, or refund logic, or what his staff should see versus what customers should see. It took his prompt at face value and started cutting wood.

AI agents are eager to please and extremely literal. If you say “build me a booking system,” you will get a booking system. Calendar, form, confirmation page. What you won’t get is cancellation logic, payment integration, timezone handling, email notifications, or admin overrides. All the stuff that makes a booking system actually work when real people use it in a real business.

What business requirements actually are

“Requirements gathering” sounds like corporate jargon, I know. But it’s really just writing down the answers to questions your software will eventually have to answer anyway. Who uses this system? What can each type of user do? What data goes in, what comes out? What happens when something breaks? What existing tools does this connect to? Are there legal or compliance rules?

You can write this in a Google Doc. It doesn’t need to be a 40-page specification. A good web development partner will run you through all of this before touching a keyboard. The point is to think through the scenarios before the AI starts building, because the AI will not think through them for you.

Why this matters more with AI

With a human developer, you’d usually get pushback. They’d ask questions like “what do you want to happen when a user tries to book a date that’s already taken?” They catch gaps because they’ve seen those gaps break things in other projects.

AI doesn’t push back. It fills in the blanks with whatever seems statistically reasonable and keeps going. I’ve seen AI agents invent entire permission systems that had nothing to do with how the business actually operates. The code compiled. The logic was wrong.

The more clearly you define what you need before the AI starts coding, the less rework later. That’s the “measure twice” part, and it’s more relevant now than it was when humans were writing every line by hand.

What a good brief looks like

You don’t need to be technical to write a useful brief. You need to be specific about your business. What problem are we solving, and for whom? Walk through the user’s experience step by step. What do they see first, what do they click, what happens after that? Think about the weird scenarios too. Cancellations, expired accounts, users doing things in the wrong order. What does this need to integrate with, your CRM, payment processor, email platform? What rules are non-negotiable, things like data privacy, accessibility, or industry regulations?

A brief like this takes a few hours. Compared to the days you’ll spend untangling a product built from a vague prompt, that’s cheap insurance.

The real cost of skipping requirements

At WebArt Design, we regularly hear from business owners whose AI-built web application looked polished on the surface but fell apart underneath. Most have security flaws, half-baked features, repetitive code, and are a security nightmare waiting to happen. I looked at one last month where the customer-facing app had no input validation at all. Anyone could submit anything into the system. Names, SQL injection strings, 10,000 character notes in a phone number field. Nothing was checked.

User roles weren’t separated. Business rules were either missing or wrong. The interface looked great in a demo, but it would have been a liability the moment real customers started using it.

Fixing these problems after the fact costs more than building it correctly would have. That’s the hidden price of skipping requirements. Measure once, cut twice. Or more accurately, don’t measure, cut repeatedly, hope it fits.

Got an AI-built prototype that needs proper engineering? We audit, rescue, and scale software projects built with AI tools. See our Custom Software Development services →

How we approach this at WebArt Design

When a client comes to us, whether they’ve got a prototype from Replit or a sketch on a napkin, the first thing we do is sit down and work through requirements. That means asking the questions the AI didn’t ask, mapping the user flows and data model, figuring out what integrates with what. All of it goes into a document so everyone involved, us and the client, is working from the same page.

Then we build. Sometimes we use AI tools, sometimes we don’t. But always from a clear set of requirements the business has signed off on. The coding tools have gotten fast. Really fast. But fast tools with a bad plan just get you to the wrong destination quicker.

So what should you do?

If you’re building something for your business with AI coding tools, write down what you actually need before you open the prompt. Talk to the people who’ll use the system. Think through what happens when things go wrong, not just when they go right. Figure out what data you need to protect and what rules apply to your industry.

If you’re not sure where to start with that, or you’ve already got something built and you suspect it’s missing pieces, that’s exactly the kind of website development problem we solve at WebArt Design. The tools changed. The discipline didn’t. Measure twice. Cut once. Even when the saw is an AI.

Need help turning a prototype into production software? We take AI-built projects and apply the requirements, security, and architecture they’re missing. Talk to WebArt Design →