Powstania Warszawskiego 15
31-539 Kraków
The suppliers who fail your project and the ones who deliver it look almost identical in a proposal. They separate on the first call, in the contract, and in what happens when something changes. Here is what to check, in the order that actually protects you.
The strongest predictor is what the supplier asks about before quoting. Teams that ask about your operation, your users and the business value of the work tend to deliver something that fits. Teams that lead with technology, team size and hourly rates tend to build exactly what was written down, which is rarely the same as what you needed.
This is not a soft signal. Every project we have taken over from another supplier failed for the same underlying reason: the previous team never understood the operation well enough to build for it. The code was often fine. It solved a problem that had been described inaccurately, and the error went unnoticed because the right questions were never asked.
You can test this in one meeting without any technical knowledge. Count the questions. If most of them are about your business, your customers and what happens today without the app, that is a good sign. If most of them are about platforms, frameworks and deadlines, you are talking to an order taker.
Ask who owns the code and the store accounts, how a change of scope is handled and priced, how the project is formally accepted as finished, whether there is any warranty on the work, and who you will actually talk to during delivery. The answers to those five separate suppliers faster than any portfolio review.
Ignore the visuals and look for the constraint. A useful case study names what was difficult, what the supplier decided, and what changed for the client. If every project in the portfolio reads as a smooth success with no problems and no decisions, you are looking at marketing rather than evidence.
Ask about a project that went badly. Not to catch anyone out, but because the answer tells you how they think. A supplier who can describe a real failure, name the cause and explain what they changed afterwards is a supplier who runs a retrospective. One who has never had a problem has either never shipped much or is not being straight with you.
Also check whether the case studies name any constraint you recognise. A team that has dealt with offline work, payment models, store review, or integrations with equipment already knows where those projects break. A portfolio of simple content apps is not evidence for an operational system, however good it looks.
Fixed price is fair when the scope is genuinely defined, because the scope list is what protects both sides. Hourly billing is fair when the product is still finding its shape and priorities change between sprints. The dishonest combination is a fixed price on a scope that neither side could describe without guessing.
When a supplier quotes a fixed price for something vague, one of two things happens. They pad the estimate to cover the unknowns and you overpay, or they hold the price and quietly narrow what gets built. Both are predictable and both are avoidable by scoping properly first.
If the scope is not clear enough to price, a short paid scoping engagement is the honest answer. It should end with a written brief and an estimate you can take to any supplier, including a different one. If a scoping engagement produces something you cannot use elsewhere, it was a sales exercise.
We go through both models and where each one breaks in our guide to fixed price app development, and the shapes of our own engagements are on the pricing page.
A freelancer fits a small, well specified piece of work with an owner already in place. An agency fits a full product where design, development, QA and release have to be coordinated. In house makes sense once the product is core to the business and needs continuous work. No code tools fit validation, not operations.
It usually does, if two conditions hold: meaningful working hour overlap and one accountable person on their side. For companies in the United States and Western Europe, a team in Central Europe overlaps the full European day and the American morning, which is enough for same day decisions.
The risk in cross border work is rarely quality. It is latency in decisions. A question that waits eighteen hours for an answer costs a sprint. Before signing, agree how fast you both expect to answer each other, because that number does more damage or good than the hourly rate.
Language matters more than it seems too. Not fluency in the abstract, but whether the supplier can run a discovery conversation about your business in your language, and write documents you can circulate internally without translating them first.
Watch for an estimate produced without questions, a proposal with no scope exclusions, an unwillingness to name who will do the work, publishing under the supplier's own store accounts, and no mention of what happens after launch. Each one is survivable alone. Two or three together predict a difficult project.
One person who is empowered to decide, availability rather than a fixed number of hours, and early access to accounts and third party services. Most delays we have seen came from the client side and from exactly these three, not from engineering.
The single most expensive gap is a missing decision maker. When approvals go through a committee, every design question becomes a week, and the timeline everyone agreed on stops being achievable in the second sprint.
The second is access. Setting up and configuring an Apple developer account is not a quick task, and it has delayed real releases. Third party keys and service accounts belong at the start of the project, not in release week.
The third is testing with real users. Some requirements exist nowhere except in how people actually work, and they appear the first time your own team runs the app in real conditions. Plan for that while there is still time to react. We wrote about what each stage asks of the client in this guide.
Put them side by side on five things: what is explicitly excluded, who owns the code and accounts, how change is priced, how the project is accepted as finished, and what happens in the first year after launch. Price differences usually turn out to be scope differences hiding in one of those five.
Two quotes that differ by a large margin are almost never quoting the same work. One may exclude QA, another may assume you supply the design, a third may treat store release as your problem. Normalise the scope first, then compare the numbers.
If you want the underlying cost logic rather than a single number, we break it down by app type in our guides to mobile app development cost and MVP cost by app type.
It depends far more on the operation behind the app than on the number of screens. Payments, offline behaviour, integrations with existing systems and user roles are what move the number. We publish the ranges and what drives them on the pricing page and in our cost guide rather than quoting a single figure that would fit almost no project.
Eight to twelve weeks from approved scope to a published app is a normal range for a defined first version. Operational systems with hardware or enterprise integrations run longer. Any timeline should come with its conditions attached, because the largest variable is usually how fast decisions and access arrive from your side.
Only after you have checked that both offers cover the same work. In practice the cheaper proposal often excludes QA, design, store release or the first year of fixes. The projects we have been asked to rescue were rarely cheap in the end, because the second supplier pays for the first one's decisions.
Start with an honest audit of the codebase before deciding anything. Sometimes continuing is cheaper than rebuilding and sometimes it is not, and that answer depends on the state of the code, not on how much has already been spent. We describe how a takeover works on our end to end development page.
It helps but it is not required. What is required is one person with the authority to decide, and a supplier who explains trade offs in business terms rather than technical ones. If you cannot follow the reasoning behind a recommendation, ask for it again in plainer language. A good supplier can do that.
Industry experience helps most when your operation has non obvious rules, for example field service, inspections or equipment. In those cases ask about specific constraints they have handled, such as offline work or scheduling, rather than about the industry label. Our own field work is described on the field service page and for heating and cooling businesses on the custom HVAC software page.
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 the scope, the quote or the app that stalled. We will tell you what it is missing and what a realistic version looks like, whether or not you end up working with us.
Book an intro call