Chicago app briefs are rarely consumer. They are a warehouse, a delivery route or an inspection process that currently runs on paper.
App development in Chicago is dominated by internal and field applications rather than consumer products. Warehouse scanning, driver and delivery apps, inspection and compliance capture. What decides success is offline behaviour, distribution to staff devices, and integration with the systems that already run the operation.
Warehouses have dead zones, trucks go through areas with no signal and basements have none at all. Capture locally, queue, sync later, and decide in advance what happens when two people changed the same record.
Internal apps are deployed, not discovered. Enterprise distribution, single sign-on, mobile device management and a clean offboarding path when somebody leaves. None of it exists on a consumer app and all of it needs scoping.
A warehouse app that does not read from the WMS is a second source of truth and a new problem. Integration with the ERP, WMS or dispatch system is usually the majority of the work and belongs on its own quote line.
Cold hands, gloves, a scanner sled, a cracked screen and bad lighting. Target sizes, contrast, and testing on the rugged device your staff really carry rather than on a new phone at a desk.
Internal apps fail on rollout far more often than on engineering. Who trains people, who owns it internally, and what happens to the paper process it replaces are questions to settle before the build.
Code in your repository, apps under your accounts, documentation as a deliverable. In an internal system your IT team will inherit this, and that handover should cost an afternoon rather than a rebuild.
| Factor | Why it moves the number | What to ask |
|---|---|---|
| Offline and sync | Conflict handling is real engineering | What happens after eight hours offline? |
| System integration | Usually the majority of the work | Price each connection separately |
| Distribution and device management | Enterprise deployment is its own project | How does it reach and leave a device? |
| Hardware | Scanners, sleds, rugged devices | Which device will you test on? |
| Roles and permissions | Who can see and change what | How many user types? |
| Rollout and training | Adoption is the risk, not the build | Who owns this internally? |
We quote fixed scope after discovery. On an internal app the integration and the offline behaviour are the number; the screens are the cheap part.
| Ask them | A good answer sounds like | Walk away if |
|---|---|---|
| How does this reach our staff's devices? | Enterprise distribution, MDM, offboarding | Through the public store, probably |
| What happens with no signal in a warehouse? | Queued locally, synced later, conflicts handled | It needs a connection |
| Price each integration separately | A line and a number per system | Integrations listed as one bullet |
| Who owns the code and repository? | You do, in your own account, from day one | Ownership ends when the retainer does |
Internal apps fail on distribution and adoption far more often than on engineering. Ask about both before you look at a single screen design.
If the work happens at a desk or on reliable wifi and nobody needs the camera or offline capture, a web application avoids distribution, store review and two platform builds.
Building an app around a process mid-change freezes the old version into software. Settle the process on paper first; it is dramatically cheaper to change.
An internal app with no named owner and no training plan gets used for three weeks. That is a management problem the build cannot solve.
It depends on how much offline capability is needed, how many systems it integrates with and how it reaches staff devices. We quote fixed scope after discovery, because on internal apps those three things are the number.
The app keeps working. Data is captured locally, queued and synced when a connection returns, with defined rules for what happens if two people changed the same record. This is the single most important thing to scope.
Enterprise distribution rather than the public store, with single sign-on, mobile device management and a clean offboarding path. It is a project of its own and it belongs in the quote rather than as an assumption.
It usually has to. A field app that does not read from the system of record becomes a second source of truth and a new problem. Name the system and version early, because it decides most of the scope.
Yes, and we test on the device your staff actually carry rather than a new phone at a desk. Gloves, cold hands, bad lighting and a cracked screen are design constraints, not edge cases.
Cross-platform for most internal apps at roughly one build instead of two. Separate iOS app development and Android app development is justified where you depend on hardware peripherals that behave differently per platform.
You do, from day one, in your repository. Your IT team will inherit this, so documentation is a deliverable and the handover should cost an afternoon rather than a rebuild.
No. We work with Chicago companies remotely on Central hours and would rather say that than imply otherwise. Not carrying downtown overheads is part of why our numbers differ.
Send us what you are trying to fix and we will tell you what it takes, what it costs, and whether we are the right people for it. If we are not, we will say so.