Powstania Warszawskiego 15
31-539 Kraków
Requirements for an app come from two places. One of them you can write down before anything is built: how the process runs today, who uses it, the flows that carry the business, the systems it has to connect to. The other arrives later, when the app meets real work, and it is often the one that decides whether anyone uses the product. On a field service build we delivered, it was that the work timer had to keep counting while the phone is locked, and keep counting while the technician places a call from inside the app. That requirement did not exist until somebody was standing on a real job with the screen off. This guide covers what belongs in the document, where the second kind of requirement tends to come from in different types of product, and what to settle in the contract so that it costs you a decision rather than an argument.
August 3, 20269 min readA requirements document does two jobs. It lets somebody price and sequence the work, and it records what was ordered so that two parties can later agree whether it arrived. That is the whole brief. Once it does those two things well, more pages stop adding value and start adding false confidence.
Most documents we receive are over specified in one direction and thin in the other. There are thirty screens described down to the button labels, and nothing at all about the conditions the app has to survive. Screens are easy to imagine at a desk. Conditions are not, and conditions are what break products.
The parts that carry real weight:
If the scope is still genuinely open, that is an earlier conversation than a document, and it belongs in a discovery workshop rather than in a folder of wireframes.
On TimeFix, a field service product, technicians track working time inside the app. The assumptions covered starting and stopping the timer, which is the obvious part. What the assumptions could not cover was that the timer has to keep counting when the technician locks the phone, and keep counting when they place a call from inside the app itself.
Read that as a sentence and it looks like something anyone would have specified. It is not, and the reason is worth understanding. Nobody sits at a table writing requirements and pictures the moment a technician puts the phone in a pocket to carry a part across a site, or taps a customer number from the job screen. The requirement is invisible until the behavior is real, and then it is obvious and urgent, because a timer that resets is worse than no timer at all.
This is the normal case, not an unusual one. Any product that sits on top of a working process will produce a handful of these. They do not appear because someone was careless during requirements. They appear because a process contains knowledge that nobody has ever had a reason to write down.
Which is why the plan matters more than the document. Your own people need to put the app in front of real work during or just after development, not the week before launch, and the schedule has to have room left for what they find.
For field service products the feature list is usually the easy half. Jobs, forms, photos, time, signatures. The half that decides whether crews use it is environmental, and it is almost never in the brief.
A supplier who has shipped this kind of product raises these while you are still describing the idea. If none of them comes up, that is information.
A booking product looks in a document like a calendar and a confirmation email. What it actually is, is two people agreeing on a slot, which means most of the engineering lives in the cases where that agreement fails.
Before EveSport went public, trainers from top gyms ran real sessions through it with their own clients. That is the point at which a booking product stops being a set of screens and starts being a schedule two people have to honor.
If your product is a marketplace or carries subscriptions, there is a stakeholder in your project who never appears in a requirements document, and they can hold your launch.
Apple protects its own interest at review, and one of the things it checks is whether payments in your model should be running through in app purchase rather than outside the app. It does not always read a business model correctly on the first pass. In practice this is resolved by explaining the model rather than rebuilding anything, but it takes days, and for these product categories it is predictable enough to plan around.
What belongs in your document is therefore not a technical answer but a clear description of who pays whom for what, and what is being bought. That description is what gets sent to a reviewer. Vagueness there costs calendar time later.
Describe your model, including the payments, and then stop talking. If the other side has shipped products like yours, the review question comes up unprompted. If it never comes up, you have learned something about their experience without having to ask for references.
Requirements documents describe what will be built. It is worth adding a short section describing what has to arrive from your side for the building to finish, because that is the single most common cause of delay in our projects. Three lines with names and dates against them is enough.
There is a longer version of this in what each stage of a build asks of you.
If the useful requirements surface after the document is signed, the document cannot be the thing that protects you. The contract is.
Settle three questions before any money moves. How acceptance works: which document closes delivery, against what criteria, and who signs it. We close with a signed acceptance protocol, which is not software industry language and will be familiar to anyone who has ever bought a machine or a fit out. Without a defined end there is no agreed line between what you already paid for and what is now billable extra.
Second, what separates a defect from a change request, in words, before you need the distinction. Everything inside the agreed scope has to work, and fixing it when it does not is the supplier's responsibility rather than a line item. On larger contracts we back that with a one year warranty on the software. Other companies cover the same ground through a paid monthly plan. Both are legitimate positions and they are different prices for the same project, so get it stated.
Third, how a genuine change gets priced and how long agreeing one takes. A fixed price with a rigid scope and no mechanism for what real use reveals is as risky as an open ended hourly arrangement, only in the opposite direction. One lets the budget run. The other makes you launch something your team works around. How fixed price delivery works covers where we draw those lines, and what to check before choosing a company covers how to read the answers you get.
There is a failure mode where a business responds to all of the above by writing more. If the document cannot be complete, the reasoning goes, at least it can be exhaustive. In practice that produces a heavier specification, a longer estimate, and exactly the same discoveries three months later.
The better response is to make the first version small enough that the discoveries are cheap. Build the flow that carries the business, run the rare cases by hand for a while, and postpone anything whose value depends on volume you do not have yet. That is the reasoning behind MVP app development for startups, and it applies just as well to an established company automating one process.
None of this changes when the work is done by a team elsewhere, but the thing that matters changes. The usual worry is overlap hours. The real question is who can decide and how quickly a discovery turns into a priced answer.
A requirement that appears on a Tuesday in a warehouse is not resolved by having somebody online at that moment. It is resolved by having one person on each side who can make a call, a written scope precise enough to say whether the thing is inside it, and an agreed route for pricing it if it is not. Teams in the same building get this wrong regularly. Teams several hours apart get it right when the mechanism exists.
We work this way with clients across Europe and the United States, including app development for New York businesses, from a team of Flutter developers in Poland. The clients who find it easy are the ones who named a decision maker in week one.
Write the document to the standard that lets somebody price the work and lets both sides say later whether it arrived. Spend the effort you save on three things instead: the conditions the app has to survive, the list of what you owe the project and when, and the contract terms that decide what happens when real use produces a requirement nobody could have written.
Then plan for that requirement, because on any product that sits on a working process, it is coming.
How the process runs today without the app, who uses it and in what conditions, the three or four flows that carry the business, the systems it must connect to and who owns access to them, and what would count as failure even if every screen works. Screen by screen detail is the part teams overinvest in and the part that changes most.
Detailed enough to price and sequence the work. That usually means the flows, the integrations, the user conditions and the non negotiable business rules. If a supplier quotes from less than that, the number is a guess, and the gap will reappear later as a change request.
That is normal on any product built on a working process, so the useful question is what the contract says about it. Agree in advance what separates a defect from a change, how a change is priced, and how long agreeing one takes. Without that, the same discovery becomes an argument instead of a decision.
You supply the operation and the constraints, because nobody outside your business has them. A supplier who has shipped similar products should turn that into a scope and challenge the parts that will not survive contact with real use. If they take a feature list and quote it back without questions about the process, they are pricing a description.
They help and they are not a prerequisite. A clear description of the current process and the flows that matter is worth more than a screen set, because wireframes tend to lock in an interface before anyone has agreed what the product has to achieve.
Keep the first version small, run the rare cases manually at first, and hold a written scope that is precise enough to answer whether a given request is inside it. Most scope growth is not caused by discoveries. It is caused by there being no agreed line to measure them against.
Co-Founder and CEO, Apps Value
Thomas takes the first call on most Apps Value projects. He spends it working out what your operation actually needs, what belongs in version one and what does not, and whether building anything is the right move yet. If it is not, he will tell you on that call. If it is, you get a written scope and a fixed price before a line of code exists.
Describe how the work runs today and what it costs you. You will get a straight answer on what belongs in version one, which parts of it will only be settled once real users touch it, and a written scope with a fixed price before anything is built.
Book an intro call30 minutes, no preparation needed.