Powstania Warszawskiego 15
31-539 Kraków
Sometimes no. Wireframes and a feature list answer what the app looks like and what it does. A fixed price also depends on questions they rarely answer: how data is structured, who can do what, what happens when something fails. Here is a test to tell which case you are in before paying for anything.
If you already have wireframes and a feature list, you need a paid discovery workshop only when the materials leave the pricing questions open: the data model, user roles and permissions, integrations with other systems, offline behaviour, payments and what happens when things fail. If you can answer those in writing, a discovery call is usually enough to get a fixed price. If you cannot, a short workshop is cheaper than a quote built on guesses, because every open question ends up either as a buffer in the price or as a change request later.
Wireframes are valuable. They show the flow, the screens and the intent, and they save days of design work. A feature list adds scope. Together they answer the question every team asks first: what is this app?
A fixed price needs answers to a different set of questions. Most of them are invisible on a screen. A wireframe shows a booking button; it does not show what happens when two people book the last slot at the same moment, who can cancel on someone else's behalf, or whether the booking has to appear in a system your office already uses.
Try to answer these in writing, in plain language. You do not need technical vocabulary, only decisions.
The things the app keeps track of, such as users, bookings, jobs or orders, and how they connect. One booking per user or many, one location or several.
If you cannot answerThe data model gets decided during the build, which is the most expensive place to change it.Every type of user and what each one can see, create, change or delete, including your own staff in an admin panel.
If you cannot answerRoles tend to multiply during development, and each one adds screens and rules.Payments, accounting, calendars, a CRM, an existing database. For each one, whether data only goes out, only comes in, or both.
If you cannot answerIntegrations are where scope grows most, especially with older systems.And if so, whether users only need to see data offline or also create and change it, to be synced later.
If you cannot answer"Offline" means very different amounts of work depending on which kind you need.Who pays whom, when, for what, and whether it is a one time payment, a subscription or a payout to someone else.
If you cannot answerPayments bring store rules and review steps that change the plan.A payment declines, a user loses signal mid task, two people edit the same record. Which ones matter to your business, and what the app should do.
If you cannot answerFailure cases are invisible in wireframes and often larger than the main flow.If every answer is already on paper, you probably do not need a workshop. Send the wireframes, the feature list and these answers, and ask for a fixed price after a discovery call. What that first call should cover is in how to brief an app development company.
Every question left open before the quote comes back later, either as a buffer in the price or as a change request.
A workshop is not a second round of design. It is the place where the open questions from the test get decided, with the people who know the business in the room, and written down as a scope document that a fixed price can refer to.
The fourth question is a good example. When a client tells us the app has to work offline, the first thing we check is whether their idea of offline and ours are the same thing.
Seeing data without a connection and doing work that syncs later are very different projects, and they are priced very differently. That distinction takes ten minutes in a workshop and weeks to discover in a build.
When Liniowiec, an offline first navigation app for inland waterways, came to us, the client arrived with something better than wireframes: years of personally collected route data in spreadsheets, thousands of rows of marinas, hazards and bridge clearances.
Even so, the first month was discovery. That time went into turning the spreadsheets into a structured data architecture, designing the interface for use while moving, and planning accessibility from the start. The content was complete; the decisions about how to store and version it were not.
That work paid off later. Routes were versioned and the relations between data were designed properly, so when the next stage added new map modules, water level data and a second language, the new parts had somewhere clean to attach. Getting that schema right early is one of the things the team is most glad it spent time on.
And when it is worth it: several user types, an admin side your team will run the business from, integrations with systems you already own, offline work, or money moving between more than two parties. Field operations apps almost always fall in this group; field service app development and custom HVAC software development show why.
A written scope document in plain language, the decisions from the six questions, a list of integrations with what each one requires, and a fixed price with milestones that refers to that document. If you leave with slides and no price, the workshop has not done its job.
How ours is run is described on the app discovery workshop page, and how the price that follows works is under fixed price app development.
Only if your wireframes and feature list leave the pricing questions open: data, roles, integrations, offline behaviour, payments and failure cases. If those are answered in writing, a discovery call is usually enough for a fixed price.
A written scope document that the price refers to, the key decisions about data and roles, a list of integrations, and a fixed price with milestones.
It should not. Good discovery builds on existing wireframes and spends its time on the decisions behind them.
You can get an estimate, but it will carry a buffer for everything the team had to assume. The more open questions, the less the number means.
It depends on the number of open questions. For a well prepared client it can be a single call; for a complex product with integrations and offline work, it is a short workshop before the build.
Often not. A small app with one type of user, no integrations and standard payments can usually be quoted from a good brief and a call.
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 us your wireframes and feature list. We will tell you which of the six questions are still open, and whether a call is enough to give you a fixed price.
30 minutes, no preparation needed.