APPS
MOBILE APPS
- 10+ projects
- from 2 weeks
- iOS and Android
Apps for iOS and Android: sign-in, payments, push notifications, work without a connection. We hook them to your site and back office so orders and data stay in one place instead of two.
WHO IS IT FOR?
Three situations where an app pays for itself fastest
- .01
THEY COME BACK, AND NOTHING HOLDS THEM
They buy regularly and open the site several times a month, but every time from scratch: through search, through an ad, through a saved tab. The only way to remind them you exist is an email or a paid impression. An app changes the mechanics of the return itself: an icon on the home screen and a push notification cost less than any repeat click. This is not about looks — it is about what the second and third purchase cost you.
- .02
THE APP EXISTS, BUT IT LIVES APART
The site on one thing, the app on another, the data synced by exports or not synced at all. You change a price twice, set a promotion up twice, and orders land in two different systems. From there the arithmetic runs against you: every new feature gets built twice, and support is left to reconcile the differences between the two storefronts.
- .03
THE WORK DOES NOT HAPPEN AT A DESK
Couriers, fitters, surveyors, field staff — the people who work with a phone in their hand. They need photos from site, completion marks, scanning, location, and the ability to carry on once the signal drops. A browser runs into its limits here: without the camera, an offline mode and background sync, the process still ends up in a messenger and a spreadsheet.
WHAT'S INCLUDED
We do not build below this line
- - Custom design, never a template.01
- - iOS and Android.02
- - Sign-in and profile.03
- - Push notifications.04
- - Works on a poor connection.05
- - One database shared with the site.06
- - Admin panel by LUNO.07
- - Publishing to the stores.08
- THIS IS THE FLOOR, NOT A PACKAGE
Everything listed ships in every project — even the simplest and cheapest one. There are no stripped-down versions.
- ONE SET OF DATA, NOT TWO SYSTEMS
The app works against the same database and the same admin panel as the site. A product, a price and an order are entered once and look the same everywhere.
- PUBLISHING IS WORK TOO
The build, the listing materials and getting through App Store and Google Play review are on us. The developer accounts are registered in your name.
WHAT'S INSIDE
THE APP CONTINUES THE SYSTEM, IT DOES NOT LIVE APART
We build sites, stores and CRMs — so the app is built on the same database and the same admin panel as everything else. A product, a price, an order, a customer are entered once and look the same everywhere: on the site, in the app, in Telegram. That removes the work which usually eats a budget unnoticed: entering content twice, reconciling by hand, and chasing down the differences between storefronts. If the system already exists and is somebody else’s, we connect to it through its API.

THE FORMAT IS CHOSEN FOR THE JOB
A mobile app, a desktop program and Telegram solve different problems, and the difference in price between them is a multiple, not a margin. We are tied to none of the three, so on the first call we work out what is genuinely needed: where an app inside the messenger is enough, where the app stores are unavoidable, and where a mobile site would do the job outright. Selling you the expensive format where the cheap one would do is a bad deal for us too — projects like that do not take off, and we are the ones who end up explaining why.

IT KEEPS WORKING WHEN THE SIGNAL DROPS
A phone on the underground, a warehouse with no coverage, a site out of town, a laptop on the road. The app has to carry on alone, accumulate the changes and reconcile them with the server once the network returns — including the case where the data moved in both places meanwhile. This is not a feature bolted on at the end: it goes into the architecture from the start, or everything gets rewritten.

LAUNCH AND UPDATES ARE WORK TOO
Publishing to the App Store and Google Play, answering moderation, the signing certificate for Windows and macOS, automatic updates, a server side ready for day-one load — all on us. The accounts and the certificates are registered to you: the app has to be your property, not ours. After that it lives on our infrastructure if you want it to — monitoring, backups, and updates for the new operating system releases that arrive every year whether you asked for them or not.

CATEGORIES
Three levels of scope. Yours is the one you recognise yourself in
AN APP FOR YOUR BUSINESS
WHEN IS THIS YOUR CASE?
You already have a site or a system, and the app is the mobile way into it: catalogue, orders, profile, history, notifications. The whole base build: design made for you, iOS and Android, sign-in, push, working on a poor connection, one database shared with the site, admin panel, publishing to the stores. Nothing stripped out — just without the extras you do not need yet.
THE APP AS THE PRODUCT
WHEN IS THIS YOUR CASE?
The app is not an addition to the business but the business itself: people use it every day and the revenue depends on it. Subscriptions and in-app purchases, several roles with screens of their own, maps and location, camera and scanning, an offline mode with sync, a chat or a feed, behavioural analytics. Plus the backend under all of it: your own logic, your own integrations, figures in the admin panel showing who uses what and at which step they drop out.
PLATFORM
WHEN IS THIS YOUR CASE?
The app is part of a system with several kinds of user and its own logic for each: client, contractor, operator, partner. Data exchange with external and accounting systems, heavy load, demands on speed and availability, several countries and languages. An architecture built for growth, a role model, monitoring and redundancy, documentation and handover to your team. The logic is designed around your processes rather than bent to fit someone else’s limits.
FAQ
Answers to the most popular questions
From $5.000 for an app on top of an existing business to $15.000 and up for a platform with several kinds of user. The figure depends on the number of screens and scenarios, on whether it needs a backend of its own or works against your existing system, and on what the load will be. After the first call you get a plan rather than a guess: what makes up the total, and what can wait for a second stage.
An app on top of an existing business takes 2–6 weeks. An app as a product in its own right, 3–8 weeks. A platform, from 6 weeks. On top of the development sits store review: usually a few days to a week and a half for the first release. We name the deadline before we start and we hold to it.
It depends on what the app does. Cross-platform means one codebase for iOS and Android: cheaper, faster, updated in one place. Native is for apps that push the hardware: heavy graphics, intensive camera work, background processes, platform-specific capabilities. For most business cases cross-platform covers everything, and paying the native premium does not pay off. Which suits you we say on the first call, before any estimate.
With cross-platform development the second platform is not a second project: the code is shared and only the platform details and the publishing differ. It usually adds 15–25% to the price, not another 100%. With native development the second platform costs nearly as much as the first — which is the main reason native is chosen only when there is no way around it.
Not always. If people come by once every few months they will not install an app, and the mobile site does the job better. An app starts paying off where there is repeat use: regular orders, daily use, notifications, one-tap payment, working with no signal, the camera. If your purchases are one-offs, the honest thing is to say so up front rather than sell you an app that gets deleted after the first order.
We do: the build, the descriptions and screenshots, submission for review, and answering whatever moderation comes back with. The developer accounts are registered to you and to your company — that part matters, otherwise the app ends up being somebody else’s property. Apple’s annual fee and Google’s one-off fee are paid by you directly.
That is the normal first submission, Apple especially: almost everyone gets notes back. Fixing them is part of the work and is not billed separately. The main requirements are known in advance and we build for them — privacy policy, account deletion, the rules on in-app payment. If the product itself contradicts a store’s rules, we say so before we start rather than after the build.
You do. The sources and the rights are handed over with the project — this is not a builder, not a subscription and not a tie to us. The store accounts are yours and the app is published under your name. If you ever decide to change contractor, the project leaves with you: we write it so another developer can pick it up.
An app needs more upkeep than a site: iOS and Android ship a major release every year, and what built yesterday may stop building. We keep the app current, ship updates and extend it as you grow. The server side can stay on our infrastructure alongside the site — monitoring, backups, updates.