Break the cost into the parts nobody quotes. Design and build. Two platforms, or one and the decision to ignore half your audience. Backend infrastructure if the app does anything beyond displaying content. Store fees and review processes. Then maintenance, which realistically runs at a meaningful percentage of the original build every year simply to keep it working. A business budgeting only for the build has budgeted for roughly half.
Before spending any of it, establish that people will return. Apps are justified by repeat use, because installation is a significant barrier that somebody crosses only if they expect to come back. A business whose customers transact a few times a year is asking people to install something for an interaction they could complete in a browser, and the installation rate reflects that.
The alternative worth costing first is a progressive web application, which behaves like an app, can be added to a home screen, works offline to a degree, and costs a fraction because it is your website with additional capability. For most first year businesses this delivers the genuine benefits without the store approval process, the two codebases, or the maintenance.
If you still conclude you need a native app, build the smallest version that does one thing well and put it in front of real users before extending it. The most expensive mobile projects are the ones that specified everything upfront and discovered after launch which single feature people actually wanted.
Ask any developer quoting you what happens after launch, and treat a vague answer as the most important information in the conversation. Who fixes it when an operating system update breaks something. What the response time is when the app stops working. Whether you own the source code and could hand it to somebody else. That last question determines whether you have bought an asset or entered a permanent relationship, and it is considerably cheaper to establish before signing than to discover eighteen months later. Get the quote broken into build, backend, store submission, and first year maintenance as separate figures, because a single number conceals which part will recur and which will not.