Powstania Warszawskiego 15
31-539 Kraków
Your app is live, your users depend on it, and it now needs something big: video, payments, offline sync, a second language. The quotes you get back will differ wildly, and most of that spread comes from what the teams could not see. This is what to put in front of them so the number means something.
Before asking for quotes on a new feature in a live Flutter app, prepare six things: read access to the repository, a list of the backend and third party services the app uses, the state of the store accounts and release process, a one page description of the feature written around the user's situation, the constraints that cannot move (dates, compliance, existing users), and a named person who can decide. With those, a team can review the code first and quote the feature against the app you actually have, not against a guess.
A new feature in an existing app is never only the feature. It lands on top of a data model, a state management approach, a backend, a set of third party services and a release process that somebody else designed. Each of those either absorbs the feature cleanly or has to change first.
A team that has not seen the code prices that uncertainty in. Some add a large buffer. Some quote low and discover the rest later, as change requests. Neither number tells you what the feature will actually cost, which is why the most useful thing you can do is remove the uncertainty before anyone quotes.
None of these require technical knowledge. They require a few hours of collecting what already exists.
The full history, not a zip of the current state. History shows how the app grew, which parts change often, and where earlier teams struggled.
Why the quote needs itThe team can price your codebase instead of an imagined one.Where data lives, which services send notifications, handle payments, store files or authenticate users, and who holds the logins for each.
Why the quote needs itMost major features touch at least one of these, and replacing one is a project of its own.Who owns the Apple and Google developer accounts, whether signing keys are available, and how the last release was published.
Why the quote needs itA feature is only delivered once it can be released, and releasing is where hidden gaps appear.Written around the user's situation: who uses it, in what context, what they do today instead, and what happens when it fails. Mockups are welcome but secondary.
Why the quote needs itThe situation decides the hard parts, such as poor connectivity, permissions or data volume.Launch dates tied to something outside the app, compliance or accessibility requirements, and how many users must not notice the change.
Why the quote needs itA fixed date or a zero downtime rule changes how the work is sequenced.Someone available during the build who can answer scope questions within a day or two, without a committee.
Why the quote needs itSlow decisions stretch a fixed scope into a longer calendar.
When we are asked to add something to an app we did not build, we start with a short code review and give an honest read of the codebase, usually within two weeks. The first questions are rarely about Flutter itself. They are about how data is modelled, how the app handles state and errors, and how releases are built and signed.
The review answers one practical question: can the feature be added as it is, or does something underneath have to be fixed first? If something has to be fixed, you hear it before the price, not halfway through the build. If the whole app needs a new owner rather than a new feature, that is a different job, covered in taking over a live mobile app.
A useful signal when comparing teams: watch what they ask about first. Clients who came to us after a project went wrong elsewhere describe the same pattern, a supplier who asked about technology on the first call rather than about the business and the people using the app.
Major features fall into roughly three groups, and the group matters more than the size of the feature list.
A new dashboard, a redesigned flow, a report. The data already exists. Quotes here are usually close to each other.
Multiple languages, offline work, new roles and permissions. The feature reaches into every layer, and the existing model decides the effort.
Group video, payments, subscriptions, a new identity provider. A third party service, a backend that issues access, and store rules all come into play.
A request such as secure group video rooms sits in the third group. The video itself comes from a specialised service. The work is everything around it: who may join which room, how access is granted and revoked, what happens on a weak connection, and what the stores require before the release goes out.
The cheapest moment to find out that a feature needs structural work is before the quote, not in the fourth week of the build.
Liniowiec is an offline first Flutter app for inland waterway navigation, covering more than 1,000 km of routes. After the first version went live, the next stage added new map modules, water level data, full WCAG AA accessibility and support for English across Android, iOS and the web.
Two things made that stage predictable. First, the scope was written down as a document, module by module, before any estimate. Second, time spent on the database schema in the first version paid off: routes were versioned and the relations between data were designed properly, so new modules had somewhere clean to attach.
The language support shows how a feature that sounds simple turns structural. It had to work in the admin panel, the mobile app and the web frontend, with a decision between manual translation when data is added and automatic translation, across large sets of route data. None of that is visible in a screen mockup, and all of it is in the quote.
If you already have developers, adding an outside team does not have to mean replacing anyone. There are two common shapes. In the first, the outside team delivers the feature as a defined package on a fixed price, with its own acceptance, while your team keeps running the rest of the app. In the second, experienced developers join your team for a period and work inside your process.
The first suits a feature with clear edges, such as a new module. The second suits a long list of changes spread across the app. Either way, agree early who reviews whose code and who owns the release. We describe the second shape in more detail under Flutter developers for an existing team, and the first under fixed price app development.
In our experience the most common delay is not code. It is access: store accounts that were not set up or not transferred, and logins to third party services that arrive weeks after the project starts. Collecting them before you ask for quotes is the single cheapest way to shorten the calendar.
The second is requirements that only surface in real use. On one field app, the work timer had to keep running when the screen was locked or a call was placed from inside the app. That could not have been specified in advance, which is why a feature is accepted only after it has been used in real conditions.
Delivery closes with an acceptance protocol: the agreed scope is checked against the working app and signed off. On larger contracts we include a one year warranty on the software, so anything inside the agreed scope that stops working is ours to fix.
The same approach applies whether the app is a consumer product or an operational tool. Field teams are a common case, where new modules such as offline reporting or service contract handling are added to a running app; see field service app development and custom HVAC software development for how those are scoped.
Yes. We start with a short code review, usually within two weeks, and tell you whether the feature can be added as it is or whether something underneath has to change first. You get that answer before the price.
Read access is enough, and it is what turns an estimate into a real number. Without it, any quote includes a buffer for what the team could not see.
No. A feature can be delivered as a separate package on a fixed price while your team runs the rest of the app, or our developers can join your team for a period. The choice depends on how contained the feature is.
Usually not its size. Features that change the data model, such as offline work or multiple languages, and features that add outside services, such as video or payments, reach into more of the app than new screens do.
It depends on which of the three kinds the feature is. A contained feature can take a few weeks; structural and external features take longer and are usually split into milestones. You get the timeline together with the fixed price, and our discovery workshop is where it is agreed.
In Poland, working with clients across the United States and Europe. More on how that works in practice is on Flutter app developers in Poland.
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.
Tell us what the feature has to do and who depends on the app today. We will tell you what we need to see before quoting, and whether the feature can go in as it is.
30 minutes, no preparation needed.