Reading an agency quote for a store app
By Abdalla Kamesh · Published October 2, 2026 · 5 min read
An agency proposal for a mobile app is a document designed to be persuasive. That is fine — so is a pricing page. What matters is knowing which line items should be in it, which are usually missing, and what the missing ones cost you later.
Written by a company selling the alternative, so treat the framing accordingly and check the questions rather than the conclusion.
The line items that should be in the proposal
Run down the quote and look for each of these. Anything absent is either out of scope or unpriced, and both are worth asking about:
- Discovery and information architecture
- UI design for every screen — and ask for the screen count. A shopping app is thirty-plus screens including empty and error states.
- The WooCommerce integration: authentication, catalog sync, offline behavior, error handling
- Both platforms, explicitly, with the technology named
- Payments, with the architecture stated
- Push notification infrastructure, including a way for you to send a campaign without a developer
- QA on a device matrix, not one phone
- Store submission, both stores, including privacy questionnaires and screenshots
- Analytics
- A warranty or bug-fix period, with a defined length
- Ongoing maintenance, as a recurring number
The last one is the most commonly missing and the most expensive to discover later.
Question 1: which changes can I make myself?
Ask exactly this: “After launch, which visual and merchandising changes can I make without you and without an app store review?”
The answer sorts every proposal into two categories.
“You’ll be able to change X, Y and Z yourself.” Good — ask for the list, and ask whether building that capability is in the quote or assumed.
“Send us a ticket.” Then your marketing calendar now runs through a developer’s backlog and Apple’s review queue. Every banner is a ticket. Every seasonal theme is a release, with a review attached.
That is not a minor operational detail; it is the difference between a Friday sale that goes up on Friday and one that goes up when someone is available. A configuration-driven product handles this because theme, colours, layout, banners and feature toggles ship over the air — in a custom build, that capability is a feature someone has to write.
Question 2: what does year two cost?
Get a number, in writing, for annual maintenance, and get it before you sign anything.
What it has to cover:
- Two OS major releases a year, each deprecating something
- SDK and dependency updates
- Store policy changes — new privacy requirements and declaration forms arrive on the platforms’ schedule, not yours
- WooCommerce and plugin updates that change your data
- Your own changes
An app that is not maintained for two OS cycles starts breaking in ways your customers report as “the app is broken.” So maintenance is not optional, which means a quote without a maintenance line is an incomplete quote rather than a cheaper one.
The five-year table
Build this yourself, once:
| Agency build | Builder subscription | |
|---|---|---|
| Year 1 | Build cost | 12 × monthly + $124 platform fees |
| Years 2–5 | Annual maintenance × 4 | 12 × monthly × 4 + $99/yr |
| A design change | Developer time + review | Included, published over the air |
| A new campaign banner | Ticket + release | Publish from the console |
| Time to first launch | Months | Days, plus account timelines |
| You own the source | Yes | No |
| Bus factor | The agency | The vendor |
Fill in real numbers and the comparison usually answers itself. The rows that surprise people are not the money rows — they are the two change rows, because they are what you will experience weekly.
Where the agency genuinely wins
Three situations, and they are real:
1. Your buying experience is unusual. A configurator, a rental calendar with availability logic, customer-specific B2B price lists, made-to-measure. No catalog builder models these, and an agency can.
2. You have a real integration requirement. An ERP as the source of truth, warehouse logic, a loyalty programme that must be first-class.
3. The app is a strategic product with a roadmap and someone’s job attached. Then owning the code is the point.
If your requirement is “my catalog, on a phone, with notifications,” none of those apply, and you are buying a bespoke solution to a solved problem.
Where the builder wins
- Speed. Days rather than months.
- Change velocity. Merchandising and design without a release cycle.
- Predictable cost, with maintenance included rather than quoted annually.
- Nobody’s backlog between you and your own app.
And the honest limits: you do not own the code, you are dependent on a vendor’s roadmap, and anything genuinely unusual about your business is out of scope. Those are real, and they are exactly what the three agency cases above are for.
The negotiation move worth knowing
If you are leaning towards an agency, ask them to price two proposals:
- The full custom build.
- Configuring a builder for you, plus any custom work that genuinely cannot be done in it.
Good agencies will do this, and some will tell you honestly that option 2 is the better use of your budget. That conversation is worth having before you commit a five-figure sum — and the answer tells you a lot about whether you are talking to a partner or a vendor.
The middle path
Start with a builder. Run the app for a year. Find out empirically which features your customers use, what your store actually needs, and where the product genuinely falls short.
If you then commission a custom app, you will be writing a brief informed by a year of real data instead of a year of assumptions. That is a better brief, a cheaper discovery process, and a much lower chance of paying for features nobody opens.
Related reading