The question almost always arrives in the same shape: "how much does an app cost?" It is like asking how much a building costs. The honest answer starts with three other questions, and they drive the budget more than anything else.
Question 1: native or cross-platform?
Native means two separate apps: one written for iPhone, one for Android. Each looks and behaves exactly like the rest of the phone, gets immediate access to new system features and runs fastest. It also costs close to double.
Cross-platform means one codebase producing both apps. You save a serious share of the budget and the schedule, and for most business apps the difference is not noticeable.
Where cross-platform starts to hurt: heavy graphics, real-time video or audio processing, fine-grained camera work, deep system integrations. If your app is a catalogue, an account area, orders, delivery, reports or customer communication, cross-platform is the rational choice.
The practical question is not "which is better" but: do you need both platforms from day one? In Moldova, for many B2B products the answer is no. You launch one, see whether the product sticks, then build the second.
Question 2: what does the first version actually do?
The most expensive thing in a mobile project is not the code. It is the feature list nobody had the nerve to cut.
A healthy first version does one important thing well: the customer orders, the employee reports, the owner sees the numbers. Sign-in, notifications, a main screen and that one flow. The rest gets added once you see how people use it.
Warning sign in your own brief: if the feature list does not fit on one page, you do not have a project, you have a two-year work programme.
Question 3: does the app stand alone or connect to what you already run?
This is where the money hides. An app that only displays content is one thing. An app that has to read from 1C, from the cash register, from a CRM or from a delivery system is a different project: somebody has to build the server side, the integrations, and decide what happens when a source goes down.
The concrete question to ask a supplier: "Who writes the server side, and what happens to the app if an integration stops answering?" A vague answer here predicts precisely where the project will slip.
How long it realistically takes
For a first business version on a sensible budget, the order of magnitude is months, not weeks. The time goes into understanding the flow, design, development, testing on real devices, and publishing.
At the end comes a stage many people forget: Apple's review. The App Store has a review process, and first-attempt rejections are normal, especially for apps that require an account, collect data or handle payments. It is not a disaster, but it belongs in the plan rather than being discovered the day before launch.
What you need to have as the client
A short list, because each missing item pushes the launch back:
- An Apple developer account in your company's name, not your supplier's. The account is your asset; if it sits with someone else, so does your app. A company account also needs an international company identifier.
- A public privacy policy — Apple requires it, and in Moldova so does Law 195/2024. We wrote separately about what it must contain.
- Real content: copy, photos, categories. An app full of invented data will not pass review and cannot be tested seriously either.
- One person on your side who decides. Not a committee, a person. Mobile projects most often die in approvals.
- An answer to "what counts as success": how many orders, how many active users, which process gets shorter. Without it, nobody can say three months later whether it was worth doing.
What we do
We build iOS and Android apps together with the server side, because in practice they are one project: the app is only the window through which the system is visible. We did the same in our own products — KX estate has its app sitting on the same property-operations platform, and with Klaro the owner sees a retail chain on their phone, fed from the cash register and 1C.
If you have an idea and want to know which budget range it falls into, write to us. The first conversation is about the three questions above, not about technologies.
*Cost and timelines depend on the project. This text explains what they are made of; it is not a quote.*