How much do photo and video features add to development?

A client sits down with a development team and says four words: "add a camera feature." To the client, this feels like a small addition, maybe a week of work, a line item on the backlog that sits somewhere between push notifications and a profile page. To the developer hearing it, those four words open into a question that takes months and tens of thousands of pounds to answer properly.

Photo and video features are among the most consistently underestimated categories in mobile development, wide enough to swallow a budget whole.

Photo and video features are among the most consistently underestimated categories in mobile app development. The gap between what a client imagines ("users can upload photos") and what the feature actually requires (compression pipelines, format handling, device permissions, storage infrastructure, moderation tooling, and compliance review) is wide enough to swallow a budget whole. We see this play out in real project costs and real project failures, and the pattern is consistent enough that we now treat any brief containing camera, photo upload, video recording, or media sharing as a signal to slow down and map the full scope before agreeing a number.

This article is a working guide to where the cost actually lives in photo and video development, what drives it upward mid-project, and what a realistic budget looks like once you account for the full picture rather than the optimistic one.

What 'Add a camera feature' actually means in development terms

The phrase "camera feature" compresses a significant amount of technical work into two words. At minimum, accessing a device camera involves handling OS-level permissions on iOS and Android separately, managing the camera hardware API for each platform, and dealing with the fact that those APIs behave differently across device manufacturers. That is before a single photo has been taken.

Once a photo exists, the work branches further. The app needs to handle what happens when a user grants permission, denies it, or revokes it mid-session. It needs to present a camera UI that feels native to the platform. It needs to manage what happens if the user switches apps mid-capture, or if a phone call interrupts recording. These are standard user behaviours that require explicit handling.

Video compounds everything

Video recording adds another layer. Where a photo is a single file produced in a fraction of a second, video involves continuous data capture, real-time encoding decisions, frame rate management, and audio synchronisation. A video feature that feels simple to a user, press record, stop, upload, requires the developer to handle encoding formats, bitrate targets, recording duration limits, background processing, and upload resumption if connectivity drops mid-transfer.

In-app camera versus photo library access

There is also a meaningful distinction between building an in-app camera and simply allowing users to select from their photo library. Library access is lighter to build. An in-app camera that needs filters, overlays, or any real-time processing is a significantly different piece of work, and the two are frequently conflated in early briefs.

Compression, formats, and file size: the invisible workload

Modern smartphones produce photo files between 3MB and 12MB, and video files that can reach several gigabytes for a minute of high-resolution footage. If an app accepts these files without processing them, the infrastructure costs compound quickly, upload times frustrate users, and the app becomes slow in ways that are hard to diagnose after the fact.

Compression is the answer, and it is a set of decisions about quality targets, format choices, and processing timing, each of which has implications for user experience and backend architecture. Compress too aggressively and a beauty app's product imagery looks degraded. Compress too little and storage costs become unmanageable within months of launch.

Format handling adds further complexity. iOS devices shoot in HEIC by default. Android devices typically produce JPEGs. Users importing from third-party apps may bring WebP, PNG, or RAW files. A photo upload feature that has not addressed format normalisation will fail in ways that are difficult to reproduce and harder to fix, because the failures are device-specific and file-specific rather than consistent.

Decide your quality-versus-storage trade-off before development begins. A beauty or fashion app needs different compression targets than a fitness tracking app. Setting this parameter late forces rework on both the processing pipeline and the storage infrastructure.

Video formats are more varied still. H.264, H.265, VP9, and AV1 all appear in the wild, and each has different compatibility profiles across devices and browsers. An app that plays back video uploaded from one device type on another device type has a compatibility problem that takes real engineering time to solve.

Device and OS fragmentation across photo and video

Testing a camera feature on one phone and one OS version is not testing. The range of devices and OS versions in active use across an app's user base creates a fragmentation problem that camera and video features expose more than almost any other part of the product.

Camera hardware varies enormously across Android devices. A feature that works correctly on a Samsung flagship may fail silently on a mid-range device from a different manufacturer because the camera API implementation differs at the hardware level. iOS is more consistent within its own ecosystem, but Apple changes camera APIs with major OS releases, and apps that are not tested against new versions before release can break camera functionality for users who update promptly.

Camera hardware varies enormously across Android devices, exposing fragmentation problems that no other feature reveals as reliably.

On the football-focused social media app we worked on, the client wanted a streamlined initial release on both iOS and Android. As scope grew and the design kept changing, budget became strained and we made the decision midway through to pause Android development and redirect the remaining budget to iOS. The client launched with iOS only, covering roughly half the potential market. That decision was forced partly by the compounding cost of testing and fixing camera and media behaviour across the Android device range, which is wider and less predictable than iOS.

OS version targeting decisions

Every app must decide which OS versions it will support. Supporting older versions means supporting older camera APIs, which creates additional development and testing work. Dropping older versions means excluding users who have not updated, which in some markets is a significant portion of the audience. This decision has a direct cost implication that is rarely surfaced in early scoping conversations.

Storage, bandwidth, and infrastructure costs that appear mid-project

Photo and video features do not just add development cost. They add ongoing operational cost that compounds with usage. Storage costs are the most obvious, but bandwidth costs during upload and delivery, processing costs for transcoding, and CDN costs for fast global delivery all accumulate in ways that are rarely modelled in early budget conversations.

A fitness and activewear app that allows users to upload workout videos is a media storage and delivery business from day one, and the infrastructure it needs looks more like a streaming platform than a typical mobile app backend. The difference in monthly running costs between a well-architected media pipeline and a naive implementation can reach thousands of pounds per month at modest scale.

The upload experience under real conditions

Upload reliability is a separate problem. Users upload photos and videos on mobile connections that drop, slow down, and switch between networks. An upload feature that does not handle interrupted transfers gracefully will lose user-generated content, which in a social or community product creates trust problems that are hard to recover from. Building resumable upload handling adds development time that is rarely budgeted at the outset.

On the alcohol buying and selling platform project we worked on, embedding web elements instead of building a proper API layer added roughly 20% uplift in work across the whole project. Because the client wanted to hold the budget, we dropped features at the end to compensate. Media handling creates the same dynamic: underestimate the infrastructure work early, and something else gets cut later.

Model your storage and bandwidth costs at three levels of adoption before agreeing a budget: light usage, expected usage, and a high-growth scenario. The difference between these three numbers will tell you whether your infrastructure design is appropriate or whether it will need rearchitecting once the app gains traction.

Third-party API dependencies and when they fail you

Photo and video features frequently depend on third-party services for processing, storage, delivery, or moderation. These dependencies introduce risks that are not always visible at scoping time but become very real once development is underway.

We encountered this directly on a proof-of-concept for a company building an app to share memories with audio attached. We initially integrated with Spotify for short audio clips. Spotify lacked a robust API for clips, and users would have needed a Spotify account, which degraded the experience. We switched to Deezer, which had a robust API, supported clips without requiring a user login, and opened the door to affiliate referral revenue when users wanted to hear a full track. The lesson was that the first obvious API choice was wrong, and discovering that cost time that had not been budgeted.

Media APIs have their own version of this problem. A video transcoding service that looks affordable at low volume has different pricing at scale. A third-party image processing API changes its terms. A CDN integration that worked cleanly in staging behaves differently in production. Each of these scenarios requires developer time to diagnose and fix, and none of them appear in a scope document that was written assuming the APIs would behave as documented.

Dependency on platform camera APIs

The camera APIs provided by Apple and Google are themselves dependencies. Apple deprecated the UIImagePickerController in iOS 14 in favour of PHPickerViewController. Apps built on the older API continued to work for some time, but eventually required migration. That migration is a development cost that arrives without warning and without budget if the team has not planned for it.

Before committing to any third-party media API, test it against your actual use case at the volume you expect within six months of launch. Pricing pages and documentation are written for the average use case, and your use case may not be average.

Safety, moderation, and compliance obligations you cannot retrofit cheaply

Any feature that allows users to upload photos or videos creates a safety and moderation obligation. This is a practical concern with legal, platform, and reputational dimensions that arrive early if they have not been planned for.

App stores apply their own review standards to apps with user-generated media. An app that allows photo or video upload without moderation infrastructure will face rejection or removal if that content violates platform policies. Building moderation tooling after the fact is more expensive than building it in from the start, because it requires retrofitting into an architecture that was not designed to accommodate it.

We learned a version of this on the peer-to-peer currency exchange product we built. The core transfer mechanism worked, but we had not factored in anti-money laundering requirements. Apple flagged the product as a potential vehicle for money laundering. We had to go back and add more stringent KYC checks, enhanced transfer security, and hard limits on transfers between parties. That retrofit took time and budget that the project had not planned for. Media moderation creates the same dynamic: the safety layer feels optional until the platform review makes it mandatory.

GDPR and data residency for user media

User-uploaded photos and videos are personal data under GDPR. Where that data is stored, how long it is retained, and how users can request deletion are all compliance questions with technical implications. A media pipeline that stores files on US-based infrastructure without addressing data residency for EU users has a compliance gap that will need closing before the app can operate properly in European markets.

How underestimation at scoping compounds once development is underway

The danger with photo and video features is that the underestimation compounds. Each additional complexity that was not scoped creates pressure on the budget, and that pressure tends to be resolved by cutting something else rather than by increasing the number.

On the dating app we worked on, the client chose to skip discovery for the messaging component and focus entirely on the onboarding process. That decision produced a generic messaging feature that contradicted the core product premise: it allowed automated and fake messages, which undermined all the verification work done during onboarding. Rewriting the messaging section cost approximately £15,000 in additional budget and two months of additional work. The principle applies directly to photo and video features: skipping discovery on a camera or upload component produces a generic implementation that will eventually need to be rebuilt.

According to McKinsey, 45% of IT projects exceed their budget. Photo and video features are one of the more reliable routes to being in that group, because the full scope is so rarely visible at the point when the budget is agreed.

The sports club app as a case study in compounding

On the sports club app project, the two co-founders were deeply embedded in the world the app was designed for. Both independently and consistently pushed to add more features. What should have reached market in three to four months never launched after twelve to fourteen months of development, and the budget nearly doubled. We warned them early that the budget would spiral and that they risked running out of funding before launching anything. The entire budget was spent and nothing was published to the app store. Media features were among the additions the founders kept requesting, and each one carried hidden complexity that was not acknowledged at the point of the request.

What realistic budget figures for photo and video features look like

Budget ranges for photo and video features vary considerably depending on what is actually being built. A useful way to think about this is in tiers, where each tier represents a meaningfully different level of complexity and infrastructure.

These are additive costs on top of the core app budget, not standalone project figures. They also do not include ongoing infrastructure costs for storage and bandwidth, which scale with usage and need to be modelled separately. For real-time video or telehealth-style features, Forasoft's own estimation data (self-reported, treating as an analogous reference rather than an industry benchmark) suggests MVPs typically run $130,000 to $320,000 and take 16 to 28 weeks, with transport infrastructure and compliance as the main cost drivers.

Moderation infrastructure, safety tooling, and compliance work add further cost that should be planned from the outset rather than retrofitted. A rough budget for a basic moderation layer, including reporting features and admin tooling, sits between £10,000 and £25,000 depending on the volume of content the app is expected to handle. On the anonymous messaging app we worked on, we built in-product reporting features to allow users to escalate concerns to the client's admin team. That work was added as we got deeper into the project, and it would have been cheaper to plan it from the start.

Conclusion

Photo and video features are infrastructure decisions with cost implications that extend from the first line of development code through to the monthly running costs of a live product. The gap between "add a camera feature" and the full scope of what that means in engineering, compliance, and infrastructure terms is where projects go over budget, miss launch dates, and sometimes fail to launch at all.

The consistent pattern across the projects we have worked on is that underestimation at scoping does not stay contained. It compounds. A camera feature that was not properly scoped creates compression decisions that were not made, infrastructure costs that were not modelled, and moderation obligations that were not budgeted. By the time those gaps become visible, the project is already in motion and the cost of addressing them is higher than it would have been at the outset.

The answer is to slow down before agreeing a number. Map the full scope of what the feature actually requires, model the infrastructure costs at realistic usage levels, and build the safety and compliance layer from the start rather than after a platform rejection forces it. A realistic budget agreed early is cheaper than an optimistic budget that has to be revised three months into development.

If you are scoping an app that includes photo or video features and want a clear-eyed view of what it will actually cost, let's talk about your project before the budget is set.

Frequently Asked Questions