App development for iPhone and Android
App development that starts with what your user needs to be able to do, not with a list of screens. We build iPhone and Android apps for a fixed price agreed in writing, publish them on your company's own App Store and Google Play accounts, and hand the source code to you. DT Nova has published 22 apps on the App Store, so the store rules on this page come from our own submissions.
- You see the result before it goes live
- Fixed price for the agreed scope, in writing before work starts
- Source code, domain and accounts in your company's name
Who this is for
Companies in Finland that work in English, founders with an idea that needs to reach a phone, and companies elsewhere in the EU that are comfortable working remotely with a small supplier in Helsinki. We meet clients on site in the Helsinki region and work remotely with everyone else.
It fits best when the first version can be described in a sentence or two.
Proof: our own apps
DT Nova has 22 apps published on the App Store, counted from the store on 25 October 2026. See them on our apps page or on DT Nova's App Store page. Every one went through Apple's review, rejections included, which is how we know in advance what stops a launch.
Web app or store app: decide this first
This is the most important decision in the whole project, and it is made before anyone writes code. Go through these questions in order:
- Does it need the camera, location or push notifications? If none of them, a web app that opens from a link is almost certainly enough.
- Will the same person come back every week? Nobody installs an app for something they do once.
- Must it work without a network? On a building site or in a basement, only a store app works.
- Are there fewer than a hundred users? For an internal tool, a web app nearly always wins: no installs, no review, no update queue.
The most expensive mistake is ordering a store app for a job that is really a web app: it costs more, launches weeks later, and every small fix waits in the review queue.
What you get
- One shared codebase for iPhone and Android, unless your case truly needs two native apps.
- Testing on real devices, including an older phone and a poor connection, because that is where problems show up.
- Internal testing through TestFlight, so people in your own company try the app on their phones before it reaches the store.
- The full store submission: icon, screenshots for every declared device size, store description, privacy details, age rating, review notes and a working demo login for the reviewer.
- Rejection fixes and resubmission included in the agreed price.
- Source code and both store accounts in your company name.
What makes an app more expensive
Not the number of screens. The price grows with a few decisions, and each one can be made differently:
- Logins and user accounts. The login is small; around it come password reset, email verification, account deletion, which the stores now require, and a privacy policy. If the app works without accounts, build it without.
- Payments or subscriptions. The stores have their own purchase systems and strict rules for how a subscription is shown and priced.
- A connection to your existing system. The cost depends on whether the other end has a ready API. If it does, the work takes days.
- A second language, or offline use. Both add real work.
The first version: what to leave out
The price of an app project is decided in the meeting where the first version is defined. A good first version does one thing completely, not ten things halfway. A rule that works: write the wish list, rank it, and draw a line under item three. Everything below the line is phase two, decided again once real usage shows what people do.
How we work
- Free discovery call. Half an hour is usually enough, and sometimes a web app turns out to serve your users better.
- Scope and fixed price in writing. Before work starts, including what is not included. Anything uncertain is written down as uncertain, so it cannot surprise you on the final invoice.
- Build and test on real devices. You follow progress through TestFlight and the Android test track.
- Store submission. Assets, privacy forms, age ratings and review. We promise a submission date, not a release date, because review time is the one step nobody controls.
- Handover. The store accounts are already yours and the source code is delivered, so the next person can continue where we stopped.
What you provide, and what is not included
Some store requirements are your decisions, and they are the usual reason a finished app waits. We ask for them at the start: the privacy policy (we help with the content), terms of use if you sell a subscription, the age rating answers, and a support address. Not included in our price: Apple's annual membership fee and Google Play's one-off registration fee, which you pay directly because the accounts are yours; store commission on in-app sales; and game development, which we do not do.
When not to build an app
- Customers deal with you once a year.
- The app is meant as marketing; the store brings no users by itself.
- The same thing works in a browser.
- There is no budget for upkeep. Apple ships a new iOS every fall, Google requires apps to target a recent Android version, and an app nobody updates stops working or gets removed within a few years.
Ownership and maintenance
The app is published on your company's own accounts and the code is yours. Maintenance is a choice, not a requirement. A stable app with no backend can go a year without changes; you then pay only for the yearly OS update. A monthly plan makes sense when the app is critical to the business, and it can be cancelled with one month's notice. Backends run on Cloudflare, so a small app has a small running cost. Plans are on the pricing page.
The founder, Mustafa Tarabya, takes your call and answers for the work. The phone is answered on weekdays from 9 to 20 Finnish time, with a callback the same working day. Related: software development, website development and AI consulting. Book a free discovery call, or read this page in Finnish: sovelluskehitys.
Questions we get
Does my company actually need an app?
Not always. If a customer uses your service once, a website is enough. An app makes sense when the same person comes back every week, or when you need the camera, location, push notifications or offline use. If none of those apply, a web app does the job for far less.
Who owns the app and the store accounts?
You own both. The Apple and Google Play accounts are opened in your company name and the source code is handed over. We never publish a client app under our own account, because then you could not reach your own app, or change suppliers, without our help.
What happens if Apple rejects the app?
It is normal, not a disaster. A rejection arrives in writing and names the rule that was broken. We fix it and resubmit, and the fix round is not billed separately because publishing is part of the agreed price. The most common causes are checked before the first submission.
Will the same app work on iPhone and Android?
Yes, built on one shared codebase. That costs less than two separate apps, every later change is made once instead of twice, and in an ordinary business app the user cannot tell the difference. Two native apps only pay off for heavy graphics or deep device features.
How long until the app is in the store?
A simple app typically reaches the store in a few weeks; one with logins and payments takes months. Store review usually takes hours to a couple of days and cannot be controlled, so we commit to the date the app is submitted for review, not the release date.
Do you make games?
No. Games are a different craft that needs different skills. We say so on the first call and help you look for someone who builds them. The same goes for projects too large for a founder-led team: we suggest splitting them into phases or point you elsewhere.