Choosing a Flutter Development Company: What to Check in the Contract, Not the Portfolio

A portfolio tells you about somebody else's business

Companies come to us after a build somewhere else went wrong. It happens often enough that we have a pattern for it, and the pattern is never that the previous team could not write code. It is that they never understood the business needs and the way the operation actually runs. They built what was described in the brief, and the brief was wrong, and no one on their side had the instinct to notice.

Those suppliers had portfolios. They had case studies with screenshots and outcome numbers. A portfolio is evidence that a company shipped something for a business whose constraints you know nothing about. It cannot tell you whether they will understand yours, and that is the variable the whole project turns on.

Reviews on platforms like Clutch are worth reading, and we ask our own clients for them, but be clear about what they do. They confirm a company exists, delivered, and did not disappear with a deposit. That is a fraud filter, not a fit test. Every checkable question is below.

Count the questions in the first meeting

This is the single strongest signal available before you commit anything, and it costs half an hour.

When a project has gone wrong at a previous supplier and we go back over how it started, the warning sign is visible in the first conversation. The supplier asked about technology instead of asking about the business problem and the concrete value the work was supposed to deliver. Which framework do you want, how many screens, do you have designs, is there an API. Those are the questions of a company positioning itself to send a quote, not to build the right thing.

None of that means technical questions are a red flag on their own. Someone has to ask them. What you are measuring is the ratio and the order. If nothing about your operation came up before the estimate did, the estimate is priced against a description, and descriptions of business processes are wrong in ways that only appear later.

Questions that indicate the other kind of company:

• What happens today without this app? There is always an existing process, usually involving phone calls, a spreadsheet, or someone remembering things. A team that has not mapped it is going to replace it with something worse.
• Who uses it, and under what conditions? A technician wearing gloves in a basement with no signal and a founder at a desk need different products, even when the feature list is identical.
• What does the person do when the process breaks? Every operation has a workaround for its own failures, and the app either supports it or gets abandoned.
• What would make this a failure even if every screen works? The answer is usually adoption or a number in the business, and it should be written down before the scope is.
• Which part of the operation is not allowed to change? Some things are habit, some are regulatory or contractual. Confusing the two is expensive in both directions.

What the contract calls finished

Ask directly: how does acceptance work, what document closes it, what are the criteria, and who signs it.

We close delivery with a signed acceptance protocol. This is not a novel idea and it is not software industry language. Anyone who has bought a machine, a production line, or a building fit out already knows the concept, and it is worth insisting on the same standard here. It defines the moment when the work has been received, when responsibility shifts, and when the final payment is due.

If the answer to that question is a version of we deploy it and you tell us if you are happy, the engagement has no defined end. Without a defined end, there is no moment at which the scope is closed, which means there is no agreed line between what you already paid for and what is now billable extra. Those arguments are much harder to have after the money has moved.

The same conversation should cover ownership. You own the code, from the start, in writing. Ask when you get the repository and what happens to it if the relationship ends early.

Who pays when something inside the agreed scope stops working

Ask it as concretely as that. If a feature we agreed on does not work three months after acceptance, who fixes it and who pays.

Watch for the answer that is really a different product. A proposal for a monthly maintenance retainer is a reasonable thing to sell, but it is not an answer to that question. It converts a defect into a subscription. Our position is that everything agreed in the fixed price scope has to work, and fixing it when it does not is our responsibility, not a line item. On larger contracts that is backed by a one year warranty on the software.

Whatever a company's model is, get it stated. The useful follow up is to ask them to distinguish, in words, between a defect and a change request, because that distinction is where the disagreements live.

The requirement that only exists once the app is running

On a field service product we built, the work timer had to keep counting when the technician locks the phone, and keep counting when they place a call from inside the app itself. That was not in the assumptions. It was not missed through carelessness. It simply did not exist as a requirement until real technicians used the thing on real jobs, and then it was obvious and urgent. You can see the product in the TimeFix case study.

The same pattern shows up on consumer products. Before EveSport went public, trainers from top gyms ran real sessions through the app with their own clients. That is the point where a booking product stops being a set of screens and becomes a schedule two people have to agree on, including when one of them needs to move a slot at short notice.

This happens on most projects that touch a working process, and it is the reason the contract question above matters more than the estimate. A fixed price with a rigid scope and no mechanism for handling what real use reveals is as risky as an open ended hourly arrangement, just in the opposite direction. One of them lets the budget run, the other lets you launch something people work around.

So ask how change is handled. Who decides whether something is a defect or a change, how a change gets priced, and how long agreeing one takes. Ask when in the plan your own people put the app in front of real users, because in our experience that is when these requirements surface, during or just after development, and the plan should have room left for them. If the answer is that the scope is locked and everything else is a new project, price that in.

Whether they tell you what they need from you, and by when

Put the question to them plainly on the first call. What do you need from me, and when do you need it. A company that has delivered several products answers with a list in seconds, because the list is the same every time and they have been burned by all of it.

• The Apple developer account. Our most common source of delay, by a distance. Enrolling an organization requires legal entity details and a person inside your company with the authority to accept the terms, and it cannot be done for you. A finished build waits for it.
• Credentials for third party services. Payments, maps, analytics, an existing CRM or ERP. Each one needs access that belongs to your company, and getting it usually means getting someone outside the project to act.
• One named person who can approve. Several people who can comment and none who can decide is more expensive than any technical problem on this list.

A company that responds to that question by talking about your vision has not shipped often enough to know what the friction is. There is a fuller version of this in what each stage of a build asks of you.

Whether they raise App Store review before you do

If your product involves subscriptions, a marketplace, or bookings, describe it on the first call and then wait.

Apple protects its own interest at review, and one of the things it checks is whether payments in your model should be running through in app purchase rather than outside the app. It does not always follow a business model correctly on the first pass. In practice this is resolved by explaining the model to Apple rather than by rebuilding anything, but it takes days, and it is entirely predictable for those categories of product.

A company that has shipped products like yours will bring it up while you are still describing the idea. If it never comes up, and you have just described a marketplace with payments in it, you have learned something about their experience without having to ask for references.

What this comes down to

Three of these checks happen in the first conversation and cost you nothing: what they asked about, whether they named what they need from you, and whether they raised the review question themselves. Three of them are contract terms you can request before signing: how acceptance works, who pays for defects inside the agreed scope, and how change is handled. That is a shortlist you can run against any company, including ours.

If you want to see how we answer them in practice, the terms are set out on our Flutter app development company page and on how fixed price delivery works. If the scope itself is still open, that is a different and earlier conversation, and it belongs in a discovery workshop rather than in a quote.

FAQ

Related guides