We deliver the whole app: discovery and scope, UX, visual design and a design system, a working prototype for sign-off, then engineering and testing on real devices, then store requirements and publishing with the review handled, then monitoring and post-launch support — eight published steps, each with its output.
Direct answers
With a scoping session rather than a quotation: we define the primary user, the problem the app solves, the smallest version that proves the idea (not every feature), and what the first release explicitly excludes. That protects the budget from creep and makes release one measurable. The session produces a written scope and an initial screen map — before any code and before any financial commitment.
We build both platforms from one codebase where the operation allows it, because it is faster and cheaper to maintain. But that is a trade-off, not a rule: apps relying on deep system features — advanced camera work, Bluetooth, always-on background work, heavy graphics — may need native code per platform, and we say so in the scoping session. The decision follows the requirements, not a technical preference.
The account is in the client’s name, not ours: the Apple Developer or Google Play account is opened under the client’s ownership with the fees on them, because the app is a company asset and should not hang off a vendor. We handle the technical preparation — signing and certificates, store listing, screenshots, age rating, data-collection declarations — then the upload and the review follow-up. If you already have an account, we work with it directly.
We guarantee no approval, because the review decision belongs to Apple and Google rather than to us, and we guarantee no timeline for it. What we do commit to method: preparing the submission against the stores’ requirements before a likely rejection (privacy policy, data declarations, permission justifications, in-app purchase where relevant, account and deletion requirements), and handling any rejection with a written reason and resubmitting. An active account and policy compliance are prerequisites for approval.
Deliverables
Eight tangible outputs, each with a file or a system you can inspect — not a promise of an app built and then abandoned.
What release one will do, what it explicitly excludes, and the map of screens and flows before any design or code.
Output: a scope and a screen map
Content structure and step order, the shortest path for the user to finish the task, and error, empty and offline states.
Output: logically reviewed flows
Screens designed at real dimensions, with unified components, type, colour and states that speed up every later screen.
Output: a design file and a component system
A prototype you tap through on a phone before coding, so the sign-off is on behaviour rather than on a picture.
Output: a tappable prototype
The app built for iOS and Android as scoped, in organised, documented code owned by the client from day one.
Output: installable builds
Documented APIs, a database, and a console where your team manages content, users and orders without a developer.
Output: a documented API and an admin console
Connecting orders, stock, invoices and customers to the systems you run (Odoo and others) through inspected APIs rather than double entry.
Output: a tested integration
Signing and certificates, the store description, screenshots and age rating, the privacy policy and data-collection declarations, and a file for handling any rejection.
Output: a submission-ready package
Delivery steps
Eight steps, each with a published output. The step usually skipped — preparing the stores’ requirements — is written out here because it delays launches more than anything else.
A scoping session: the primary user, the problem, the smallest version that proves the idea, what release one excludes, and the systems to connect.
Output: a written scope and a screen map
Ordering and shortening the steps, and defining what happens on error, lost connection and missing data — before any screen is drawn.
Output: defined flows and states
Screens at real dimensions and a unified component system that carries into every later screen and shortens the time for any addition.
Output: a design file and a component system
A prototype tested on a phone, then a written sign-off on the flows before coding starts — because changing a design is cheaper than changing code.
Output: sign-off on the prototype
Building the app, the backend and the admin console, in organised code in your repository, with weekly installable builds you can try.
Output: an installable build each week
Testing across devices and system versions, weak-network conditions and screen sizes, fixing what surfaces before release rather than after it.
Output: a test report and closed defects
Signing and certificates, the listing, screenshots and age rating, the privacy policy and data declarations, then upload, review follow-up and answering any rejection with a written reason.
Output: the app published or a documented rejection response
Watching stability and crashes on the real release, shipping fixes, and improving what actual usage reveals in the first cycle.
Output: a stability report and fixes
Inside the work
The expected set: the screen map, the visual design, the design system, the prototype, app screens, and the store listing.
The images shown now are temporary placeholders that mark each slot and what it should contain. They are replaced with real screens from the dashboard (/admin/mobile-apps-screenshots) with no code change. All of them use anonymised demo screens, never a real client app.
Measurement
Indicators read from the development tools and the runtime data, not promised figures.
From the start of engineering to a build you can install and try — because seeing something work early surfaces gaps before it is too late.
The share of crash-free sessions on the published release — the first thing a user actually feels.
What remains open and how severe it is, because releasing without a published defect list is a decision rather than a surprise.
Which devices and OS versions were actually tested and which were not — so nobody assumes everyone sees what you see.
From a confirmed defect arriving to a fix being released, noting that store review time is part of that time, not outside it.
We announce no download count, no store ranking and no retention rate: those are outcomes of the market, the marketing and the product experience, not of code. What we measure here is delivery quality and app stability on real devices, and we present it in a report.
App types
Each kind has its own details: a delivery app is not a field-service app, and a customer app is not an employee app.
Browsing, buying, order tracking and notifications, with the online store and the tills on the same stock.
Field tasks, visit logging and photo reports that work offline and sync later, with precise per-role permissions.
Assigning orders to drivers, tracking status, capturing proof of delivery, and measuring the time of each stage.
An ordering and delivery app with branch pickup and a loyalty programme, a menu managed from the console, and till integration.
Logging works and materials with photos and location, and progress reports that link the site to the office without paper.
Appointment booking, reminders and visit history, with privacy and consent handled carefully around health data.
Listing units, media tours and viewing requests, with enquiries connected to the contracts and collections system.
Content, learning paths, assessments and progress tracking, with offline operation for weak-network areas.
Integration
We connect the app to the systems you already run — orders, stock, invoices and customers — so the work is not managed in two places.
An app order deducts from the same stock and creates the sales order and invoice, so the work is not run in two systems.
The primary integration
Connecting the payment provider you hold a merchant account with, plus cash on delivery where your operation needs it.
Your merchant account stays yours
Address capture, tracking and notifications, with permissions configured and each one justified to the user and the store.
Justified permissions
Measuring the key in-app events so you can see where users stop, with the required data-collection declarations.
Measurement with consent
Any system with an API or a scheduled file can be connected; we inspect the interface first and say what cannot be connected.
After inspecting the interface
Scope
Described scope with no published prices: cost follows the number of screens, platforms, integrations, and the testing and release scope, and is quoted after the scoping session.
Scope and screen map, UX and UI design with a design system, and a working prototype for sign-off — for testing the idea before investing in engineering.
Before investing in engineering
Everything above plus engineering, the backend and admin console, testing on real devices, store preparation and publishing, and post-launch support.
From idea to store
Everything above on both platforms, with two connected apps (customer and field), deeper integration with your systems, multiple builds and separate test environments.
Quoted after the scoping session
We publish no price before the scoping session: cost follows screens, platforms, integrations and the testing and release scope.
FAQ
Direct answers on ownership, the stores, responsibility and what we do not guarantee — without inflation.
With a scoping session rather than a quotation: we define the primary user, the problem the app solves, the smallest version that proves the idea (not every feature), and what the first release explicitly excludes. That protects the budget from creep and makes release one measurable. The session produces a written scope and an initial screen map — before any code and before any financial commitment.
We build both platforms from one codebase where the operation allows it, because it is faster and cheaper to maintain. But that is a trade-off, not a rule: apps relying on deep system features — advanced camera work, Bluetooth, always-on background work, heavy graphics — may need native code per platform, and we say so in the scoping session. The decision follows the requirements, not a technical preference.
The account is in the client’s name, not ours: the Apple Developer or Google Play account is opened under the client’s ownership with the fees on them, because the app is a company asset and should not hang off a vendor. We handle the technical preparation — signing and certificates, store listing, screenshots, age rating, data-collection declarations — then the upload and the review follow-up. If you already have an account, we work with it directly.
We guarantee no approval, because the review decision belongs to Apple and Google rather than to us, and we guarantee no timeline for it. What we do commit to method: preparing the submission against the stores’ requirements before a likely rejection (privacy policy, data declarations, permission justifications, in-app purchase where relevant, account and deletion requirements), and handling any rejection with a written reason and resubmitting. An active account and policy compliance are prerequisites for approval.
We give no binding duration before the scoping session, because it follows the number of screens and flows, the platforms, the integrations, whether an admin console is needed, and the store review time that is not ours to control. What we give after the session is a phased plan with outputs, and the first installable build usually arrives early in engineering so you can try it yourself before everything is finished.
The client owns both: the code is delivered into your repository and documented, and the Apple Developer or Google Play account is opened in your name with the fees on you. We neither hold the code hostage nor keep the app tied to our account, and another developer can continue from the repository and the documentation. That is written in the contract rather than promised.
Store account fees and third-party subscriptions (maps, messaging, payments), hosting and monthly running costs unless agreed as separate scope, running marketing campaigns and buying ads to acquire downloads, producing the content, imagery and video inside the app, and legal advice on data protection. We say so before the contract so none of it is a surprise after launch.
Four details are enough: what the app will do, who uses it (customer or employee), the systems you want connected, and whether you already have a store account.
Tell us the idea, the users and the systems you want connected, and we will come back with a scoping session, a written scope and an initial screen map.
Request a proposalWe are a systems and applications development company — not an agent of Apple or Google and not a certification body: intellectual property in the code and the store accounts belong to the client, account and subscription fees are the client’s, and the store’s decision to accept the app and how long that takes belong to the store. We guarantee no download count, ranking, retention rate or marketing outcome, and announce no binding launch date before the scoping session.