Scroll Top

App Development Agencies: Cost and When Not to Build

Updated September 2026 · Written and maintained by the Progression Agency strategy team

The most useful thing an app development agency can tell a prospective client is that they do not need an app. Most business ideas that arrive as app briefs are better served by a mobile website, and the ones that genuinely need an app usually underestimate the ongoing cost by a wide margin, because an app is not a project that finishes. This page sets out when native development is genuinely warranted, what it costs to build and to keep, and how to choose an agency without buying the wrong thing.

The short answerAnswer three questions before commissioning anything. Does your idea need something a mobile website cannot do — camera, offline use, push notifications, background location, device hardware? If not, a responsive site reaches everyone immediately with no store approval and no install step. Will people use it more than once a week? Apps that are opened monthly get deleted. And can you fund it indefinitely? An app needs maintenance for operating system updates every year whether or not you change a single feature, and that recurring cost is the one most briefs omit entirely.

Cost figures are ranges typical of the US and near-shore market in 2026 and are stated as ranges rather than quotes; actual pricing depends on scope, platform count, backend complexity and team location. Platform policies described reflect Apple’s and Google’s own published developer documentation as of August 2026 and change regularly. Nothing here reports client results.

Progression Agency runs Web Development, Web Design and AI Automation as separate divisions. We build web applications rather than native mobile apps, which is why this page is written to help you decide honestly — including when the answer is that you need a native app and should hire a specialist rather than us. We are a New York City firm working across the United States.

The three questions before any app brief
The fifth row eliminates most app briefs, and eliminating them is the correct outcome. A responsive website reaches every device immediately, requires no store approval and no install, and costs a fraction to maintain.

Do you actually need an app?

Probably not. An app is warranted when your idea needs something a mobile website genuinely cannot do — device hardware, true offline operation, reliable push notifications, background location — and when people will open it weekly or more. Most briefs meet neither test.

This is worth stating plainly because the cost difference is enormous and runs in one direction. A responsive website reaches every device the moment it is published, needs no store approval, requires no install, and costs a fraction to maintain. An app starts with zero users and has to earn every single one through a download.

Camera, sensors or hardware — Needs an app. A website cannot reach these..
True offline use — Needs an app. Not merely slow connections..
Reliable push notifications — Needs an app. Web push is weaker on iOS..
Background location — Needs an app. Continuous, not on-demand..
Daily or weekly habit — Needs an app. Frequency justifies the install..
Device-integrated payments — Needs an app. Where it genuinely applies..
Product catalog — Website is better. No install, instant reach..
Booking or appointments — Website is better. A form works everywhere..
Content or publishing — Website is better. Search finds it; apps do not..
Occasional-use services — Website is better. Monthly use gets deleted..
Lead generation — Website is better. Nobody installs to enquire..
Anything needing search visibility — Website is better. Apps are invisible to search..

The install barrier is the cost nobody budgets

Every app user must decide to install something, find space for it, and remember it exists. That is a marketing cost, it recurs for every user, and it appears in almost no app budget. A website skips it entirely.

Content inside an app cannot be found by search engines, cannot be linked to in the ordinary way, and cannot be shared as easily. For any business whose customers arrive through search, moving functionality into an app removes it from the channel that was producing the customers.

Occasional-use apps get deleted

People clear apps they have not opened. Anything used monthly rather than weekly is competing for space against apps used daily, and it loses. Frequency of genuine use is the honest test of whether an install will survive.

Do you actually need a native app?
The last row is the most consequential no. An app with build funding and no maintenance budget becomes unusable within about two years as operating systems move, and the money spent building it is lost rather than saved.
Ideas plotted by whether an app is the right answer
The top-right quadrant genuinely needs an app; the bottom-left is where a mobile website does the same job for a fraction of the cost. Product catalogs and booking forms sit firmly in the second group and are commissioned as apps constantly.

The quadrant chart is the fastest version of this decision. Field service capture, health tracking and internal workflow tools genuinely need an app. Product catalogs, booking forms and lead generation sit at the opposite corner and are commissioned as apps constantly, at several times the necessary cost.

What does app development cost?

A simple single-platform app with a modest backend commonly starts in the mid five figures; a two-platform app with accounts, sync and an admin interface reaches six figures. The build is frequently the smaller half of the total.

Build options compared
Read the last column. Everything that requires an install starts at near-zero reach and has to earn every user through a download, which is a marketing cost most app budgets never account for.
Build options, what each costs and what it gives you
OptionTypical build costOngoing costBest forMain limitation
Responsive websiteLow to mid five figuresLowAlmost everythingNo device hardware access
Progressive web appLow to mid five figuresLowOffline-ish, installable feelWeaker push on iOS
Cross-platform appMid five to low six figuresModerateTwo platforms, one codebaseSome native edges
Native, one platformMid five to low six figuresModerateA single-audience productOnly reaches one platform
Native, both platformsSix figuresHighGenuine hardware-led productsTwo codebases to maintain
Backend and adminFrequently as much againModerate to highAnything with accounts or dataRegularly missing from quotes

The last row is where quotes go wrong most often. Accounts, data storage, synchronisation, notifications and an administrative interface are not part of the app people see, and they are regularly quoted as though they do not exist. Scope them separately and explicitly.

Cross-platform versus native is a maintenance decision

Cross-platform frameworks let one codebase serve both platforms, which lowers build cost and halves the ongoing maintenance surface. Native gives the best access to device features and the closest platform behavior. For most business apps the maintenance argument decides it, not the technical one.

The recurring cost is the real number

Apple and Google both change their operating systems annually, and both periodically require updated build targets for apps to remain in their stores. An app receives maintenance every year or it degrades until it stops working, whether or not you add a single feature.

The real lifecycle of an app, and where cost sits
The year-two row is the one omitted from most budgets. Operating systems change every year and an unmaintained app degrades until it stops working, which turns the original build spend into a sunk cost rather than an asset.

The lifecycle chart is the argument for treating an app as an ongoing commitment rather than a project. The year-two row is not optional maintenance; it is the cost of the app continuing to exist, and a budget that stops at launch guarantees the rewrite conversation two years later.

How do you brief an app properly?

Write down the one thing it must do, confirm a website genuinely cannot do it, decide platforms deliberately, scope the backend separately, budget maintenance from year one, and plan how anybody will discover it.

How to brief an app properly, if you still need one
Step five catches nearly everybody. The visible app is often the smaller half of the work; accounts, data, sync, notifications and an admin interface sit behind it and are regularly missing from the quote.
1 — Name the one thing it must do. Five things means not ready..
2 — Test whether a website could. Honestly, not defensively..
3 — Decide platforms deliberately. Both roughly doubles cost..
4 — Scope the backend separately. Often the larger half..
5 — Budget maintenance from day one. OS updates are annual..
6 — Plan how people find it. Downloads are marketing..

One thing, not five

An app that does one thing well is buildable, testable and explainable. A brief listing five features is a brief that has not decided what the product is, and it produces a longer, more expensive build with a worse result.

Downloads do not happen by themselves

Store search is a weak discovery channel for a new app with no reputation, and app store optimization is a discipline of its own. If nobody has planned how people will hear about it, the app will launch to the people already in your database and nobody else.

How do you choose an app development agency?

By whether they ask what a website could do instead, whether the backend is in the quote, what year two costs, and what happens at store rejection. The first question separates most reliably.

What could a website do instead? — Ask an agency. A good answer exists..
Is the backend in this quote? — Ask an agency. Frequently it is not..
What does year two cost? — Ask an agency. The number that decides it..
Who owns the code and accounts? — Ask an agency. Store accounts included..
What happens at store rejection? — Ask an agency. It is normal, not rare..
How will anyone find this? — Ask an agency. Downloads need a plan..
  1. What could a mobile website do instead of this app?
  2. Is the backend included in this quote, and what does it cover?
  3. What does year two cost if we change nothing?
  4. Native or cross-platform, and what is the reasoning?
  5. Who owns the code, the repositories and the store accounts?
  6. What happens if the app is rejected during store review?
  7. Who submits updates, and how quickly after an OS release?
  8. How will anybody discover this app?
  9. What is included in support, and what is billed separately?
  10. What would you tell us not to build?

Question one is the filter. An agency that answers it seriously — naming what a website genuinely could and could not do — is thinking about your outcome. One that treats it as an objection is selling a build.

Store accounts should be in your name

Apple and Google developer accounts, the code repository and any signing certificates should belong to your business with the agency granted access. Agencies holding store accounts is a recurring and entirely avoidable problem when a relationship ends.

Store rejection is normal

Apps are rejected during review for reasons ranging from metadata to functionality, and it is a routine part of launching rather than a failure. Ask how it is handled and whether resubmission is billed, because a first submission passing cleanly is not the common case.

Search demand across the app development cluster
The third term is the largest genuine question in this set. Most people searching for an agency are really trying to find out what it costs, which is why a page that answers that plainly serves them better than a services page.

The demand chart shows what people are really asking. The largest genuine question in this cluster is what an app costs, not which agency to use, which is why a page answering the cost question plainly serves the audience better than a services page does.

What about Android specifically?

Android development is broadly comparable in cost to iOS with a wider device and version range to test against, which adds testing effort rather than build effort. An Android app development agency and an iOS one are usually the same firm with different specialists on the team.

Where the platforms genuinely differ for a business decision is audience and payments. Which platform your customers actually use should be established before committing to both, because building for one and adding the second later is a legitimate and much cheaper sequence.

Should you build for one platform first?

Frequently yes, and it is under-used. Building for the platform your audience actually uses produces a real product at roughly half the cost, generates genuine feedback, and defers the second platform until you know whether the first one worked.

What is a progressive web app, and does it help?

A website built to behave more like an app: installable to a home screen, capable of working offline to a degree, and delivered without a store. It sits between a website and a native app and covers a meaningful share of briefs that arrive as app requests.

Its main limitation is notification support, which is weaker on iOS than on Android. If push notifications are central to the product, that constraint matters; if they are not, a progressive web app frequently delivers what was wanted at a fraction of both costs.

How long does an app take?

Roughly six months to a first public release for a modest two-platform app: a month of discovery and design, three to four months of build, and a month for store submission and the rejection cycle. Faster is possible on one platform with a narrow scope.

What should be in the contract?

Named deliverables, ownership of code and store accounts, what maintenance covers and costs, response times for OS-driven fixes, who submits updates, and what happens on store rejection. Maintenance terms matter more here than in almost any other kind of build.

When is an app genuinely the right answer?

When device capability is essential, usage is frequent, and the business case survives the maintenance cost. Field service tools, health and fitness tracking, and internal workflow applications regularly pass all three.

What if you have already built an app that nobody uses?

Establish whether the problem is discovery or fit before spending more. An app nobody knows about needs marketing; an app people installed and abandoned needs an honest look at whether a website should have done the job.

Common mistakes

Seven, and the first is the most expensive decision in this entire category.

App development mistakes and what to do instead
MistakeConsequenceInstead
Building an app a website could beSeveral times the cost, a fraction of the reachTest the website option honestly
Omitting the backend from the budgetThe larger half of the work unquotedScope it separately and explicitly
No maintenance budgetUnusable within about two yearsFund it from year one, indefinitely
Building both platforms firstDouble cost before any validationOne platform, then decide
No discovery planLaunch to your existing database onlyPlan how people hear about it
Agency-held store accountsYou cannot update your own appEverything in your name, day one
A brief with five core featuresLonger build, worse productOne thing, done properly

For the alternatives, our web development page covers what a web application can do, the web design page covers responsive builds, and the ecommerce development page covers transactional sites that are frequently commissioned as apps by mistake.

App versus mobile website, decided by what your idea needs
RequirementMobile websiteProgressive web appNative app
Reach without an installYesMostlyNo
Findable in searchYesYesNo
Camera and device sensorsLimitedLimitedFull
Works fully offlineNoPartlyYes
Reliable push notificationsWeakWeak on iOSYes
Background locationNoNoYes
Cost to buildLowestLowHighest
Cost to maintainLowestLowHighest

Read down the first two rows before anything else. Reach without an install and visibility in search are the two things a native app gives up, and for a large share of business ideas those are precisely the two things that were producing the customers.

What people are really asking when they search for an app development company

Answer first: mobile app development cost, more often than anything else. The largest search term in this cluster is about price rather than supplier, which means a page that answers the cost question plainly is more useful than a page describing services.

Mobile app development cost by scope, and what drives each number
ScopeTypical build rangeOngoing per yearWhat drives the cost
Progressive web appLow to mid five figuresLowSame as a website; no store cycle
Single-platform, no accountsMid five figuresModerateFeature count and design depth
Single-platform with accounts and backendMid to high five figuresModerateThe backend, usually underestimated
Cross-platform, both storesHigh five to low six figuresModerate to highOne codebase, two store cycles
Native both platformsSix figuresHighTwo codebases to build and maintain
Hardware-integrated productSix figures upwardHighDevice testing and edge cases
Ongoing maintenance onlyNot applicableLow to moderateAnnual OS changes, regardless of features

Read the final row against every row above it. Maintenance is the only line that never goes away, and an app development company quoting a build without stating it is quoting half the commitment.

Why an app development company should quote year two

Because the build number alone makes an app look like a project. Asking for the year-two figure converts it into what it actually is: a recurring commitment with an upfront cost attached, which is the frame the decision should be made in.

Where an app development agency and a web agency differ

Store submission, device testing across many models, platform release cycles and native tooling are genuine specialisms. A web agency taking on a native app without those is a real risk, and so is a mobile specialist insisting an app is required when a website would serve.

What an honest supplier says first

That a website might do it. Any app development agency willing to lose the build by naming what a responsive site could achieve is giving you the single most valuable piece of information in this whole process.

Not sure whether you need an app or a website?

Tell us the one thing your idea has to do and roughly how often people would use it, and we will tell you honestly whether it needs a native app — including when the answer is yes and you should hire a mobile specialist rather than us.

Talk to Progression Agency

Video: mobile development and product decisions

Three talks on mobile development, product scoping and the web platform. Everything relevant to the build decision above is written out in text, so nothing on this page depends on watching them.

Getting found in search

AI, AEO and what is changing

Paid media and lead generation

Websites and design

Choosing and working with an agency

Social, content and brand

By industry and by situation

Frequently asked questions

Do I actually need an app?
Probably not. An app is warranted when your idea needs device hardware, true offline operation, reliable push notifications or background location, and when people will open it weekly or more. Most briefs meet neither test.
When is a mobile website better than an app?
For product catalogs, booking and appointments, content and publishing, lead generation, and anything used occasionally. A website reaches every device immediately with no store approval, no install and a fraction of the maintenance.
How much does app development cost?
A simple single-platform app with a modest backend commonly starts in the mid five figures; a two-platform app with accounts, sync and an admin interface reaches six figures. The visible app is frequently the smaller half of the total.
What is usually missing from an app quote?
The backend. Accounts, data storage, synchronisation, notifications and an administrative interface are not part of the app users see and are regularly quoted as though they do not exist. Scope them separately.
What does an app cost to maintain?
Enough that it belongs in the budget from year one. Apple and Google change their operating systems annually and periodically require updated build targets, so an app needs maintenance every year whether or not you add features.
What happens if I do not maintain an app?
It degrades until it stops working, usually within about two years, and can be removed from the stores for outdated build targets. The original build spend becomes a sunk cost rather than an asset.
Should I build for iOS and Android at once?
Frequently not. Building for the platform your audience actually uses produces a real product at roughly half the cost, generates genuine feedback, and defers the second platform until you know whether the first one worked.
Native or cross-platform: which should I choose?
For most business apps it is a maintenance decision rather than a technical one. Cross-platform serves both platforms from one codebase and halves the ongoing surface; native gives the best device access and closest platform behavior.
What is a progressive web app?
A website built to behave more like an app: installable to a home screen, able to work offline to a degree, delivered without a store. It covers a meaningful share of briefs that arrive as app requests, at a fraction of both costs.
What is the limitation of a progressive web app?
Notification support, which is weaker on iOS than on Android. If push notifications are central to the product that constraint matters; if they are not, a progressive web app frequently delivers what was actually wanted.
Why do occasional-use apps fail?
Because people clear apps they have not opened. Anything used monthly rather than weekly competes for space against apps used daily and loses. Genuine usage frequency is the honest test of whether an install survives.
Are apps visible to search engines?
No. Content inside an app cannot be found by search engines, linked to in the ordinary way, or shared as easily. For a business whose customers arrive through search, moving functionality into an app removes it from the channel producing customers.
How long does app development take?
About six months to a first public release for a modest two-platform app: a month of discovery and design, three to four months of build, and a month for store submission and the rejection cycle. Narrower single-platform scopes go faster.
Is store rejection common?
Yes, and it is routine rather than a failure. Apps are rejected for reasons ranging from metadata to functionality. Ask how it is handled and whether resubmission is billed, because a clean first submission is not the common case.
Who should own the app store accounts?
You. Apple and Google developer accounts, the code repository and signing certificates should belong to your business with the agency granted access. Agency-held store accounts are a recurring and entirely avoidable problem.
What questions should I ask an app development agency?
What a website could do instead, whether the backend is in the quote, what year two costs, native or cross-platform and why, who owns the code and store accounts, what happens at rejection, and what they would tell you not to build.
Is Android app development different in cost from iOS?
Broadly comparable to build, with a wider device and version range to test against, which adds testing effort rather than build effort. An Android app development agency and an iOS one are usually the same firm with different specialists.
How will people find my app?
Only if you plan it. Store search is a weak discovery channel for a new app with no reputation, and store optimization is a discipline of its own. Without a plan, the app launches to your existing database and nobody else.
What should be in an app development contract?
Named deliverables, ownership of code and store accounts, what maintenance covers and costs, response times for operating-system-driven fixes, who submits updates, and what happens on store rejection. Maintenance terms matter unusually much here.
What kinds of apps are genuinely worth building?
Ones where device capability is essential, usage is frequent and the business case survives the maintenance cost. Field service data capture, health and fitness tracking, and internal workflow tools regularly pass all three tests.
What should I do if my existing app has no users?
Establish whether the problem is discovery or fit before spending more. An app nobody knows about needs marketing; an app people installed and abandoned needs an honest look at whether a website should have done the job.
Why should a brief describe only one core feature?
Because an app doing one thing well is buildable, testable and explainable. A brief listing five features has not decided what the product is, and it produces a longer, more expensive build with a worse result.

Sources and further reading

  1. Google Search Essentials — SEO starter guide
  2. Google: creating helpful, reliable, people-first content
  3. Google: intro to structured data
  4. Google: LocalBusiness structured data
  5. Google: FAQPage structured data
  6. Google: Article structured data
  7. Google: Product structured data
  8. Google: title links in search results
  9. Google: control your snippets
  10. Google: robots.txt introduction
  11. Google: sitemaps overview
  12. Google: consolidate duplicate URLs
  13. Google: redirects and Search
  14. Google: JavaScript SEO basics
  15. Google: multi-regional and multilingual sites
  16. Google Search Central Blog
  17. Google: get started with Search Console
  18. Google: how local search results are determined
  19. Google Business Profile: prohibited and restricted content
  20. Google Business Profile: address and service area guidelines
  21. Google Business Profile: review policy
  22. Google Business Profile: add or edit categories
  23. Google Ads: location targeting settings
  24. Google Ads: about negative keywords
  25. Google Ads: about Quality Score
  26. Google Ads: importing offline conversions
  27. Google Ads: about Smart Bidding
  28. Google Ads: about Performance Max
  29. Google Local Services Ads: eligibility and screening
  30. Google Ads: keyword match types
  31. Google Analytics 4: about conversions
  32. Google Analytics 4: attribution models
  33. US Census Bureau QuickFacts: New Jersey
  34. US Census Bureau: American Community Survey
  35. US Census: Statistics of US Businesses
  36. Bureau of Labor Statistics: New Jersey data
  37. BLS: Occupational Employment and Wage Statistics
  38. NJ Department of Labor: labor market information
  39. New Jersey Business Action Center
  40. US Small Business Administration: New Jersey district
  41. USA.gov: business resources
  42. web.dev: Core Web Vitals explained
  43. web.dev: Largest Contentful Paint
  44. web.dev: Cumulative Layout Shift
  45. web.dev: Interaction to Next Paint
  46. Google PageSpeed Insights
  47. Google Rich Results Test
  48. Google Search Console
  49. W3C Markup Validation Service
  50. Schema.org: LocalBusiness type
  51. Schema.org: Service type
  52. Schema.org: FAQPage type
  53. Schema.org: HowTo type
  54. W3C: WCAG 2.2 quick reference
  55. FTC: CAN-SPAM Act compliance guide
  56. FCC: telemarketing and robocall rules (TCPA)
  57. FTC endorsement guides — reviews and testimonials
  58. FTC: rule on consumer reviews and testimonials
  59. HHS: HIPAA guidance on online tracking technologies
  60. New Jersey Courts: attorney advertising guidelines
  61. New Jersey DCA: construction codes and permits
  62. New Jersey Home Improvement Contractor registration
  63. New Jersey Division of Consumer Affairs
  64. TikTok for Business
  65. TikTok Creative Center
  66. TikTok Ads Help Center
  67. TikTok Community Guidelines
  68. TikTok Terms of Service
  69. TikTok Privacy Policy
  70. TikTok Safety Center
  71. TikTok Transparency Center
  72. TikTok Creator Portal
  73. TikTok Newsroom
  74. TikTok for Developers
  75. TikTok advertising solutions
  76. TikTok Creator Marketplace
  77. TikTok Business Center
  78. TikTok for Business blog
  79. TikTok Creative Center: top ads
  80. TikTok Branded Content policy
  81. TikTok Shop for sellers
  82. Instagram for Business
  83. Instagram for Creators
  84. Instagram Help Center
  85. About Instagram
  86. Meta Business Suite
  87. Meta Business Help Center
  88. Meta Transparency Center
  89. About Meta
  90. Meta: Instagram platform docs
  91. YouTube Creators
  92. YouTube Official Blog
  93. YouTube Shorts help
  94. How YouTube Works
  95. YouTube Studio
  96. LinkedIn Marketing Solutions
  97. LinkedIn Help
  98. Pinterest Business
  99. Pinterest Business Help
  100. Snapchat for Business
  101. X for Business
  102. Reddit communities
  103. Reddit for Business Help
  104. ASCAP
  105. BMI
  106. SESAC
  107. Global Music Rights
  108. PRS for Music (UK)
  109. PPL (UK)
  110. SOCAN (Canada)
  111. APRA AMCOS (Australia)
  112. GEMA (Germany)
  113. SACEM (France)
  114. SIAE (Italy)
  115. JASRAC (Japan)
  116. IFPI
  117. RIAA
  118. National Music Publishers Association
  119. Harry Fox Agency
  120. SoundExchange
  121. Music Reports
  122. Epidemic Sound
  123. Artlist
  124. Soundstripe
  125. PremiumBeat
  126. AudioJungle
  127. Free Music Archive
  128. Creative Commons
  129. Incompetech
  130. FTC: advertising and marketing
  131. FTC: disclosures 101
  132. FTC: endorsement guides
  133. FTC: consumer reviews rule
  134. FTC: advertising FAQs
  135. US Copyright Office
  136. US Copyright Office: DMCA
  137. US Copyright Office: music FAQ
  138. US Copyright Office: fair use FAQ
  139. USPTO: trademarks
  140. UK Advertising Standards Authority
  141. ACCC (Australia)
  142. Competition Bureau Canada
  143. GDPR overview
  144. California Consumer Privacy Act
  145. COPPA
  146. FTC: children’s privacy
  147. W3C Web Accessibility Initiative
  148. W3C: WCAG
  149. W3C: captions
  150. W3C: making audio and video accessible
  151. ADA.gov
  152. WebAIM
  153. Epilepsy Foundation
  154. Pew Research: internet and technology
  155. DataReportal
  156. US Census Bureau
  157. US Bureau of Labor Statistics
  158. Interactive Advertising Bureau
  159. Think with Google
  160. Google Trends
  161. Nielsen insights
  162. Schema.org: VideoObject
  163. Schema.org: SocialMediaPosting
  164. Schema.org: MusicRecording
  165. Schema.org: HowTo
  166. Schema.org: FAQPage
  167. Schema.org: Organization
  168. Google: video best practices
  169. Google: video structured data
  170. CapCut
  171. Adobe Premiere Rush
  172. DaVinci Resolve
  173. Canva
  174. Descript
  175. VEED
  176. Kapwing
  177. Otter.ai
  178. Later
  179. Buffer
  180. Hootsuite
  181. Sprout Social
  182. Google Analytics
  183. Google Search Console
  184. Google Analytics developer docs
  185. GA4: events and conversions
  186. Matomo
  187. Plausible Analytics
  188. Similarweb
  189. UK Information Commissioner’s Office
  190. Office of the Privacy Commissioner of Canada
  191. Australian OAIC
  192. European Data Protection Board
  193. EU data protection
  194. EU Digital Services Act
  195. Ofcom
  196. FCC
  197. AIGA
  198. Nielsen Norman Group
  199. Smashing Magazine
  200. web.dev
  201. MDN: web media
  202. MDN: the video element
  203. ISO 21001 (reference)
  204. Buma/Stemra (Netherlands)
  205. STIM (Sweden)
  206. Teosto (Finland)
  207. Koda (Denmark)
  208. TONO (Norway)
  209. IMRO (Ireland)
  210. SGAE (Spain)
  211. ZAiKS (Poland)
  212. KOMCA (South Korea)
  213. MCSC (China)
  214. CISAC
  215. World Intellectual Property Organization
  216. TikTok: creating videos
  217. TikTok: exploring videos
  218. TikTok: privacy settings
  219. TikTok: growing your audience
  220. TikTok Creator Academy
  221. TikTok Effect House
  222. TikTok for small business
  223. Instagram: Reels help
  224. YouTube: Shorts best practice
  225. How YouTube recommends
  226. Pinterest Predicts
  227. Snapchat for Business
  228. Hootsuite blog
  229. Social Media Examiner
  230. Marketing Week
  231. Adweek

Get a free marketing proposal

Tell us what you are trying to grow and we will come back with a plan, not a pitch deck. Same-day reply on weekdays.

Our website uses cookies from third party services to improve your browsing experience. Read more about this and how you can control cookies by clicking "Privacy Preferences".
Privacy Preferences
When you visit our website, it may store information through your browser from specific services, usually in form of cookies. Here you can change your privacy preferences. Please note that blocking some types of cookies may impact your experience on our website and the services we offer.
Privacy Policy
You have read and agreed to our privacy policy
Required