Mobile app development
Mobile apps connected to the systems your business runs on
iOS and Android applications for your customers, field teams and operations, built on the same backend as the rest of your platform and supported after they reach the stores.
For companies that need an app to do real work: capture data, serve customers or run a process, not to exist as a store listing.
- Platforms
- iOS and Android from one codebase
- Stores
- Submission and review handled
- After launch
- OS updates and releases under the same agreement
Apps
- iOS app
- Android app
- Admin panel
Services
- API layer
- Authentication
- Push notifications
Your systems
- CRM or ERP
- Payments
- Existing database
One codebase
iOS and Android ship together from a shared codebase.
Connected
The app reads and writes the same data as your other systems.
Maintained
OS updates and store requirements are handled on a schedule.
The business problem
Most business apps fail because they were built as a separate project.
An app is usually commissioned as a standalone deliverable: designed, published and left alone. It does not talk to the systems that hold the real data, the next iOS release breaks something nobody is watching, and the team that built it has moved on.
- Staff re-enter in a spreadsheet what they already captured in the field
- Customers call to ask for information the app should already show
- An existing app is rated poorly and nobody owns the fixes
- Separate iOS and Android codebases, each one behind the other
- The app works on office Wi-Fi and fails where users actually are
- Store rejections and OS updates delay every release
Outcomes
What a mobile app should change.
- 01
Work captured where it happens
Field data, photos, signatures and status updates recorded on the device and synced to your systems.
- 02
One source of data
The app reads and writes the same records as your web platform and back office, through a documented API.
- 03
Parity across platforms
iOS and Android ship together, with native code only where the platform requires it.
- 04
An app that stays current
OS updates, dependency upgrades and store requirements handled on a schedule, not in an emergency.
Scope
What can we build?
Most projects fall into one or two of these categories.
Customer apps
Accounts, orders, status, documents and support in the customer’s pocket.
Field service apps
Jobs, checklists, photos, signatures and routes for teams away from a desk.
Internal operations apps
Approvals, inventory, inspections and requests for your own staff.
Booking and ordering
Scheduling, reservations and orders connected to your availability and payments.
Companion apps for SaaS
A mobile client for a web platform you already run, sharing its API and accounts.
Loyalty and membership
Member cards, points, benefits and notifications tied to your customer records.
Offline-first data capture
Apps that keep working without a connection and sync when one is available.
App modernization
Taking over, stabilizing or rebuilding an existing app without losing its users.
Fit
Who this service is for.
A good fit when
- People need to do part of their work away from a computer.
- Customers already use your service often enough to keep an app installed.
- The data the app needs already lives in a system, or should.
- An existing app has users but no reliable owner.
- Someone internally can decide what the first release must include.
Probably not yet when
- A responsive website would serve the same users with less cost to maintain.
- The goal is a store presence rather than a tool people use.
- The budget covers a launch but nothing after it.
Process
How an app is built and released.
Each stage produces something you can review on a real device before the next one starts.
Discovery
Who uses the app, where, how often and with what connection. What it has to read from and write to.
Product definition
The first release written down: screens, rules, integrations and what is deliberately deferred.
UX/UI
Flows designed for one-handed, interrupted use and tested with the people who will rely on them.
Architecture and API
Backend, data model, authentication and integrations defined before app screens are built.
Development
iOS and Android built together, with test builds on your devices at every milestone.
Testing and store release
Device testing, internal test tracks, store listings, privacy forms and submission.
Maintenance and iteration
OS compatibility, fixes, analytics review and the next set of features on an agreed cadence.
Store release
Publishing is part of the work.
An app is not finished when the code is. It has to pass App Store and Google Play review, meet each store’s privacy requirements and keep passing them with every OS update. ZitDevs handles that process and documents it.
Store accounts in your name
Developer accounts, signing keys and listings are set up under your organization wherever the stores allow it.
Releases you can follow
Every build goes through internal testing before submission, with release notes written for your team.
- Apple developer account Under your organization
- Google Play Console Under your organization
- Internal test builds Before every release
- Crash and performance reporting Configured at launch
- Privacy labels and data forms Completed per store
- OS compatibility review Each major release
Technology
How the app is built.
Cross-platform development keeps iOS and Android in step and halves the code to maintain. Native code is used where a feature or performance requirement justifies it.
If you already run a backend, the app is built against it rather than beside it.
Cross-platform
- React Native
- Expo
- TypeScript
Native when required
- Swift
- Kotlin
- Device APIs
Backend
- Node.js
- NestJS
- PostgreSQL
- REST and GraphQL
Delivery
- Automated builds
- TestFlight
- Play internal testing
- Crash reporting
Engagement models
How the work is contracted.
Project-based
A defined first release, timeline and store launch.
- Written scope and screen inventory
- Store submission included
- Best for a new app
Dedicated team
Mobile and backend engineers aligned to your roadmap.
- Composition set by workload
- Continuous releases
- Best for an evolving product
Managed monthly
Maintenance and continued development after launch.
- OS and store compliance
- Prioritized backlog
- Best for apps already in the stores
Why ZitDevs
How we keep the app useful after launch.
Built with the backend
The API, data model and integrations are part of the same engagement, so the app is never waiting on another vendor.
Cross-platform by default
One codebase for iOS and Android unless a requirement justifies native code, and we say which one.
Bilingual from the first screen
Interfaces, store listings and notifications in English and Spanish, written rather than machine-translated.
Maintained after the listing
OS updates and store policy changes are handled on a schedule as part of the service.
FAQ
Questions about mobile app development.
Answers are written for this service. Where a figure depends on your situation, we say so instead of publishing an average.
How much does a mobile app cost?
Cost depends on the number of screens and user roles, the integrations with your systems, whether the app must work offline and whether a backend already exists. We give a written estimate after discovery, with the assumptions stated so you can see what would change it.
How long does it take to build an app?
It depends on the first release, not the eventual product. We scope a first version small enough to reach the stores, then sequence the rest. Store review adds time at each submission and is included in the plan.
Do you build for both iOS and Android?
Yes. By default both are built from a shared React Native codebase and released together. Where a feature needs native code, we explain why before building it.
Can you take over an existing app?
Yes. We start with a technical review of the codebase, dependencies, store accounts and backend, then recommend whether to stabilize, extend or rebuild. The review is a deliverable you can act on with or without us.
Do you handle App Store and Google Play publishing?
Yes. Store listings, privacy forms, test tracks, submission and responses to review feedback are part of the engagement.
Can the app work offline?
Yes, where the use case needs it. Offline support is designed into the data model from the start, because adding it later usually means rewriting how the app stores and syncs information.
Who owns the app and the source code?
Ownership of deliverables is defined in the contract for each engagement, before work begins. Store accounts are set up under your organization wherever the stores allow it.
Do you provide maintenance after launch?
Yes. A managed monthly service covers OS compatibility, dependency updates, crash monitoring, store policy changes, fixes and new features.
Tell us who will use the app and what it has to do.
Describe the users, the work the app should support and the systems it needs to talk to. We will come back with a first release, a plan and an honest view of what it takes.
The form is preselected for mobile applications, so the questions match the project.