Tolaron · Prague, Czech Republic
We build mobile apps for the products and APIs your business already runs, as well as new products built around a mobile app.
#digitalproduct · for founders and product teams
A first mobile product
For founders and product teams preparing an MVP, the first usable version of the product: start with the main task the user needs to complete in it. We show you a free preview of roughly what the app could look like. Then we design and build the app and the web app that goes with it; what is needed on the server side is agreed within the project scope.
Discuss a new product#mobileapp #webapp · for companies with an existing product
A mobile app for an existing product
An iOS and Android app connected to the product or system you already run, with web administration where needed. We start with your API, define user permissions and agree who can change the backend. If you want us to take over development of an existing app, tell us what technology it is built on and who owns the source code. Before we agree the work, we assess its condition, build process and dependencies.
Discuss an app for your productExamples of possible scope. The tasks and integrations depend on your product.
Give customers a clear view of their contracts and the documents they need.
Let users describe what they need sorted, or report a claim, and attach photos from their phone.
Show the current status and what the customer needs to do next.
Help your team review and approve requests away from their desks.
Founder’s experience before Tolaron
Five years at a UK FCA-authorised payment institution, from merchant onboarding to transactions and settlements. Zdeněk worked as a senior mobile developer and team lead.
Project detailsOwned product · in development
A company number becomes a reviewable case, with sources for the data and visible gaps. We are building Monivero for compliance teams; it is not yet available to customers.
Project detailsAlready have a product? Read what your API needs before mobile app development.
How we design fintech apps
Healthcare, energy, logistics and fintech are our four main sectors. These six parts of a fintech app show why particular design decisions work, from KYC and onboarding to payments and dashboards.
Strength 01
Fintech apps
Payments, cards, onboarding and KYC. Before Tolaron, the founder spent five years as a senior mobile developer and team lead at a UK FCA-authorised payment institution.
Strength 02
Data and dashboards
Overviews, charts and numbers people understand at a glance, on the phone and on the web.
ExampleThe screens are examples from other companies’ apps (the Mobbin library), not our work. They show the principles we design by.
01 · Onboarding and KYC
N26, account opening. Hover over the numbers.Tap the numbers.
1Why it works
Finished steps stay visible
N26 keeps completed steps in the list with a tick. People see how much they have already done.
In our design: We split a long onboarding into named steps and keep the finished ones in view.
Onboarding and KYC: more screens that work · hover over a screentap a screen
Data and dashboards · across sectors
1The tiles drive the chart
Clicking a number switches the chart below it. A number and its trend always stay together.
Amplitude, traffic overview. Hover over the numbers.Amplitude, traffic overview. Tap the numbers.
The examples are other companies’ apps from the Mobbin library (N26, Careem, Starling, Crypto.com, Monzo, Revolut, Wise, Cash App, Vipps, Lloyds, ubank, Copilot, Origin, Apple Wallet, Afterpay, Zip, Mercury, Shopify, Square, CVS Health, Warby Parker, Zocdoc, Wonder, Bolt Food, DoorDash, Octopus Energy, Amplitude, Rocket Money). They are not our work; they show the principles we design by. Names and trademarks belong to their owners. Tolaron’s samples use made-up data.
First we clarify the project’s scope and check that working together makes sense for both sides. We show you a free concept preview of roughly what the app could look like, not a working MVP. Then together we define the users and their main tasks, the first usable release, the screens and the acceptance criteria.
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. For data access, authentication and third-party integrations, it must be clear who is responsible for what.
We release the app on the App Store and Google Play. Testing, store accounts and handover are agreed before launch. Upkeep, meaning fixes and security updates, and later improvements are set up to fit the project.
Zdeněk Dolák leads the project and is your contact throughout our work together. Where needed, we bring in specialists from other fields; which ones, and how much, is agreed for your project.
Maintenance, support and responsibility for incidents are agreed for each project. To track the app’s errors and performance, we can use Sentry, for example. Together we decide what to monitor, who receives alerts and how issues are handled.
Technology
React Native lets an iOS and Android app share application code. It suits apps whose users do the same tasks on both platforms. Platform-specific behaviour still needs implementation and testing on each platform.
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.
iOS
Android
TypeScript
React Native
Expo / EAS
Next.js
Supabase
PostgreSQL
Vercel
GitHub Actions
Playwright
SentryMore questions? Write to hello@tolaron.com.
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.
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 what the app needs; we never replace or rebuild your product.
Cost depends on scope: the number and complexity of user journeys, design readiness, API quality, integrations, offline behaviour, testing and release requirements. That is why we have no standard price list. We estimate against the agreed scope and bill the work actually done, up to a budget cap agreed in advance. Any increase to the cap needs your approval first.
It depends on scope: the user journeys, design and API readiness, integrations, offline behaviour, testing and the App Store and Google Play release. So we do not promise a standard launch date. The MVP is limited to the user’s main task. If you must hit a fixed date, put it in the brief along with the reason.
Yes, fintech is one of the industries we focus on. Tolaron founder Zdeněk Dolák gained experience in financial services, payments, compliance and customer onboarding in the UK. We can take responsibility for apps whose main purpose is payment. Describe the intended transactions, backend and SDK dependencies. Security requirements, regulatory review and the responsibilities of each party are agreed for the project.
We work in Czech and English. Founder Zdeněk Dolák leads the project and is your contact; other developers join as the project needs and capacity allow. 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.
When a mobile app is worth building and when a faster mobile website serves people better: how often they return, what the phone adds, what an app costs to run.
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.
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.
A short summary is enough to start. We will discuss whether we can help, what the app needs to connect to, and what we need to estimate scope, cost and timing.
