Powstania Warszawskiego 15
31-539 Kraków
The first call with an app development company goes one of two ways. Either it is about screens and features, and it ends with an estimate so wide it decides nothing. Or it is about how your operation runs today, and it ends with a scope someone can put a number on. Which one you get depends less on the supplier than on what you bring. This guide covers how to brief an app development company so the call produces a priceable scope, product type by product type, because the detail that decides a field service quote is not the one that decides a marketplace quote.
August 18, 20268 min readBefore the product specifics, five things make any first call useful. None of them are documents you have to write. They are answers you already have.
If you want to write some of this down beforehand, the practical shape of it is in our guide to a mobile app requirements document. But it is not a condition of the call. The point of the call is to get there together.
For a service company the quote turns on three places, and all three are visible in a week of real jobs. Which technician may take which job, and what that depends on. What the work order form has to capture, and whether it changes by job type. And what the technician does when there is no signal.
The third one decides more of the engineering than the other two combined. Offline reading is simple. Offline writing is where the work sits: two technicians editing the same job from different vans, a photo upload that stalls on one bar and reports success, a form definition that changed while a device was out of coverage for two days.
What to bring: a printed or exported week of work orders, the exceptions included, plus the name of your current platform. The platform matters because in most cases the right shape is to keep it as the system of record and build only the technician app, and whether that is feasible depends on what its API lets us write. That check takes days, not weeks, and it comes first.
The wider question of whether your operation has crossed the line where configuration stops working is covered in build or buy field service software. The service page for this kind of project is field service app development.
On TimeFix, the work timer had to keep counting when the technician locks the screen, and when the technician places a call from inside the app itself. That was not in the original assumptions and it did not come out of a briefing. It came out of technicians using the app on real work.
Plan for that pattern rather than fearing it: a meaningful share of field requirements only appear once the app is in the environment it was built for, which is why your own crew testing during development belongs in the plan.
HVAC contractors are field service companies with one extra layer, and that layer is where the generic answer stops fitting. Recurring revenue comes from service agreements: what each agreement entitles the customer to, which visits are due when, and when it renews.
Generic platforms model the customer as the record. An HVAC operation runs on the unit as the record.
That record carries make, model, refrigerant, service history and the certificates a technician needs before the job can be assigned to them at all.
What to bring: two or three real service agreements, a sample of the equipment records you keep today, and an honest description of how dispatch changes between peak season and the rest of the year. Those three things let a supplier see which parts of your operation a platform already handles and which part needs its own software.
The specifics of that build, from agreements as a revenue record to refrigerant tracking and callback ownership, are on our custom HVAC software development page.
A booking app demo always shows the easy path. Pick a slot, confirm, done. The quote is decided by everything around that path, and every booking business has its own list.
Cancellation windows and what they cost the customer. Deposits and refunds. Resources that a booking has to reserve alongside a person, such as a room, a bay, a piece of equipment. Recurring bookings and what happens when one instance moves. Waitlists. Two people booking the last slot in the same second.
What to bring: your cancellation and deposit policy as it actually operates, including the exceptions staff make by hand, and a month of bookings that shows the busiest day.
If your bookings involve payment, bring the answer to one more question: does the customer pay for a service delivered in person, or for something consumed inside the app? That distinction decides how the App Store treats your payment flow, and it is a predictable review step, not a surprise, when it is planned for.
The vertical page is booking app development. If you are weighing whether an off the shelf scheduler would do, when to build custom booking software covers that question directly.
A marketplace is two products sharing one database, and the first call goes best when the money flow arrives already drawn. Who pays whom, at what moment, and who holds the funds in between. What the platform's take is and when it is collected. How and when the supply side is paid out. Who is liable when a transaction goes wrong.
That drawing does two jobs. It fixes the scope, because payouts, disputes and refunds are where marketplace estimates diverge most. And it settles the App Store question early.
Apple checks whether payments should be going through in app purchases rather than outside the app, and for a marketplace that sells real world goods or services the answer is usually clear once the flow is on paper. Resolved by communicating with Apple, but far cheaper to plan for than to discover in review.
What else to bring: how you will get the supply side on board before there is demand, because the first version of a marketplace is often lopsided on purpose, and which side you would build for first if you could only build one. The service page is marketplace app development.
Founders often arrive with the fullest brief in this list and get the least useful call, because everything is in the document and nothing is ranked.
The single most useful thing a founder can bring is the opposite of a feature list: the list of things you are willing to do manually for the first three months. Onboarding by hand. Payouts by bank transfer. Support in a shared inbox. Matching in a spreadsheet.
That list is your first version scope, drawn from the outside in. Everything on it is a screen you do not build yet, and a screen you do not build is time and money moved to the part that has to work on day one.
The logic for cutting a release this way is in what a first version of a mobile app should contain, and the service page is MVP app development for startups.
One more thing to bring: the metric that will tell you the first version worked. Not downloads. The number that, if it moves, means the assumption behind the product was right. A supplier who knows that number can protect it when scope has to be cut.
Some first calls are not about a new product. There is a codebase from a previous team, a version built in a visual builder that has hit its ceiling, or a project that stalled short of the store. Here the useful thing to bring is access rather than history: the repository, the developer accounts, and a clear answer to who owns each of them.
The reason is practical. What a supplier can tell you about an inherited project without seeing the code is close to nothing, and the honest first step is an audit with a written report, not a quote.
If the app was built in FlutterFlow, FlutterFlow to Flutter migration explains what the export gives you and what it does not. If the project stalled or broke, the same audit first approach is described on mobile app rescue services.
A first call is a two way test. You are checking whether the supplier understood the operation. The supplier is checking whether the scope is clear enough to price. What comes back tells you both.
The stage by stage picture of what follows the call is in working with an app development agency. If you are in the US and wondering whether a team in Poland can run this from six hours ahead, the honest answer is on nearshore Flutter developers in Poland: under a scoped, fixed price engagement the overlap is a scheduling detail, not the product.
No. You need to be able to describe how the work runs today, name the systems involved, and say who decides. A specification is usually the output of the first call or of a discovery workshop, not the input to it. If you already have one, bring it, but expect the questions above anyway.
Then bring the list of what you will do by hand and the one metric that would prove the idea. That is a founder's version of an operation, and it is enough to scope a first version. What does not work is a full feature list with nothing ranked, because it leaves the supplier guessing what to protect.
Because in most projects the new app has to write into a system you already pay for, and what that system's API allows decides what is feasible. A supplier who does not ask is either planning to replace everything, which is rarely the right answer, or has not thought about integration, which shows up later as a change request.
Enough to know who pays whom and for what. Whether it is a service delivered in person or something consumed in the app changes how the stores treat the payment flow, and that is worth knowing before scope is written. Exact provider choices can wait.
Because it is the single most common cause of a slipped launch date on the projects we have delivered, and setting it up is not quick. Knowing on the first call whether it exists lets both sides start it in parallel with the work instead of discovering it a week before release.
Take it seriously, and note that they said it. A supplier who is willing to tell you that configuring what you own is the better answer is one whose scope you can trust when they say the opposite. It is one of the reasons we run discovery workshops as a separate, honestly priced step.
Co-Founder and CEO, Apps Value
Thomas takes the first call on most Apps Value projects. That call is spent on how the work runs today, which systems are in place, and who decides, because a fixed number is built from those three things. If you do not need custom software yet, he will say so on the call. If you do, you get a written scope and a fixed price before a line of code exists.
Tell us how the work runs today, which systems it touches and what the deadline is for. You will get a straight answer on whether custom software is the right move, and if it is, a written scope with a fixed price for a defined first version.
Book an intro call30 minutes, no preparation needed.