iTicket
A ticketing platform for Moldova and Romania. Two apps: the buyer app — event search, tickets, vouchers, filters by city; and a scanning app for venue staff, working together with the turnstiles at the entrance.
React Native · Expo
An app
for iOS and AndroidMobile app development
We work remotely, for clients in any country. One codebase — iOS and Android grow out of it together rather than as a second project with its own invoice. Whether to ship to both stores at once or start with one is your call.
02 — how it works
The second platform is not a second project
React Native and Expo: interface, logic and screens are written once and run in both stores.
The difference shows not at release but in everything after it. One fix, not two. A bug is fixed in one place. A new feature does not reach one store a month before the other — and with it, two versions of your product do not drift apart, each needing to be watched separately.
Mobile development here is led by Emilian and Dumitru — React Native and Expo, apps already standing in both stores. When an app needs its own backend and servers, that is us as well — Dumitru and Andrei, not a second contractor with their own invoice and their own schedule.
how long building an app takes
Three to five months to reach both stores. If the app also needs a backend written from scratch, longer — and that is estimated as a separate line.
That schedule includes the thing people usually forget: store review. Apple and Google look at the build themselves, by their own rules, and that takes time which depends neither on you nor on us. We allow for it in advance rather than announce it in the final week.
03 — scope of work
What the work on an app includes
Both platforms. Every app of ours ships to both the App Store and Google Play — there is no such thing as “we will price Android separately”.
A backend, if it needs one. Accounts, data, APIs, integrations — that is a neighbouring specialisation inside the same team, not another contractor.
Support after release, if you want it. An app does not end at the store upload: the platforms and the stores change their requirements by themselves, and updates are needed even without new features.
The code is yours. Repository and access from the very start, not on completion.
Published to your accounts. The app ships under your developer account, not ours: the store page, the reviews and the statistics stay with you.
The things a phone has and a website does not. Map and location, camera, push notifications, working offline — if your app needs those, that is what makes it an app in the first place.
04 — evidence
Mobile apps we have built
BoleoExpress
Not a website but one product across four surfaces: web, online store, mobile app and an app for Roku televisions. The only project the three of us built end to end together.
React Native · Expo
A significant part of our work is covered by agency NDAs. Examples on request.
05 — process
How a mobile app is built
- 01You come with a technical spec.What kind of app, who needs it, what has to be in it. That part is yours: without it there is nothing to count.
- 02We analyse it.We turn it into a document that leaves no questions and no double readings: what exactly we are building, and what we are not. For an app this is also where the things a phone can do and a browser cannot go: map, camera, notifications, working offline.
- 03An estimate in hours — from the finished spec.The numbers are counted from a document you have read and approved. Counting hours from a vague description is guesswork you pay for. Both platforms are counted as one figure: the second is never a separate line in the quote.
- 04You see something working early.Not a status report but an app you can install on your phone and poke at. Changing your mind at this stage is cheap.
- 05You see where the time goes.Tracked in Toggl, the report open to you: once a month — hours by task, what is done, what comes next. You are billed for hours worked, not in advance.
- 06Release to both stores.Both platforms together. After that we either keep maintaining it or hand the work over cleanly to your team.
06 — plainly
What we do not do in mobile development
We do not quote a price before the spec. A figure based on a description of an idea is not an estimate — it is a number that will change anyway. We would rather change it before you have counted on it.
Buffer time goes into the estimate but not into the invoice: you pay for hours worked. If the work takes less, you pay less. More on how hours are counted — on the home page.
07 — common questions
Common questions about mobile app development
How long does building an app take?
Three to five months to reach both stores, store review included. The exact schedule comes with the estimate in hours, from the finished spec.
Native development or React Native — which to choose?
We write in React Native, and for the vast majority of apps that is the right choice: one codebase instead of two, one fix instead of two, half the hours on everything that happens after release. Native development is justified where an app runs into the limits of the platform itself — heavy graphics, video processing, unusual work with hardware. If that is your case we say so straight away rather than take it on and get stuck halfway.
Do you build the backend too?
Yes, when it is needed. Accounts, data, APIs and integrations are a specialisation already inside the team, so there are no two contractors to introduce to each other.
Whose accounts is the app published under?
Yours — in the App Store and Google Play, not ours. They stay yours even if we stop working on the app.
What if the app is rejected by a store?
We fix it and resubmit; the schedule allows for that in advance. A rejection at review is usually a formality, such as a missing explanation of why the app needs camera access. A rejection on substance, when the very idea of the app conflicts with the store rules, is visible before the work starts, and we say so at the spec stage.
What happens to the app after release?
Either it stays with us on monthly support, or we hand the work over cleanly to your team. Apps have to be updated even without new features: the platforms and the stores change their requirements by themselves.
Who owns the code?
You do. We work month to month and invoice for work already done, so repository access can be handed over at the start rather than at the end — there is no reason for us to hold the code until the final payment.
Will you sign an NDA?
Yes. A significant part of our current work is already under one.
What time zone and languages do you work in?
We work remotely with clients anywhere, time zone EET. We speak and write Romanian, Russian, English and Bulgarian.
08 — next
Tell us what you want to build
Come with a technical spec. We will rework it until no questions remain, and count the hours from that.
one address, all three of us
This is the way in. Mobile apps are answered by two of us: Emilian and Dumitru.
To write to one of us directly — contacts on the home page.
If the task is a different one: a web app or internal system, APIs, integrations and payments, an online store, a website or landing page, taking over an existing project, making an existing site mobile-friendly.
Want to see who we are first — the home page: the three of us, what each one does, how we count hours and what we have already built.