What Enterprise App Development Really Involves
An enterprise app is defined less by the size of the company and more by its constraints. Users authenticate through corporate identity. Devices may be company-owned, BYOD, or rugged scanners. Data comes from systems that predate the app by a decade. Security, legal, procurement and IT all have sign-off rights.
The work we typically take on includes field-service and inspection apps, sales enablement tools that sit on top of the CRM, warehouse and logistics apps for handheld scanners, employee self-service portals, and partner or dealer apps that expose a controlled slice of internal data. Many of these start as custom software built around a specific workflow rather than a general-purpose product.
| Concern | Typical consumer app | Typical enterprise app |
|---|---|---|
| Sign-in | Email, social login, passkeys | SSO via SAML or OIDC, MFA enforced by the IdP |
| Distribution | Public app stores | MDM, Apple Business Manager custom apps, managed Google Play |
| Data sources | App's own backend | ERP, CRM, HRIS, legacy databases, file shares |
| Access control | User owns their data | Roles, groups, regions, delegated admin |
| Logging | Product analytics | Audit logs, SIEM export, retention policies |
| Release cadence | As fast as possible | Aligned with change windows and UAT |
Identity, SSO and Access Control
Most enterprises already run an identity provider, and the app should defer to it. For mobile, we implement OpenID Connect with the authorization code flow and PKCE through the system browser (ASWebAuthenticationSession on iOS, Custom Tabs on Android) so users get the IdP's own MFA and conditional access screens. For web portals that must support older IdP setups, we add SAML 2.0 service provider support.
- SCIM 2.0 provisioning so accounts are created and disabled from the IdP, not by hand.
- Group-to-role mapping that turns IdP groups into application roles without hardcoding names.
- Short-lived access tokens with refresh token rotation and server-side revocation on offboarding.
- Step-up authentication for sensitive actions such as approvals or data exports.
- Attribute-based rules where access depends on region, cost center or site, not just role.
MDM, Distribution and Device Security
If your devices are managed, the app should cooperate with the MDM rather than fight it. We support managed app configuration through AppConfig so IT can push server URLs, tenant IDs and feature flags without a rebuild. For Microsoft shops, we can integrate the Intune App SDK so App Protection Policies, such as blocking copy and paste into personal apps, apply even on BYOD devices.
- Private distribution through Apple Business Manager custom apps or managed Google Play private apps.
- Encrypted local storage with keys held in the Secure Enclave or Android Keystore.
- Jailbreak and root detection with policies your security team defines.
- Remote wipe of app data on logout, offboarding or MDM command.
- Certificate pinning where your threat model calls for it, with a documented rotation plan.
Platform choice matters here. Shared rugged Android scanners often justify native Kotlin development for Android devices, while knowledge-worker apps on mixed fleets frequently suit a single cross-platform codebase.
ERP, CRM and Legacy System Integrations
Pointing a mobile app directly at SAP or a 15-year-old SQL Server is how projects stall. We put an integration layer, usually a backend-for-frontend service built with Node.js or your existing platform, between the app and systems of record. It handles authentication to each system, data shaping, caching, rate limits and retries, so the app sees one consistent API.
| System | Typical approach | Watch out for |
|---|---|---|
| SAP S/4HANA or ECC | OData services, BAPIs via middleware, or SAP BTP | Authorization objects, batch windows, latency |
| Salesforce | REST and Bulk APIs, Platform Events for changes | API call limits, field-level security |
| Microsoft Dynamics 365 | Dataverse Web API | Throttling, environment promotion |
| ServiceNow | Table API, scripted REST APIs | ACLs and update set coordination |
| Legacy databases | Read replicas or change data capture into a service | Schema drift, undocumented stored procedures |
Where real-time access is not required, event-driven sync or change data capture keeps load off fragile systems and lets the app work offline in warehouses and job sites with poor coverage.
Offline Operation for Field and Frontline Teams
Technicians in basements, drivers in rural areas and pickers inside steel-framed warehouses all lose signal. An enterprise app that blocks work when the network drops will be abandoned for paper. We design offline behavior explicitly per workflow instead of treating it as an afterthought.
- Scoped data sets: each user downloads only the work orders, customers or SKUs relevant to their territory or shift, keeping sync fast and limiting data exposure on lost devices.
- Local database with encryption: SQLite or Realm on device, encrypted with keys protected by the platform keystore.
- Outbox pattern for writes: every change is queued with a unique ID so retries never create duplicate orders or inspections.
- Conflict policy agreed with the business: for example, a dispatcher's reassignment wins over a technician's stale status update.
- Visible sync state: users can see what is pending, what failed and why, instead of guessing whether their work was saved.
Attachments such as photos and signed forms upload in the background with resumable transfers, so a 20-photo inspection survives a dropped connection halfway through. On the server, each synced record is validated again, because a device that has been offline for a week may be acting on outdated rules.
Audit Logging, Compliance and Governance
Audit logs answer a different question than analytics. We record actor, action, target, timestamp, device and outcome for every security-relevant event, write them to append-only storage, and stream them to your SIEM, such as Splunk, Microsoft Sentinel or Datadog. Retention follows your policy, and log access is itself logged.
We build with the requirements of frameworks like SOC 2, HIPAA, GDPR and SOX in mind and supply the artifacts your auditors ask for: data flow diagrams, access control matrices, threat models and evidence of code review and testing. Your organization owns the compliance attestation; our job is to make the app easy to attest.
Delivery Process and Timeline
- Discovery and security intake (3–5 weeks): stakeholder interviews, integration inventory, IdP and MDM review, threat model.
- Architecture and pilot scope: decision records, API contracts, and a pilot group defined by site or department.
- Iterative build: two-week sprints with demos to business owners and a shared UAT environment.
- Security testing: SAST, dependency scanning, and support for your third-party penetration test.
- Pilot rollout: MDM-based distribution to a limited group, with support and telemetry in place.
- Phased expansion and handover: runbooks, admin training, and an agreed support model.
A first enterprise release commonly takes 5–9 months. You can see how we structure phases and checkpoints on how we run projects.
Cost Drivers for Enterprise Apps
Enterprise projects usually fall in the complex range, roughly $150k–$400k+ for an initial release, as a market estimate that depends heavily on scope. The biggest swing factors are the number and condition of integrations, offline requirements, the number of roles and approval workflows, and the depth of security review. Our overview of app development costs explains how these drivers stack up.
We can work as a fixed-scope team for a defined pilot or as a dedicated team embedded with your IT organization; the trade-offs are outlined in our engagement models.