Powstania Warszawskiego 15
31-539 Kraków
Suppliers price uncertainty. Every question you leave open becomes a risk premium in their number, or a change request later. This is the document that removes both.
Ten things: the business goal, the user roles, the main user journeys, what version one includes, what it deliberately excludes, the platforms, the systems to integrate with, the data and offline requirements, your design expectations, and your constraints on timeline and decision making.
Two to four pages covering those ten blocks is enough to get comparable quotes from several suppliers. Longer documents are not better. Specification documents running to fifty pages usually still miss the same three things: who decides, what happens without a connection, and which systems the app must talk to.
The reason to write it before contacting anyone is that you want quotes for the same product. If each supplier scopes for you, you receive three different products at three different prices, and no way to compare them.
Each block answers one question a supplier would otherwise have to guess. The note under each one is what it actually decides in the estimate, which is why leaving a block empty always shows up in the price.
What has to change in the business once this exists. Fewer phone calls, faster reporting, a new revenue line, less time spent on paperwork.
Decides what a good supplier proposes to cut. Without it, everything on the list looks equally important.Every group that opens the app or the admin panel, and what each is allowed to do.
The strongest single driver of the estimate. Each role adds screens, permissions and a full test pass.Three to six sentences per role, describing a complete task from start to finish. Not screens, tasks.
Reveals the states and edge cases that a feature list hides.The features that must exist for the first release to be usable by real people doing real work.
Becomes the fixed price scope, so this is the section that gets quoted.Everything discussed and deliberately postponed, written down with the same care as the included items.
Prevents the most common dispute in fixed price work, which is whether something was implied.iOS, Android, or both, plus whether a web admin panel is needed and who uses it.
Sets testing effort and store submission work. Cross platform makes both cheaper than two native builds.Every system the app has to exchange data with, named, with a link to documentation if it exists and a contact who knows it.
The least predictable part of any estimate, because the effort is set by the other side.What data the app holds, who owns it, and what has to work with no connection. Say whether people only read, or also create and edit.
Offline writing changes the architecture, so this block can move a price band on its own.Whether you have a brand and design system, need a custom interface, or are happy with clean platform patterns.
Decides how much design work is priced and how many review rounds are assumed.The real deadline and what drives it, the budget range you are working within, who signs off, and who is available during the build.
A supplier can design around a constraint they know about. They cannot design around one you keep to yourself.Short and specific. Here is a shortened example for a field service product, written the way we would want to receive it, with names and figures changed.
Technicians currently record job time on paper and hand it in at the end of the week. Invoicing is delayed and around a tenth of recorded hours are disputed. We want job time recorded on site and available to the office the same day.
Field technicians, who record work. Dispatchers, who assign jobs and see status. An office administrator, who corrects records and exports data for invoicing.
Opens the app in the morning, sees today's jobs, drives to a site, starts a timer, takes photos, records parts used, captures a customer signature, closes the job, moves to the next one. Sites frequently have no usable signal.
Job list and job detail, timer, photos, parts, signature, offline creation and editing of job records with sync, dispatcher web view, administrator export to spreadsheet.
Customer facing portal, invoicing inside the app, stock management, live technician tracking on a map, second language.
Android phones supplied by us as the priority, iOS for supervisors, web panel for dispatch and administration.
Export to the accounting system in version one, with a direct integration considered later. Our accounting supplier has documentation and a named contact.
First crews on the app before the busy season starts in March. One person on our side can approve scope decisions and is reachable each week. Budget range shared on the call.
That document fits on two pages and answers almost everything a supplier needs. What it deliberately does not do is describe screens, name a framework, or specify a database.
Technology, screen designs, database structure and API details. Those are the supplier's job, and deciding them early usually costs money rather than saving it.
Three things, in a predictable order: the price contains a risk premium you cannot see, the missing decisions get made during development at development rates, and requirements appear from real use that nobody could have specified.
The third one is not avoidable and should not be treated as failure. Many business process requirements only appear once the product is running in the real environment. On a field service build we delivered, the timer had to keep counting when a technician locked the screen or took a call from inside the app. That came out of use, not from any specification conversation.
What a good scope does is separate that genuine discovery from the avoidable kind. If the roles, journeys and offline behaviour were written down, then a surprise like the timer is one contained change. If they were not, everything is a surprise and the project is renegotiated continuously.
There is also a warning sign worth knowing, visible on first meetings. When a supplier asks mainly about technology rather than about your business problem and the value the project has to deliver, the risk of a mis specified product is high. We have picked up work from failed projects where that was the root cause.
Ask for the assumptions, the exclusions, the risks and the delivery model in writing. A number on its own is not comparable with another number.
For choosing between the suppliers who answer well, see our guide on how to choose a mobile app development company. For what your scope will cost once it is written, the drivers are broken down in what actually drives the price and feature by feature in mobile app feature costs.
Two to four pages for a first version. If it is longer, it is usually describing screens instead of tasks. What matters is that all ten blocks are answered, not that the document is thorough looking.
No. Journeys written in plain sentences are more useful than wireframes, because they carry the intent. If you already have designs, send them, and say whether they are fixed or open to change.
Yes, as a range. Without it, suppliers guess, and the guess is usually wrong in one direction or the other. With it, they can tell you what fits and what would have to wait, which is a more useful conversation than a number arriving in isolation.
Name the systems anyway and say what you do not know. A supplier can then price that part as an assumption or propose an export instead of a live integration, which often unblocks the same business value for far less effort.
Yes, and it is a normal paid engagement. The output is a scope you own and can take to any supplier. It is worth doing when the operation is complex or when internal stakeholders disagree about what version one is.
Some change is normal, because requirements surface from real use. What should not change is the shape of version one. If that keeps moving, the problem is usually that nobody on the client side has final authority to decide.
Thomas sets the company's long term strategy and direction, identifies market opportunities, and owns business development and client acquisition. He builds strategic partnerships that last beyond a single project. He works with clients from the first strategy conversation, so their business goals, not just their feature list, drive every decision.
Send what you have, even if it is a page of notes. We will tell you which blocks are missing, which parts will drive the price, and what we would put outside version one.
Book an intro call30 minutes, no preparation needed.