Mobile apps

We design mobile products around a specific journey: selecting an offer, managing tasks or checking a digital object on a phone. We first choose a responsive website, PWA or iOS/Android app and assess device, network and publishing requirements. Explore MYRU, NVideoHub, RRID and GeoOverlay mobile scenarios in their cases and presentations. Each product’s format and stage are clarified separately.

Glass mobile devices with dimensional interface elements
Starting budget
On request
Delivery timeline
According to an agreed plan
Discuss a project

Who it is for and the tasks we solve

For companies with returning customers, teams launching a mobile product and employees working away from the office. Format depends on usage frequency, required device capabilities, data and permitted installation method.

Mobile customer service

We connect offers, profiles and user actions. MYRU materials illustrate combined commerce and social scenarios for planning a mobile structure.

Remote management

We design object selection and actions on a phone. The NVideoHub case shows screens, collections and display scheduling; specific mobile-client capabilities need testing against the brief.

Digital-object verification

We define a short path from entering or obtaining data to a verification result. RRID demonstrates a separate web token-verification scenario that should not be presented as a native app.

An app with networking logic

We separately develop connection, synchronization and error handling. GeoOverlay provides material for discussing distributed architecture; an alpha description does not establish mobile-release readiness.

What we do and what you receive

  • A justified first-version format: responsive website, PWA or agreed mobile platforms
  • Prototype, interface and network, loading and error states within the agreed scope
  • App implementation and server-data connections according to the brief
  • List of supported devices and tested user scenarios
  • Builds or a web-deployment package, submission materials and handover instructions for the chosen format

How we work

  1. 01

    Choosing the format

    We match the task to device features, network conditions and installation method. We define platforms and first-version criteria.

  2. 02

    Prototype and data

    We connect screens into the main journey and check API and user permissions. Where needed, we define offline states and synchronization rules.

  3. 03

    Implementation

    We build the agreed client and server connections, accounting for device permissions, request errors and resuming interrupted actions.

  4. 04

    Testing and handover

    We test scenarios on agreed devices, prepare the chosen installation or publishing method and provide update instructions.

Pricing and timeline

Starting project price

Budget
On request
Delivery timeline
According to an agreed plan

Included in the starting scope

We define first-version scope after examining the task: target platforms, main screens, roles, data handling and required integrations. The estimate covers agreed design, development, testing and publication-preparation stages.

Estimated separately

App-store fees and accounts, external-service licenses, extensive content preparation, promotion and ongoing support. Additional platforms and features are added to the estimate separately.

The estimate includes project management, specialist work, testing and handover within the agreed scope.

The starting price applies to the scope described. The final price depends on your task: after our discussion, we agree on the scope, estimate and schedule. The timeline depends on materials, access and stage approvals.

Price and timing follow an agreed plan after selecting format, platforms and scenarios. API readiness, device permissions, offline mode, synchronization and the device matrix affect scope. Store fees and accounts, licenses, promotion and maintenance are separate.

What to prepare for an estimate

  • Main task, audience and mobile-product usage frequency
  • Required device features, offline behavior and preferred installation method
  • Existing server API, roles and anonymized data examples
  • Target devices and platforms, publishing-account owner and essential first-version features

Related projects

All related projects from our portfolio.

P2P infrastructure

GeoOverlay

Infrastructure for applications whose nodes exchange data directly. GeoOverlay’s public version is presented as an alpha.

Task and solutionView project

Commerce and social platform

MYRU

A commerce and social platform combining products and services, a feed, profiles, chats, live streams and clubs.

Task and solutionView project

Digital token verification

RRID

A digital-token authenticity project: local signature verification and a separate layer of usage rules.

Task and solutionView project

Digital signage

NVHUB

The NVideoHub product website — television for business with AI video, ready collections and your own materials.

Task and solutionView project
Full portfolio

Before the project begins

Questions before we start

Do we need a native app, or is a mobile website enough?

That depends on device features, installation and usage. A responsive site runs in a browser; a PWA uses available web capabilities; an iOS or Android app has separate build and publishing requirements. We choose the format before estimating rather than treating these options as interchangeable.

How much do development and launch cost?

Pricing is on request and timing follows an agreed plan. Before estimating, we define first-version platforms, screens, roles, data and integrations. Store accounts and fees, external-service licenses, promotion and support are not automatically included.

Which projects can we explore as mobile examples?

The MYRU, NVideoHub, RRID and GeoOverlay cases contain descriptions and presentations of products with mobile scenarios. RRID separately shows web-based token verification; GeoOverlay is an alpha project. These materials do not establish published native builds in the App Store or Google Play.

Can one foundation serve both iOS and Android?

If the required features and constraints permit it. We compare approaches by device access, interface, existing libraries and maintenance. A shared foundation does not eliminate testing on every agreed platform.

Will it work offline?

Only within a predefined scope. Viewing saved data, creating an action offline and synchronizing later are different tasks. They need device-storage, retry, conflict and access rules.

How do you check app readiness?

Against an agreed list of devices and actions: startup, login, the main scenario, permissions, errors and recovery after interruption. Offline behavior and device permissions are tested when included in the brief. A design or presentation does not replace testing a build.

Who handles the server and publication?

We check the API before development; necessary server changes are included separately. We agree account ownership, platforms and submission materials in advance. A prepared build guarantees neither platform approval nor a particular review time.

Let’s discuss your project

Tell us about your product and the outcome you need. We will define the scope, propose an approach and agree on timing and cost.