“Let's build an app” can describe very different needs: event registration, access to documents, working without a connection or a tool employees use every day. Each points to a different scope.
Before requesting prices, establish what people need to do on a phone and why the current service makes that difficult.
Describe the moment of use
Will someone use the service once a year or several times a day? Do they arrive through search, a message link or by regularly opening a familiar tool? Are they willing to install something and create an account?
Someone checking opening hours needs a quick answer. An employee collecting information in the field may need a very different experience. Putting both situations under “mobile” does not make them the same project.
Check features in the intended conditions
If photographs, location, notifications or unreliable connectivity matter, describe the expected behaviour. Ask for feasibility checks on the actual devices and environments you intend to support.
Do not assume that one named feature settles the technology choice. You need confirmation for your own scenario, including limitations and ongoing support costs. A demonstration in favourable conditions may leave the difficult part unanswered.
Compare the complete product
Include the administration area, data source, testing and support in both options. For an app, establish publication work and later release responsibilities. For a website, verify that the core tasks work well on a phone.
Ask for two scopes that reach the same user outcome. Compare cost, how people reach the service and post-launch expenses. A decision based on a specific need is easier to explain than an assumption that owning an app is the natural next stage of development.
Every number in this article, plus thousands of other contracts, is in the database.
Open the database