Powstania Warszawskiego 15
31-539 Kraków
Almost everything written about app development is written for the people building it. This is written for the client: the person who signs off the scope, releases the budget, and answers for the result. Here is how a project actually runs, stage by stage, and what each stage asks of you.
If you run an operation, you have bought a lot of things. Vehicles, machinery, service contracts, insurance. All of them work the same way: you describe what you need, you get a price, you pay, and something arrives that does the job. The specification came from the supplier, the risk sat with the supplier, and your involvement ended at the purchase order.
Commissioning software looks like that and behaves nothing like it. It is much closer to putting up a building on your own site. The contractor knows how to build. Only you know how the space will be used, who moves through it, and which door has to be nearest the yard. If you are not available while it is going up, you get a building that is technically finished and wrong for you.
Almost every delayed project we have seen traces back to this one mismatch. Not to bad developers, and not to bad clients. To a client who reasonably expected to hand over a problem and receive a solution, and a project that needed them reachable to stay on course.
By the time anyone writes code, the outcome is already decided. Development is execution.
The clients who come to us after a project failed somewhere else almost always describe the same cause, and it is not bad engineering. The previous supplier never understood the operation. You can usually see that coming from the first meeting: they ask what the app should be built with, and never ask what has to change in your business or how you will know it worked.
The good news is that your part is small and completely learnable. What follows is the whole process, stage by stage, with what happens, what you do, and the warning sign that tells you something is off. You do not need to understand any of the technology to use it.
Working with a development agency runs in eight stages. Read the right hand column of each one first, because that is your side, and it is the part no proposal describes. Timings assume a focused first version built around one workflow; bigger systems stretch the middle stages rather than the shape.
Nobody writes code. We ask how work actually reaches the people doing it, what happens when something goes wrong on site, and what a finished job looks like in your records today. For a field service operation that means talking to the dispatcher and to a technician, not only to whoever signs the contract.
Give us access to the people who do the work. An hour with a technician is worth more than a week of documents, because the documents describe the process as designed and the technician describes it as it runs.
The conversation becomes a written document: who uses the app, what each of them can do, what it connects to, and, most importantly, what is deliberately not included in this version. That document is what a fixed price is priced against.
Read it and say where it is wrong. This is the cheapest moment in the entire project to change your mind, by a very wide margin. An afternoon of your attention here is worth weeks later.
The screens get drawn and linked together so you can click through the app before it exists. It looks real and does nothing, which is exactly the point.
Click through it yourself, then put it in front of someone who will use it daily. They will spot things you cannot, because they are the ones who will be doing it with cold hands in a van.
The app gets built in fortnightly cycles, and each one ends with a demo of software that actually runs. You will see something visibly unfinished in week four. That is a healthy project, not a struggling one.
Turn up to the demo and answer questions when they arrive. Questions do not queue politely: work stops while it waits for one, so a day of silence on your side is a day of nothing on ours.
Someone whose job is to break it goes through the app on real devices, including old and cheap ones, on bad connections, in the conditions your people actually work in. Developers do not test their own work effectively, in the same way nobody proofreads their own writing well.
Nominate one or two people from the field for the last round, and tell them to be blunt. Polite feedback at this stage is expensive.
Your people take it out on real work. This is where requirements appear that nobody could have written down. On TimeFix the work timer had to keep running when a technician locks the screen, and when they place a call from inside the app itself. Neither was in the original assumptions. Neither would have come out of a specification meeting.
Bring your team in early enough that what they find can still change cheaply. They will find the same things whether they start in week eleven or after go live. What differs is the cost of acting on it. Pick the people who will tell you the truth rather than the ones who will be agreeable.
Apple and Google review the app before it goes live. The review does not always follow a business model, particularly around whether money moving through the app should be running through in app purchases instead. Apple is protecting its own commercial interest there, which is fair enough. It is rarely a real problem and it gets resolved by explaining the model to them, not by changing the product.
The real risk at this stage is not the review, it is the developer account. Setting one up for a company means verifying the legal entity, and configuring it afterwards is not a fifteen minute job. We have had a finished app sitting and waiting on an account that was started too late. Begin it in week one. If the app is only for your own staff, ask about distribution routes that avoid public review entirely.
Delivery closes with a signed acceptance protocol, checked against the scope document rather than against anyone's memory of a conversation. On larger contracts we add a one year warranty on the software, which draws the line where it belongs: anything inside the agreed scope that stops working is ours to fix, not a support ticket you pay for. After that, iOS and Android keep shipping major versions every year whether or not you have plans.
Read the acceptance protocol against the scope, not against your memory, and get the warranty terms in writing before you sign rather than after. Then decide who inside your business owns the app. Not who uses it, who owns it: the person who collects what the field is asking for and decides what happens next.
Everything above condenses into four things. None of them technical, and together they predict whether a project lands on time better than anything the supplier does.
None of that requires you to understand software. It requires you to be available, which for most operations leaders is the harder ask, and it is worth knowing that upfront rather than finding out in month two.
If you want the version of this with numbers attached, our guides to what a mobile app costs and how fixed price delivery works cover the commercial side. If you are at the point of wanting the scope written down properly, that is what an app discovery workshop produces.
Tell us what is costing you the most time and who is doing it today. We will tell you which workflow we would build first, what we would leave out, and what your side of it would involve.
Book an intro call30 minutes, no preparation needed.