What your API needs before we build a mobile app
Sign-in, data access, permissions and a backend owner: what an existing product needs before a mobile app is built on it, and what if the API falls short.
Tolaron · Prague, Czech Republic
Mobile app development for iOS and Android.
Tolaron is a Prague venture studio focused on mobile apps: we build new digital products around the app, and apps for the systems your business already runs. We work with Czech and international clients in Czech and English, with direct involvement from founder Zdeněk Dolák.
What do you need the app to change?
A first mobile product
For founders and product teams defining an MVP: start with the user journey that needs to work in the first release. We design and build the app and the web app around it; what it needs on the server side is agreed as part of the scope.
A better interface for an existing system
Give customers or employees a mobile interface to your existing data and workflows. Define who can see or change each part of the system, and which tasks belong on a phone or a web dashboard.
An existing app that needs attention
Describe the problem, the current technology and who owns the source code. Taking over an app depends on its condition, build process and dependencies; those need to be assessed before agreeing the work.
React Native, Expo and TypeScript
React Native lets an iOS and Android app share application code. That is useful when both platforms serve the same users and workflows. Platform-specific behaviour still needs implementation and testing on each platform.
Expo supports the React Native workflow and can work with native modules. A required payment SDK, device feature or offline workflow should be checked early: shared code does not remove those integration decisions.
The technology should fit the product. If a project depends on specialist hardware, demanding graphics or an existing native codebase, those constraints belong in the initial technical discussion.
Technical documentation: React Native · Expo Modules
Agree the app and its dependencies together
- 1
Product and interface
Identify users, core tasks and the first useful release. Agree the design, screens and acceptance criteria alongside the mobile implementation.
- 2
Backend and integrations
Backend development is not a standard service. For an existing product, we build on your API and need someone on your side who can explain and change the backend. For a new product, or where the API falls short, what the app needs on the server side is agreed within the project scope, and an existing product is never replaced or rebuilt. Data access, authentication and third-party integrations need explicit responsibilities.
- 3
Release and ongoing improvement
Agree testing, store accounts, release responsibilities and handover before launch. Define later improvements and maintenance separately, including what support is needed.
See the work behind the offering
The portfolio distinguishes Tolaron client projects, owned products and the founder’s earlier work. Each project page explains its role and current status, so an in-development product is not presented as a completed client delivery.
Client project · In delivery
Management information system for hospital managers
Dashboards and operational functionality on the client's backend. Design, UX/UI, build and long-term maintenance.
Case study →Before Tolaron · 2021 to 2026
Merchant payments and onboarding
Product engineer, later senior mobile developer and team lead, UK payment institution
One FCA-authorised UK payment institution, two roles. First, merchant onboarding in the app: identity verification, commercial terms and e-signed agreements, without paperwork or a sales call. Then the card-payments app in React Native for iOS and Android, used by more than three thousand merchants: from architecture to store release, leading two to three engineers.
Before you request a proposal
- Can one application support both iOS and Android?
- Yes. React Native supports shared application code across iOS and Android, with platform-specific code where needed. Both versions still need testing and their own release process.
- Can the app connect to our current backend?
- Yes, and for an existing product that is where we start. Tell us what your API supports, how users sign in and who can make backend changes. Where the API falls short, we agree within the project scope what the app needs; your product stays as it is.
- How much does it cost to build a mobile app?
- We do not publish a standard price, because cost depends on scope: the number and complexity of user journeys, design readiness, API quality, integrations, offline behaviour, testing and release requirements. We estimate against an agreed scope and bill the work actually done under a budget cap agreed up front. Any increase to the cap needs your approval first.
- How long does it take to build a mobile app?
- It depends on the same scope: the user journeys, design and API readiness, integrations, offline behaviour, testing and the App Store and Google Play release. We do not promise a standard launch date. A focused MVP limits the first release to the essential task, and a date that is fixed for a real reason belongs in the brief from the start.
- Can you work with a fintech or payments business?
- Mobile interfaces for fintech and B2B companies are part of our focus. Describe the intended transactions, backend and SDK dependencies. Security requirements, regulatory review and the responsibilities of each party must be agreed for the project.
- How does working with a Prague partner remotely work?
- We work in Czech and English. Before starting, agree the people responsible for product decisions and backend changes, how feedback will be shared, and meeting times that work across your locations.
Read more before you plan the app
All posts
React Native for business apps: what one codebase covers
When one React Native and Expo codebase fits an iOS and Android business app, and what it does not remove: native SDKs, offline, testing and releases.
What to send before asking for a mobile app proposal
The four points a useful mobile app brief covers, what drives cost and delivery time, and why an estimate follows an agreed scope, not a standard price.
Send enough context for a useful conversation
- Who will use the app and the main task it should solve.
- Whether this is a first release or an existing app, with public links if available.
- The backend or API it must connect to, if there is one, and who is responsible for it.
- The platforms, priorities, target timing and any budget constraints.
A short summary is enough to start. We can then discuss fit, clarify dependencies and agree what is needed for a scope and estimate. Please keep credentials and customer data out of the enquiry.