Build the app, then keep it running
Mobile app development can cover iOS, Android or one cross-platform codebase, for your customers, your staff, or both. Scope can include the backend and APIs behind the app, plus maintenance after release; the code and the store accounts stay yours.
- Platforms
- iOS, Android, or one cross-platform codebase
- Built for
- Customers, staff, or both
- Can also cover
- The backend, APIs and maintenance after release
- You own
- The code, repository and store accounts
- Not included
- Games, real-time 3D, AR, app-store marketing
What it solves
The situations this is for
The work happens away from a desk
Staff on site, in a van or on a route write things down and type them in later. Detail goes missing between the job and the record, and the same data gets entered twice.
A website asked to be an app
Push notifications, offline use and the camera work unevenly in a browser, or not at all. That usually surfaces after the mobile site is already built.
Apps break while nobody touches them
New OS versions, retired APIs, expiring signing certificates and changed store rules all arrive on their own schedule. An app needs work in years when you change nothing in it.
iOS and Android drift apart
Specify and schedule the two separately, and features land at different times. Support then has to ask which phone the caller is holding before it can answer.
Scope
What the scope can include
The app
- Customer-facing apps and apps for your staff
- Apps built around a process you already run
- Native iOS, native Android, or one cross-platform codebase
- Phone and tablet layouts
Backend and integration
- Integration with APIs you already have
- New backend and API work where none exists
- Sign-in and account handling
- Offline capture that syncs when the signal returns
After the first release
- Maintenance and new features
- Updates for new operating system versions
- Builds prepared for submission through your store accounts
- Test builds sent to your internal testers
Scenarios
What this could look like
An inspection recorded on site
A scenario this covers: someone works through a checklist and photographs the fault, and the record reaches the office without being retyped. Signal is poor in that setting, so the app would hold the work and send it later.
One staff app over three systems
For example, a company runs an ERP, a ticket queue and a shift schedule, all reachable from a desk and none from the loading bay. One app could read and write to all three through their APIs, instead of becoming a fourth system to keep in step.
A founder's first app
For example, a founder wants a customer app that needs sign-in, alerts and offline use. Scope could start with a working build on real phones, sent to a small group of testers. The code and the store accounts would be in the founder's name from the start.
Method
How we would work
A starting point for the first conversation, not a fixed methodology.
- 01
App or website? Settle it first
We would ask that before any design work. Notifications, offline use and device hardware argue for an install. A login and a set of forms usually do not.
- 02
Native or cross-platform, decided together
It is a trade between cost and device access. It turns on which phones your users carry, who manages those phones, and how much of the app touches hardware. We would put that question to you rather than answer it in advance.
- 03
Real phones, early
The proposed approach is to put a working build in your own testers' hands before the store is involved. Holding an app tells you far more than its specification does.
- 04
Name who looks after it
The store accounts and the code are yours. Signing keys, store submissions and OS updates still need someone named to look after them: us, under a maintenance arrangement, or your team. We would settle that before release, not after.
Fit
Is this the right fit?
A good fit if
- Your staff work on site or on the road and type everything in later.
- The app needs notifications, offline use or the phone's camera to do its job.
- You have an app idea and your own budget, and you want to own the code.
- Someone, on your side or ours, can look after the app once it is live.
Not the right fit
People only read things and fill in forms
Build a responsive website instead. It changes when you decide rather than when a store review allows, and nobody has to install or update anything. Ask about Website Design & Development.
No one to look after it once live
Mobile platforms generate work in years when you change nothing. An unmaintained app eventually stops running on current phones, or stops being accepted by the stores. With no budget and no named person for that, do not start it; stay on the web, where neglect costs less.
Your mobile engineers need extra hands
Handing a build to an outside team splits responsibility for one codebase, and your engineers end up reviewing work they could have written. Keep the work with them. If they need another engineer, Staffing & Talent Solutions covers sourcing and screening for that role.
Questions
Questions about mobile apps
Native or cross-platform: which should we choose?
It is a trade between cost and device access. Cross-platform app development uses one codebase for iOS and Android; native apps are written separately for each, with the most direct access to the device. The choice turns on which phones your users carry, who manages them, and how much of the app touches hardware. We would put that question to you rather than answer it in advance.
Do we need mobile app development, or a mobile-friendly website?
Ask what the app has to do. Notifications, offline use and device hardware argue for an install; a login and a set of forms usually do not. A responsive website changes when you decide rather than when a store review allows, and nobody has to install it.
Who owns the App Store and Google Play accounts?
You do. The store accounts, the code, the repository and any backend accounts are yours, and builds would be prepared for submission through your accounts. Signing keys and OS updates still need someone named to look after them: us, under a maintenance arrangement, or your own team.
What happens after the app launches?
An app needs work even in years when you change nothing in it, because new OS versions, retired APIs and expiring certificates keep arriving. Scope can include maintenance, new features and OS updates, or that work can stay with your team. Either way, we would settle who does it before release.
Can the app connect to our existing systems?
Scope can include app backend integration through the APIs you already have. The app would then read and write to your systems instead of becoming one more to keep in step. Where there is nothing to connect to, scope can include new backend and API work.
Are you a mobile app developer in Oklahoma?
Traittek LLC is a software development company in Edmond, Oklahoma, and mobile application development is one of its nine services. Enquiries are answered by email at info@traittek.com. A useful first message says who would use the app and where they would be when they use it.
Start with who would use the app
Describe who would use it, where they would be at the time, and what it has to connect to.