What to Send a Developer Before They Quote Your App

Six things. Send those six and most developers can come back with a number without needing a call first. Leave any of them out and what comes back is a guess dressed as a price. The twenty-page requirements document, the wireframes and the finished feature list all wait until somebody has been hired, and much of it never needs to exist.

A developer pricing work on an app that already runs needs six things: what the app is and who uses it, the one job you want done, what is not in that job, what it was built with and where it runs, what has been tried, and what access you can give and when. None of it requires reading code.

The six items below were set against what the requirements templates currently ranking for app requirements example ask a reader to fill in, read on 26 August 2026, and against what AxonBuild’s fixed study of 26 AI-built applications audited in June and July 2026 found could not be established from a running app without asking the person who owns it. Nobody was hired for this page, no message was sent to a developer, and no app was priced.

Someone building a CRM for their own business with an AI builder described what kept their bill under control, in a thread held in AxonBuild’s own outreach records and not read live for this page:

I am building a CRM for my business with Replit. I spent a looooong time building out a very tight set of specifications with short tasks in order to prevent costs from getting out of control.

They were controlling a credit bill rather than a person’s price, and the mechanism transposes: the job was written down in short, tight pieces before any of it started. Choosing which single job to buy first, and which of the four kinds of supplier to buy it from, happens before any of this.

What a developer needs before they can give you a number

Six pieces of information move a price on an app that already exists. Three of them describe the app and three describe the job. The third column of the table below is the one no requirements template has: what to put down when the honest answer is that you do not know.

An honest blank in that third column is worth more than a filled-in guess, for a mechanical reason rather than a moral one. A blank tells the person pricing the job that this is something they will have to check, so they price the checking. A guess tells them the question is settled, and the correction arrives later as a change to a price you already agreed.

The study behind this page hit the same problem from the reviewer’s side. Before it could score any of the 26 applications, it had to establish which parts of each one were even in play: pillars that did not apply to an app, because it took no payments, ran no AI, or had no server of its own, were excluded from the score rather than counted as zero. That call cannot be read off the screens. It comes from knowing what the app is for and which parts of it are switched on, which is the owner’s knowledge and nobody else’s. A stranger pricing one job makes the same call in ten minutes instead of across a full review, and a wrong assumption there moves the number more than anything else in your message. The cohort rules and method behind these counts are written up separately.

What the app is, and who is using it right now

Three sentences cover this: what the app does, in the words you would use to a friend who is not technical, who logs into it, and whether there are real people and real money on it today.

The third sentence carries more weight than the other two put together. An app with nobody on it can be taken apart and put back together on a Tuesday afternoon. An app with forty paying accounts cannot, because every change now has to be made in a way that does not interrupt anyone, and that constraint is most of the difference between two prices for what sounds like the same work.

Numbers help and they do not have to be exact. “About forty accounts, six of them paying, live since March” is enough. So is “I built it in June and my business partner and I are the only two people who have ever logged in.” What does not help is the word “some”, because it covers everything from three friends to three thousand strangers, and the person reading it has to assume the expensive end. If money moves through the app, put that in this sentence rather than saving it for later.

The one thing you want done, in a sentence that stops growing

Write the job as one sentence, then say it out loud. If it ends, it is one job. If you find yourself adding “and also” for the third time, or it finishes with “and then we can look at the rest of it”, you are describing several jobs, and several jobs cannot share one price. The second one belongs in a different message on a different day.

A post title on r/vibecoding on 12 August 2026 put the same demand on the other side of the table: “Pitch me what you’ve built in one sentence (if you meet my requirements)”. One sentence is a real constraint when somebody is deciding whether to spend time on you, and it is the same constraint when they are deciding what to charge you.

Name the finish line inside that sentence: what will be true when the job is done that is not true today. “Declined payments send the customer an email and show a banner in their account” is a finish line. “Fix the billing” is a subject heading. The first can be checked by you, on your own app, on the day the work is delivered. The second cannot be checked by anybody, which is why nobody will price it tightly.

Counting what is actually missing in an app that is nearly done is its own piece of arithmetic, and it produces the second item on this list rather than replacing the list.

What is not in this job

This is the shortest thing to write and the one almost nobody sends. Two lines of “not this, not that” stop a price from quietly covering the whole app, and they stop the opposite failure too, where the price covers so little that the thing you wanted still does not work at the end.

Write it as a sentence about what stays the same. “The rest of the billing, the design, and the reports all stay exactly as they are for now.” That is it. You are saying which work this particular number is for, without ruling any work out forever.

The benefit shows up later. When the person comes back and says the job needs one more thing to work, and sometimes it genuinely does, you have a written line to compare it against, and the conversation is about whether the extra thing is necessary rather than about what either of you remembers agreeing.

The line protects the developer too, which is worth knowing if you want good ones to reply. A serious person reading a request with no boundary on it has to assume the worst case, and the price they send back has that assumption baked in.

What it was built with, and where it runs

Name the builder you used, where the app is deployed, where the data sits, which accounts exist, and whose name each of them is in. You do not need the right technical words for any of it. “I built it in Base44, it is on a web address they gave me, I think the database is Supabase because that is what it says on the screen, and everything is under my email” is a complete answer.

People skip this item because they feel unqualified to answer it, and it is the one that most often decides whether the job is possible at all. Some work can be done inside the builder by anyone who knows that builder. Some has to happen in the code underneath, which needs a different person, sometimes a more expensive one.

The accounts half matters just as much. If the app was built inside somebody else’s login, or the domain is registered to a person you no longer speak to, the work cannot start until that is resolved, and any price given first is provisional whether or not anyone says so.

Where you genuinely do not know, say which screen you looked at and offer a screenshot. “I do not know where the data lives, here is what my settings page shows” is a priceable answer. A developer reads that screenshot in ten seconds. They cannot read a guess.

What has already been tried, and what happened

Copy the error rather than describing it. The exact text, or a screenshot of it, is worth more than a paragraph explaining what it seemed to mean, because the text is searchable and the paragraph is an interpretation.

Then give three facts around it: when it started, what changed just before it started including anything you asked the AI builder to do that week, and what you have already tried with what happened when you tried it.

The last of those three moves the price more than people expect. A problem nobody has touched is one job. A problem two AI attempts have already failed at, where one of those attempts broke something else on the way through, is a larger job, because whoever picks it up has to work out what the failed attempts left behind before starting on what you actually asked for.

Undoing an attempt does not always undo everything it did, which is worth saying plainly if you rolled something back. “I undid it and logging in works again, but I do not know what else that change touched” is exactly the right sentence, and it warns whoever is pricing the work that part of the job is finding out.

What you can give them, when, and the date that actually matters

Two things go in this item, and they are usually the last two anyone thinks about.

The first is access: what you can give, and on what day. Read access to the code, an invitation to the hosting, a role on the payment account. You do not have to hand any of it over now, and you should not. You are telling them what will be available and when, so their price is not built on an assumption that they can start looking on Tuesday. Say what you will not send too, which for almost everyone means the real customer data.

The second is the date, and only if there is a real one. A real date happens whether or not the work is finished: a demo booked with a customer, twenty new accounts starting on the first of the month, a season that ends. That kind of date changes a price legitimately, because it changes how the work has to be sequenced and sometimes who can do it.

A date invented to sound serious changes nothing except how you are read. “As soon as possible” is on every message a developer receives and has stopped carrying information. If nothing is forcing a date, write that instead.

An app requirements example for an app that already exists

Here is the same request written twice. The first version is close to what most people send, and nobody can price it. The second version is the six items above, written by the same person about the same app, and any competent developer can put a number on it.

Subject: Need some help with my app

Hi,

I built an app with an AI tool and it is mostly working, but there are a
few things that need fixing and I would like to make it more professional
and reliable before I push it to more customers. Some parts are broken and
the design could be better.

Could you let me know how much you would charge and roughly how long it
would take? Happy to jump on a call to explain more.

Thanks

Every sentence in that message is true and none of it is priceable. “A few things” could be two or twenty. “More professional and reliable” is an outcome with no finish line attached. “Some parts are broken” does not say which, or how, or whether anyone has already tried to fix them. The offer of a call is doing all the work, so the price cannot exist until the call happens, and most people never reply.

Subject: One fix on a live CRM, quote please

What it is: a CRM I built myself in Replit for my own business. About 40
accounts log in, 6 of them pay me monthly, and it has been live since
March.

The one job: when a customer's card is declined, nothing happens. No email
goes out, nothing shows in their account, and I only find out when they
ring me. I want a declined payment to email the customer and show a notice
inside their account.

Not in this job: the rest of the billing, the design, and the reports all
stay exactly as they are for now.

Built with and running on: built in Replit and still running there.
Payments go through Stripe. I think the data is in Supabase because that
is what the settings screen says. All the accounts are under my email. I
do not know where the app currently sends email from.

Tried already: I asked the AI builder to add this twice. The second
attempt broke logging in for two days and I undid it. Logging in works
again. I do not know what else that change touched.

Access and timing: I can give you read access to the code and a role on
the payment account on the day we agree. I will not be sending the
customer list. There is a real date: 20 new accounts start on 1 October
and I would like this working before then.

Three things changed between those two messages and none of them needed technical knowledge. The job got a finish line somebody else can check, so a price has something to attach to. The boundary got written down, so the number covers a known piece of work rather than an unknown share of the whole app. Two honest blanks were left in, which is what tells the reader which parts of the job include finding something out.

The second message runs to about 180 words. No app specification template produced it. It is an email rather than a requirements document sample in any particular format, and six headings copied off a page produce it in twenty minutes.

What you do not need to send

Four things people prepare before a first message that nobody needs at that stage. Skipping all four is normal and costs you nothing in the quality of the replies you get back.

Real customer data, first and permanently. Nobody needs live customer records to produce a price. Made-up rows, blanked-out names, or a screenshot with the personal details removed cover every legitimate need at this stage, and anyone who tells you otherwise before they have quoted anything is worth a second look.

An eleven-section requirements document is the second. The templates that rank for this search are real work and some are good, and every one of them was built for a project that has not started. Designs and mockups are the third: unless the job is a visual change, a description of what should happen beats a picture of what it should look like.

A finished feature list is the fourth, and it costs people the most time. Listing everything the app might eventually need is planning work rather than pricing work, and it makes the message longer without making the number tighter.

Confidentiality is worth handling in one line rather than one page. If you want an agreement in writing before you send anything, say so in the first message and ask them to send theirs. That is an arrangement between you and them, and this page makes no claim about what any particular wording does.

Why the requirements templates you will find do not fit

Page one for app requirements example, pulled on 26 August 2026, holds seven results: three agencies, two tool vendors, a requirements-management vendor and one community file. The five that were read are written for a build that has not started yet, and none of those five has a section for an app that already exists; the two that were not read beyond their titles, Jama Software and Simpalm, are left unassessed. Their addresses are given below without links, because every one of them either sells the work this page is about or puts a template behind a sign-up.

NIX United’s requirements-document guide, at nix-united.com/blog/how-to-write-a-proper-mobile-app-requirements-document-in-5-steps/, ranks first today, offering a downloadable template alongside a five-step guide. Its own guidance on timing says who it is for: preparing a mobile app requirements document takes one to two weeks for a simple MVP, and four to eight weeks or more for a complex enterprise application with detailed system requirements, workflows and integrations. That is a sensible estimate for a company deciding what to build, and a strange amount of homework for somebody who wants one broken thing fixed on an app that is already live.

Mind Studios’ guide, at themindstudios.com/blog/mobile-app-requirements-document/, organises the same job into three layers of requirements, business, user and system, then sets out eight qualities the finished document must have: complete, correct, consistent, feasible, prioritized, modifiable, verifiable and unambiguous. It hands the finished article over as a PDF. Two more results were not read for this page, so only their positions and titles are known here: Jama Software ranks second with “Functional requirements examples and templates”, and Simpalm ranks sixth with “How to write product requirement document for mobile app?”.

Atlassian’s Confluence product requirements template, at atlassian.com/software/confluence/templates/product-requirements, and Figma’s guide to writing a PRD, at figma.com/resource-library/product-requirements-document/, both aim inward, at a product manager lining up designers and engineers inside one company. Figma’s page says product managers usually own the document and that the strongest ones are written together with the designers and engineers who will build the work. That describes a team, and you are one person buying one job from a stranger.

The fifth result is the most revealing. It is a community file called web-app-requirements-template.md running to eleven sections including a data model and complete user flows, and its opening instruction is not addressed to a person at all: “You are an expert AI web application developer. Create a comprehensive, detailed implementation plan for the following web application:”. It asks you to “Describe all entities and their relationships” and to “Detail the complete user journey through the application”, which are reasonable instructions to give a machine that is about to write an app from nothing and the wrong ones for a person about to price one change to an app that already runs.

The marketplaces would be the obvious place to check what a buyer is actually asked to fill in, and that check was not available for this page. Both support.upwork.com/hc/en-us/articles/211063408-How-to-post-a-job and help.fiverr.com/hc/en-us refused an automated read on 26 August 2026, answering with an HTTP 403, which is why neither is linked and why nothing here is claimed about what either marketplace tells its clients to write.

Which documents a developer needs before quoting, and which can wait

Documentation is not a pre-hire requirement at all. The six items above are the whole set, and none of the app documentation people search for has to exist before somebody tells you what one job costs. Everything else on that subject belongs after a person has been chosen.

The samples themselves are worth understanding, because the search results do not distinguish them. A mobile app technical documentation sample, or a mobile app documentation sample, is usually an internal reference: how the system is put together, how to set it up, which parts are fragile, written so the next person can pick the app up without interviewing anyone. It is a genuinely useful thing to own, and it answers a question nobody is asking at the point where you want a number.

The durable version of that set does matter once somebody is keeping your app running, and it is a real piece of work with a real payoff: the full documentation set an app needs once somebody has to keep it running covers what belongs in it. So does the shorter, sharper version you assemble the moment a person is actually chosen, which is the packet a developer needs once they have been chosen. Both come after this message, not before it.

A third document gets confused with both of those and is aimed at a machine rather than a person. A spec written for the tool that builds the feature is what you write when the AI builder is doing the work and you want it to stop wandering off. That is the shape the community template on page one has, and it explains why the template reads so oddly here: it was never written for hiring anybody.

If you already have any of this on paper, send a one-paragraph summary rather than the whole file. A developer pricing one job reads four paragraphs carefully and skims forty.

What comes back, and what a priceable answer contains

Two kinds of reply arrive. One names your job back to you, names the finish line, and puts a number on that job. The other puts a number on “the app”, or offers a range, or asks for a call before saying anything at all.

The first kind is answerable. You can read it, compare it with the next one, and check at the end whether the thing that was promised happened. It usually also names the one or two things the person still has to look at before the number is firm, which is a good sign rather than a bad one: they read your blanks and they priced the checking.

The second kind compares with nothing. A range from one person and a range from another tell you about their appetites for risk rather than about your app, and when everyone comes back with a range the usual cause is a missing boundary in the original message. The fix is one more sentence rather than more calls. What the different hiring routes actually cost is a separate question: what developers charge for an app that already exists sets out the bands.

Two replies with very different numbers usually means the two people read your request as two different jobs, which is information about your message rather than about them. Send both the same one-sentence clarification and see whether the gap closes. Whether the person replying really did the work they say they did, and how to test that without reading code, is a separate check that runs beside this one.

The eight questions to put to a candidate, and how to tell a real answer from a hand-wave, are a separate skill practised on the call after this message has already been sent. What happens after the replies come in, all the way to somebody starting work, is a longer sequence than one message.

Common questions about what to send a developer before they quote

What should an app requirements example include for an app that already exists?

Six things: what the app is and who uses it today, the one job you want done with its finish line, what is not in that job, what it was built with and where it runs, what has already been tried and what happened, and what access you can give and when. About 180 words covers all six. Anything longer is usually planning work rather than pricing work.

How do I write a mobile app requirements document if I am not technical?

Write it in the words you already have. Nobody pricing a job on an existing app needs correct technical vocabulary from you, and the six items above are all answerable in plain English. Where you do not know something, write that you do not know it and offer a screenshot of the screen you looked at. A developer reads a screenshot faster than a guess and prices it more tightly.

Do I need an app specification template, or is an email enough?

An email is enough, and for one job on an existing app it is better. A template asks you to fill in fields that were designed for a product that has not been built yet, which produces long documents with the six load-bearing facts scattered through them. Six short headings in an email put those facts where somebody can read them in two minutes.

How long should the message be?

Under 250 words. Every one of the six items fits in one or two sentences, and the worked example on this page runs to about 180. Length works against you here: a developer deciding whether to reply is scanning for whether the job is real and whether you know what you want, and both of those read faster in a short message than a long one.

What if I do not know what my app is built on?

Say so, and say where you looked. “I built it in Lovable, I do not know where the data lives, here is what my settings page shows” is a complete and priceable answer. Naming the builder alone is usually enough for somebody to work out the rest, because the builders each have a small number of standard setups underneath them.

Can I just send a link to the app and let them look at it?

Send the link as well, never instead. Somebody clicking around your app can see what the screens do and cannot see what is behind them, which parts run for real, whether anybody is using it, or which of the things they can see you actually want changed. A link with no message asks a stranger to guess at your job, and a guessed job produces a guessed price.

Should I send my code or give access before anybody has quoted?

No, and you do not need to. Say in the first message what access you can give and on what day, and hand it over once you have chosen somebody. Real customer data stays with you at every stage, including after the hire: sample rows or blanked-out screenshots cover anything a developer legitimately needs to see while pricing.

What is the difference between this and the documentation my app needs?

Timing and audience. What you send before a quote is six facts written for a stranger deciding what one job costs. Documentation is written for whoever has to keep the app running afterwards, and it covers the whole system rather than one job. The first takes twenty minutes and is needed now. The second is a real piece of work and is needed later, if at all.