Powstania Warszawskiego 15
31-539 Kraków
Most companies that ask us for an app already run something. An ERP, a service management system, a warehouse program, a customer database, or a set of spreadsheets that one person maintains. The app rarely replaces it. The question is how the two talk to each other, and that answer sets a large part of the budget.
Discovery conversations usually open with screens. Someone describes a list of jobs, a form, a photo upload. That part is easy to agree on and it is not where projects go wrong.
Mobile app integration with existing systems is where these projects are decided. The part that sets the schedule is what sits behind those screens. If a technician opens a job in the app, that job came from somewhere. If they close it, something has to know. The path between the app and that something is the actual project.
So the first question worth answering, before any estimate is credible, is simple. What system holds your jobs, customers, and inventory today, and what can it give us.
Almost every company we talk to falls into one of these. The label matters because it changes both the estimate and what we need from your side to keep the estimate true.
The best case. The vendor publishes endpoints, authentication, and limits. We read the documentation, confirm that the data you need is actually exposed, and build against it. Integration becomes a known quantity early, which means the fixed price around it is solid rather than padded.
More common than it sounds. The system has an interface, but it is licensed separately, it requires a support ticket, or the vendor treats integrations as a paid project of their own. The engineering work is unchanged. The calendar is not, because it now depends on a third party who has no deadline.
Older systems and in house tools often have no interface for anything outside themselves. Then the options are a scheduled file exchange, a reporting database, or a small service that sits next to the system and exposes only what the app needs. All three work. They differ in how fresh the data is, and freshness is the thing to decide consciously rather than by accident.
Many working operations run this way and it is not a failure. It does mean the app has no stable source to read from, because a spreadsheet changes shape whenever someone adds a column. We usually treat the file as a starting import, then let the app own that data going forward, which is a change in how your team works and is worth naming out loud.
Two systems holding the same record will disagree eventually. A dispatcher edits a job in the office at the same moment a technician updates it in the field. Both actions are legitimate. Something has to win, and that rule is a business decision, not a technical preference.
There are only three workable answers, and picking one early removes an entire category of later argument.
We put this in the written scope before development starts, alongside the rest of the requirements document. It is one page and it prevents a lot of expensive rework.
Across our projects the most consistent cause of delay is not integration code. It is waiting on the client side for access to third party services and store accounts. Setting up an Apple developer account and configuring it properly is not a quick task, and neither is getting credentials for a system that another department owns.
The practical fix is boring and it works. Name one person who can approve access, start those requests in the first week, and treat them as project tasks with owners rather than as paperwork that happens later.
If your people work in basements, on rural routes, or inside buildings with no signal, the integration is no longer a call that either succeeds or fails. Work happens on the device and reaches your system later, which introduces ordering, retries, and the possibility of two people changing the same record.
That is why we always ask what offline means for your operation before quoting it. Viewing data that was downloaded earlier is inexpensive. Completing forms and photos that sync later is a real build. A full day of work with one sync is a different product again, and we go through the three levels on the offline first app development page.
One detail from real use is worth repeating. On a field service app we built, technicians started keeping notes in their phone notepad for the one case the app did not cover yet, which quietly created a second version of the truth outside the system. The gap between what the app supports and what the job requires does not stay empty. Someone fills it.
Integration scope is not a single line item. These are the factors that actually change the number, in roughly the order they matter.
The pattern repeats with different names. In field service the app talks to whatever schedules the jobs, and the practical questions are covered on the field service app development page, with the drivers of the number on field service app development cost.
In heating and cooling the record that matters is usually the equipment rather than the customer, because service contracts, warranties, and history hang off the unit. That changes the data model before it changes the screens, which is why we treat custom HVAC software development as its own conversation.
In booking and marketplace products the integration is often payments and calendars rather than an ERP, and the store review adds a step, since Apple checks whether payments should run through in app purchases. That is predictable and resolved by talking to them, but it belongs in the timeline rather than in a surprise.
We work on fixed price, so the integration has to be understood before the number exists. That is the whole purpose of the workshop at the start.
Our team is in Krakow and works with companies across the continent on European hours. That matters more than usual on integration projects, because these need short conversations with your IT people rather than overnight message threads.
There is more on the working model on the app development for European companies page, and for teams in the United States on app development for NYC businesses and Flutter app developers in Poland.
On TimeFix, a field service app with an office panel, the work timer had to keep counting when a technician locked the screen or took a call from inside the app. That requirement did not come from the specification. It came from real shifts, and it is the kind of thing that only surfaces once data starts flowing between the field and the office.
On Workly we built an ERP class system for manufacturing in Flutter on Supabase, with one interface that behaves the same on a phone and on a desktop. When the operational system and the mobile client are designed together, most of the integration questions in this article turn into ordinary product decisions instead.
Usually yes. If the ERP publishes an API we build against it. If it does not, we use a scheduled export, a reporting database, or a small service that exposes only the data the app needs. The path changes the effort, so we confirm it during discovery rather than assuming it.
It is still workable. The trade off moves to how current the data is. A sync a few times a day is straightforward. Near real time without an API means building the missing interface, which is a separate piece of scope and gets priced as one.
You do, during scoping. We present the three workable rules, you pick per record type, and it goes into the written scope. Without that decision the conflict simply appears later, in production, with a customer watching.
A single documented API against a clean data model usually adds days rather than weeks. Several systems, poor data quality, or a vendor who controls access can add considerably more, which is why the estimate depends on the answers above.
Strongly recommended. Testing writes against a live operational system slows everyone down, because every mistake is a real record. If a sandbox is impossible we work around it, with tighter controls and a slower pace.
You do. Repositories, accounts, and data transfer to your side at acceptance, the same as the rest of the build.
I run scoping calls for operations teams building their first mobile app, and I have watched enough of these projects to know that the integration question decides the schedule long before the design does.
We go through your process and the systems behind it. On that basis we prepare a written scope for the first version, with a timeline and a fixed price.
Book an intro call30 minutes, a direct conversation about your goals.