Ask what a dispensary app costs and you will get a build number. That number is the least important figure in the decision, because an app is not a thing you buy. It is a thing you keep. The build happens once. The keeping happens every month for as long as the app exists, and that is where the money goes.
Below is the full lifecycle, broken into what actually drives cost. No dollar figures appear here, because credible sourced numbers for custom cannabis app builds are not available and inventing a range would be worse than useless.
Phase one: the build
Discovery and design
Before anything is written, somebody has to decide what the app is. Screens, flows, what happens when an item is out of stock, what a first-time user sees. Cost here is driven by how much is undecided when you start. A retailer who arrives with a clear picture spends a fraction of what one exploring their options spends, because exploration is billed by the hour.
iOS and Android development
Two platforms, and the naive assumption is that the second one is cheap because the first is done. It is cheaper, not cheap. Different conventions, different behaviours, different testing.
The bigger driver is device variety. An app has to behave on a three-year-old handset with a small screen and on the current flagship. Most of the effort past the first working version goes into that range rather than into features.
Point-of-sale integration
The app has to show real inventory and send real orders, so it has to talk to your register. This is where custom builds tend to exceed their estimate, because the estimate assumed a clean, well-documented, stable connection and reality includes edge cases: an item priced differently in one location, a category structure that does not translate, a sync that fails at 2am and needs to recover on its own.
App store submission
Review is a process rather than a formality, and cannabis apps attract particular attention. Budget for rejection and resubmission, and for the possibility that a rejection requires a change to the product rather than a change to the listing.
Phase two: the part nobody budgets for
Operating system updates
Apple and Google ship major releases annually and neither asks your permission. Something breaks or is deprecated most years. This is not a feature request and it produces nothing a customer notices. It is rent, paid to keep the app functioning, and it recurs for the entire life of the app.
Menu sync maintenance
The integration built in phase one is not finished, it is started. Your point-of-sale vendor updates their system. You add a location. You restructure categories for a promotion. Each of those is a small piece of work against a contract, and small pieces of work against a contract are the most expensive way to buy engineering.
Every feature request
Here is the pattern that catches operators. Six months in, you want to add loyalty. Or push notifications. Or a second brand. In a custom build, each of those is a new scope, a new estimate, a new schedule, and a new app store submission. The app becomes a queue of requests with a waiting list, and the marketing calendar starts bending around the development calendar instead of the other way round.
That is the real cost of the custom route, and it does not appear on any invoice: the things you stop trying because each one is a project.
The platform alternative and how the cost shape changes
A platform app changes what you are paying for. Instead of commissioning an artefact and then maintaining it, you are paying for a maintained product that you configure. The operating system work, the device testing, the integration upkeep, all of it is amortised across everyone using it rather than billed to you alone.
The trade is control. You are not getting an app nobody else could have. You are getting one that works, is branded as yours, and is somebody else’s responsibility to keep running. For most retailers that is the right trade, because the differentiator was never the app architecture.
The speed difference is real and follows from the same logic. Buddy stores go live in about 24 hours, because nothing is being built from nothing.
The difference that changes the ongoing cost most
This one is specific and worth isolating. On Buddy, the native app updates itself when the retailer updates the platform. No app store resubmission.
Sit with the implication. In the custom model, changing something in your app means a build, a submission, a review, and a wait, and then a further wait while customers update. Every change carries that overhead, which is precisely why most operators stop making changes. In the platform model, you update the storefront and the app reflects it.
The saving is not really the submission fee. It is that changing your mind becomes cheap, and an app you can change is an app you will actually use.
Cannabis app development covers the approach in detail, and the mobile app page covers what ships in it. For where the app sits alongside everything else, see the retailer overview.