AI in business

How to brief a contract developer in the AI era: a one-page spec that gets you a working build

October 10, 2026

A developer working with AI agents can build what you described in days, including the parts you described badly. Here is a one-page brief a non-technical founder can fill in, with a worked example, and what changes when the person you hire builds with AI.

Two people at a table with laptops going over a printed page together

When a contract build goes wrong, the code usually gets the blame. Look closer and the trouble often started a month earlier, in a two-line message: "I need an app like Calendly, but for clinics. How much?" The developer filled the gaps with guesses, the founder pictured something else, and both found out at the demo.

That was always true. What's new is the speed. Most developers now work with AI tools: 84% use them or plan to, according to Stack Overflow's 2025 survey of developers (Stack Overflow). A developer with a coding agent can turn a description into a working screen in an afternoon. A vague description gets built just as fast as a clear one, so you can be a long way down the wrong road by Friday.

So the brief matters more than it did, and it doesn't need to be long. One page will do, if it's the right page.

Why one page

A forty-page requirements document doesn't get read, by people or by you six weeks later. A two-line message leaves everything open. One page forces the decisions that only you can make: who it's for, what it must do first, what it must not do yet, and how you'll know it's finished. Everything else, the developer can ask about or propose.

There's a second reader now, too. Developers increasingly hand the brief itself to their AI agent as the thing to build against. GitHub released an open-source toolkit for exactly this in 2025, built on the idea that the written specification is the shared source of truth, because a vague prompt "forces the model to guess at potentially thousands of unstated requirements" (GitHub). An agent reads your page literally. Where a human developer would stop and ask what you meant, an agent will often pick something plausible and keep going.

The page

Nine short sections. Here it is filled in for a made-up example, a booking app for a physiotherapy clinic with three therapists. Copy it and replace the answers with yours.

text

1. GOAL (one sentence, and how we'll know it worked)
   Patients book and move their own appointments online, so the front
   desk stops spending two hours a day on the phone.
   Worked if: within a month, half of all bookings are made online.

2. USERS (three roles at most)
   Patient    - books, moves, cancels own appointments
   Therapist  - sees own day, blocks time off
   Front desk - sees everyone's calendar, books on a patient's behalf

3. MAIN JOURNEYS (step by step, in plain words)
   a. New patient picks a therapist and a free slot, enters name, email
      and phone, gets a confirmation email.
   b. Patient opens the link in that email and moves or cancels, up to
      24 hours before.
   c. Therapist blocks next Friday afternoon; those slots disappear.

4. DATA (what we keep, where it comes from, who can see it)
   Patient name, email, phone, appointment times. No medical notes.
   A patient sees only their own bookings. Therapists see their own
   patients. Front desk sees all.
   Existing: 1,400 patients in a spreadsheet (sample of 20 rows attached).

5. MUST HAVE FOR VERSION 1
   Journeys a, b, c. Reminder email the day before. Works on a phone.

6. NOT NOW (do not build these)
   Online payment. SMS. Insurance claims. A patient app in the stores.
   More than one clinic.

7. CONNECTIONS
   Email sending (we have no account yet - please recommend one).
   The therapists' Google Calendars, read-only, to avoid double booking.

8. DONE MEANS (each line is true or false)
   - Two patients cannot book the same slot, even at the same second.
   - A patient cannot open another patient's booking by changing the link.
   - A cancelled slot is bookable again within a minute.
   - The 1,400 existing patients are imported, with no duplicates.

9. LIMITS AND HANDOVER
   Budget: fixed price, three milestones. Live by 1 March.
   English and Spanish. Patients are in Spain, so EU privacy rules apply.
   Code in our GitHub account from day one. Hosting, domain and email
   accounts in our name, on our card.

That's about 300 words. A developer can price it, and can tell you in one call which parts are easy and which line will cost more than you think. (In this one it's the Google Calendar connection.)

The four sections people skip

Data

Founders describe screens. Developers need to know what's stored behind them and who is allowed to see it. "A patient sees only their own bookings" is a sentence a non-technical person can write, and it's the sentence that prevents the most common hole in quickly built apps: every signed-in user being able to read everyone's records. If you have existing data, attach a real sample. Twenty rows of your actual spreadsheet, with its typos and its three date formats, tell the developer more than any description of it.

Not now

This list has become more important, not less. An AI agent asked for a booking app will cheerfully add payments, an admin dashboard and dark mode, because booking apps usually have them. Every extra is more code that somebody has to check, secure and maintain. Writing "no online payment in version 1" is free. Removing a half-built payment flow is not.

Done means

Write acceptance checks as sentences that are plainly true or false. "Fast and easy to use" can't be tested. "A patient can book in under a minute on a phone" can. Good developers turn these lines straight into automated tests, and the agent then works until the tests pass. They are also your protection at the end. You don't need to read code to try opening someone else's booking link.

Handover

Decide on day one where things live. The code goes in a repository in your account, with the developer invited in. The hosting, the domain, the email service and the payment provider are opened in your company's name and paid with your card. Founders who skip this find out later that their product runs on a stranger's personal accounts.

What changes when the developer builds with AI

Ask who reads the code. In the same Stack Overflow survey, 46% of developers said they don't trust the accuracy of AI tools' output, and the most common frustration, named by 66%, was answers that are "almost right, but not quite" (Stack Overflow). The people using these tools every day know the output needs checking. So ask your developer how that happens on your project: do they read what the agent writes, are there tests, who looks at the sign-in and permission code? "The AI handles that" is the wrong answer.

Pay for results, not hours. If a week of work now takes two days, an hourly rate rewards the slow developer and punishes the good one. A fixed price per milestone, each tied to lines from your "done means" list, is fairer to both of you.

Ask where your data goes. The developer's AI tools see what the developer pastes into them. Real customer records, passwords and API keys shouldn't be among those things. Give sample data with made-up names where you can, and ask which tools will be used.

Put ownership in the contract. The US Copyright Office concluded in January 2025 that AI output can be protected by copyright only where a human author has determined sufficient expressive elements, and that prompts alone don't get there (US Copyright Office). How that applies to code a developer directed, edited and assembled is not settled. The practical answer doesn't depend on it: have the contract assign to you whatever rights exist in the work, and make sure you hold the repository, the accounts and the data. Possession and a clean contract cover most of what a small business needs.

Expect a first version sooner, and plan to change your mind. The biggest gain from AI-assisted building is that you can see something real in days. Use that. Ask for the main journey first, try it with two actual users and then update the page. A brief that changes after the first demo is a brief that's working.

What to leave off the page

The technology. Unless you have a reason, such as an existing system or a team who will take it over, let the developer choose. Do ask them to pick something common, so the next developer can read it.

Pixel-level design. A sketch on paper or a link to two sites you like is enough for version 1.

Adjectives. Modern, robust, scalable, intuitive. They cost nothing to write and can't be checked. Replace each one with a number or an example, or delete it.

How to tell the brief landed

A good developer answers a good brief with questions. What happens to a booking when a therapist leaves? Do reminders go out in the patient's language? Who resets a front-desk password? Those questions are the first piece of real work on your project, and they're a better sign than a fast quote. Be wary of a reply that is only a price and a date.

Then, before you accept delivery, go back to section 8 and try every line yourself. If the build was done quickly with AI tools, also run through the checks in your AI-built prototype works; check these six things before customers log in. And if you're still deciding whether to commission anything at all, buy, build or prompt looks at when building your own tool makes sense.

We turned those pre-launch checks into a free checklist you can go through with your developer on a call: seventeen yes-or-no questions on access rules, keys, backups and ownership, with a score and a printout.

About to accept a build? Go through the launch checklist first.

Open the checklist

Sources

Stack Overflow, 2025 Developer Survey: AI; Stack Overflow, 2025 Developer Survey press release; GitHub, Spec-driven development with AI: get started with a new open source toolkit (2025); US Copyright Office, Copyright and Artificial Intelligence, Part 2: Copyrightability (January 2025). The clinic example is invented for this article.