Mobile app development
Mobile app development for iOS and Android, and where the task allows, both platforms at once from a single codebase. We take the app all the way to the store and stay around after it is published.
A mobile app is worth building not because everyone has one, but when the phone gives you what the browser cannot: working offline, notifications, the camera, payment in one gesture, a place on the home screen. If the task needs none of that, it is fairer to say so straight away and build a web application faster and cheaper.
Cross-platform development covers most tasks: one codebase, both platforms, half the work on every change. We go native where it is justified. That decision is made during discovery, not out of team habit.
Apps inside Telegram are a story of their own. A Mini App installs in a couple of taps, lives in the messenger where the user already is, and needs no download from a store. For many products this is the first step instead of a full app.
Design, backend and artificial intelligence models sit inside one team, so the interface and the server logic never drift apart between contractors. If the product has not been tested on real people yet, it makes more sense to start with a prototype or an MVP. How this looks on a live project can be seen in the Battle of the Bees case study: a game for the phone and a Telegram Mini App.
What the service covers
Any combination of the items below can be taken on its own.
If the task is straightforward and going cross-platform does not cut into the functionality, both platforms are built at once from a single codebase. That is cheaper to develop and twice as cheap to maintain: a change is made once rather than twice.
A native app is written separately for each platform in that platform own language: Swift for iOS, Kotlin for Android. Within each platform the devices differ in hardware as well, and their specifications have to be accounted for. Hence the price: native development always means two builds and two testing cycles, so it is far from necessary for everyone. We go native where the cross-platform layer hits its ceiling: heavy graphics, high performance requirements, close work with device capabilities.
An app inside the messenger: authorisation, notifications and the whole product logic with no install from a store. Payments run through the built-in Telegram platform, including stars and cryptocurrency.
The server side, synchronisation, offline mode, data exchange with CRM and payment systems. This also covers embedding artificial intelligence models where the product needs them. Non-trivial tasks are the rule rather than the exception here, and we handle them out of accumulated experience rather than at your expense.
Developer accounts are registered in your name rather than published from ours: the app must belong to you. Then we put the accounts in order, prepare the builds, descriptions and screenshots, take the app through review in the App Store and Google Play and release it.
We watch crashes and reviews, update for new versions of the operating systems and add what the business needs.
How we work
We work out what the app is for and what it has to do that a website cannot. The output is scenarios, risks, the choice between native and cross-platform development and the technical documentation.
The key screens as a clickable prototype, so the app can be handled before development, plus an estimate by stage.
Layouts for both platforms, then the build. Every iteration can be installed on a phone and tried out.
We test on different models and system versions, not only in an emulator.
We take the app through store review, set up crash monitoring and stay on call for the first weeks.
Stack and tools
Cases for this service
Frequently asked questions
The price depends on how many scenarios the app has and whether it needs its own server side. After the discovery stage we give an estimate broken down by stage, so you can see what you are paying for.
In most cases cross-platform: cheaper to develop and twice as cheap to maintain. We go native where the cross-platform layer runs into performance limits or device capabilities. We explain the choice at the discovery stage, before the work starts.
Yes. It often makes more sense to build a Telegram Mini App or an MVP and check demand in weeks rather than going straight into a full app published in two stores.
Developer accounts in the App Store and Google Play are registered in your name, we put them in order and prepare everything publishing requires: builds, descriptions, screenshots, policies. Then we take the app through review and release it. The accounts stay yours, so changing contractor does not take the app away from you.
Everything is set by the contract, and we put it in writing at the specification stage, before the work starts. During the project the team works either on our infrastructure or on yours: the choice depends on the complexity of the project and on whether you already have infrastructure in place. Every approved stage is transferred to your servers and your repository, so the work accumulates on your side rather than ours. Once the project is closed, all code, materials and documentation are handed over to you together with the rights to them.
Yes, it is a separate agreement: updates for new system versions, crash analysis and further development of the product.
Related services
Shall we discuss your task?
Tell us what needs to be done and we will come back with an estimate, the team composition and a plan for the first two weeks.