Vesna
Service Marketplace
WebiOSAndroid
iOS
AndroidAn on-demand HVAC marketplace connecting homeowners with verified local professionals.
Learn More All services
iOS and Android apps, built once and live in both stores
One cross-platform codebase, native features where they earn their place, and a store submission process we have run on the App Store and Google Play. We design the app, build it, launch it, and stay for the releases that follow.
You are probably here because
- You need one product on iOS and Android without paying for it twice
- You have a web product, and mobile is now where your users are
- Your app was built by someone else and you need it taken over and kept alive
- You need to be in the stores and have never been through review
What decides whether it works
Mobile is slower to correct than the web. A bad release is not a redeploy, it is a review queue. A careless permission prompt costs installs. A slow screen on a three-year-old Android phone is the screen most of your users see.
The expensive decisions come first: native or cross-platform, what works offline, what to ask for at first launch, and what the app does before sign-in. We make them in the first week, in writing, while they are still cheap.
We have done this
All case studies
Connexa
AI Networking App
iOSAndroid
A relationship intelligence app that preserves the context behind every professional connection.
Learn More
Guarders BabyPass
Pediatric HealthTech
iOSAndroid
Two connected apps that let parents track a baby's health at home and send a urine test, read by the phone camera, straight to their pediatrician.
Learn MoreWhat the work covers
Included
- Product and UX design for the platform, not a shrunken web layout
- Cross-platform build for iOS and Android from one codebase
- Native capabilities where they earn it - camera, location, push, biometrics, offline
- The backend, API and integrations the app depends on
- Testing across real device sizes, not one simulator
- Store assets, listings, and submission to the App Store and Google Play
- Release configuration, crash reporting and analytics
- The first releases after launch, when the real-world bugs show up
Not included
- Separate native codebases in Swift and Kotlin unless the product genuinely needs them - and we will tell you when it does
- Games and real-time 3D
- Publishing under our developer account - the listing belongs on yours
How the work runs
The same four steps we use on everything, in this service’s terms.
1
Observe
Learn the journey before the screens
What the person is doing when they open the app, how often, and on what device. An app used once a month on the go is a different product from one used daily at a desk, and it should not look the same.
2
Plan
Settle the platform questions early
Native or cross-platform, what works offline, which permissions are worth asking for and when, what is reachable before sign-in. Cheap decisions now, expensive ones after launch.
3
Uncover
Build it on real devices
Tested across the phones and OS versions your users actually carry, not the newest phone in the room.
4
Ship
Through review and into the stores
Listings, assets, review notes and submission on both stores, then the releases that follow - because the bugs that matter show up once real users have the app.
What it costs
Typical bands rather than a quote. The number moves with scope, and we would rather you knew the range before the call than after it.
6-10 weeks
MVP Sprint
$25k - $80k
A focused app, in both stores, that real users can install.
Ongoing
Product Partner
Custom
Your long-term product team after launch - roadmap, releases and continuous improvement.
Questions we get asked
Native or cross-platform - which should we choose?
Cross-platform by default. One codebase serving both stores is usually the right trade for a product still finding its shape: half the code to maintain, and the two platforms cannot drift apart. It is the wrong answer for heavy real-time graphics, sustained background processing, or deep use of a platform feature with no cross-platform equivalent, and we say so when that applies. The decision is made in the first week with the reasons written down, because it is cheap then and expensive after launch.
Whose developer account is the app published under?
Yours, always. The listing, the reviews, the ratings history and the users belong to your company, not to us. That matters more than it sounds: moving an app between developer accounts later means a new listing, losing your reviews, and existing users reinstalling. We set up the accounts with you at the start, or work inside the ones you already have. The same goes for the analytics, crash reporting and push notification services the app depends on.
What happens if the app store rejects the submission?
We handle the response and the resubmission as part of the work, not as an extra. Rejections are normal and usually specific: a permission that needs a clearer explanation, a login path the reviewer could not get through, a listing that does not match what the app does. Every app we have shipped passed App Store and Google Play review and is live. We write the review notes together with the submission, which is the cheapest way to avoid a second round.
Can you take over an app someone else built?
Yes. First we read the code and tell you what we found, before agreeing a plan. That report is useful on its own: it separates what is fine, what needs attention, and where rewriting one contained piece is cheaper than maintaining it. If a takeover is not worth it, we will say so. Taking over also means taking over the accounts, the signing certificates and the release process, which is often where the real risk sits.
Do you build the backend as well, or only the app?
Both. The app is the visible end of a system, and splitting the two between suppliers is where most schedule slips come from: each side waits on the other and nobody owns the contract between them. We build the API, data model, integrations and background jobs alongside the app, so a change that touches both is one piece of work. If you already have a backend team, we work with them and agree the API contract early instead of discovering it in testing.