---
title: What a Film Industry Production Portal Taught Us About Designing Around Access We Didn't yet Have
description: How a film production portal adapted when planned integrations fell through, and how to de-risk access assumptions before you build.
image: https://weareaffective.com/hubfs/learning-centre-images/what-a-film-industry-production-portal-taught-us-about-designing-around-access-we-didnt-yet-have.webp
---

[Skip to content](https://weareaffective.com/learning-centre/what-a-film-industry-production-portal-taught-us-about-designing-around-access-w#main-content)

[![we\_are\_affective\_logo\_200](https://weareaffective.com/hs-fs/hubfs/we_are_affective_logo_200.png?width=175&height=48&name=we_are_affective_logo_200.png "we_are_affective_logo_200")](https://weareaffective.com)

- [Home](https://weareaffective.com)
- About Us 
  
    - [Our Story](https://weareaffective.com/about)
    - [How We Work](https://weareaffective.com/how-we-work)
- Our Services 
  
    - [App Planning & Strategy](https://weareaffective.com/app-planning-strategy)
    - [App Design](https://weareaffective.com/app-design-agency)
    - [App UX Design](https://weareaffective.com/app-ux-design)
    - [App UI Design](https://weareaffective.com/app-ui-design)
    - [App Technical Architecture](https://weareaffective.com/app-architecture)
    - [Existing App Audits](https://weareaffective.com/app-audit)
- [Case Studies](https://weareaffective.com/case-studies)
- [Pricing](https://weareaffective.com/pricing)
- [Learning Centre](https://weareaffective.com/learning-centre)

- [Get Started](https://weareaffective.com/get-started)

Expert Guide Series

# What a Film Industry Production Portal Taught Us About Designing Around Access We Didn't yet Have

 Table of Contents

We worked on a production management product for the motion picture industry, and the plan on day one looked simple enough. Productions already store their documents in established platforms, so we expected to connect to those platforms directly and pull the data across. Email integrations sat alongside that as a second route in. The architecture, the schedule and a good part of the budget were drawn around that expectation.

Then we got access, and the systems turned out to be far more locked down than anyone had described to us. Not slow. Not badly documented. Closed. The permissions we needed were never going to be handed to a product whose makers had no formal relationship with the platform owners.

> Access promised on a call and access tested with real credentials are two different things.

[What followed was a rebuild of how data got into the product](https://weareaffective.com/learning-centre/what-film-industry-document-portal-users-taught-us-about-designing-for-people-wh) at all. We ended up ingesting emails tied to specific roles within a production and processing the data from there, with no direct connection into the third-party platforms. It worked, and users never had to think about why it worked that way.

This piece walks through what we planned, what we found, what we built instead, and what the pivot cost us. It also covers other projects where somebody else's access rules quietly decided the shape of our work.

## The Integration We Planned For

Film productions run on paper that changes daily. Call sheets, schedules, crew lists, scripts and revisions all move between a lot of people very quickly, and almost none of it starts life inside the product we were building. So the first design question was about where the data lived and how it got in.

Our plan had two parts. We would read from the platforms productions already used to store documents, and we would ingest email as a supporting route for anything that arrived outside those platforms. The product's whole promise rested on that first part. If a schedule was revised at six in the morning, the portal should already know by the time anyone opened it.

Designing around other people's systems is normal now. Per [Salesforce, 2023](https://www.salesforce.com/news/stories/connectivity-report-2023/#:~:text=As%20organizations%20become%20more%20digital,%20customer%20experiences%20and%20generate%20revenue), 99% of organisations say they use APIs to connect applications and data, which tells you how routine the assumption has become. Routine assumptions are the ones nobody tests.

We did what the majority do. We read the public documentation, looked at what the platforms advertised, and treated access as a procurement detail to be sorted out once the commercial conversation matured. The product design moved ahead of that conversation. That sequencing was the mistake, and it is a very easy one to make.

## Discovering the Doors Were Locked

The film industry has a specific reason to be paranoid. Scripts leak. Unreleased footage leaks. Cast and location details leak. Every platform serving that industry is built by people who have spent years being shouted at about exactly that, so the security posture is not an accident and it is not negotiable by a new product with no track record.

When we finally got into those systems, we found how tightly shut they were. The data we wanted to read was not exposed in any way we could reach. There was no partner tier to apply for, no sandbox with sample documents, no route that ended in us holding a key. Waiting longer was not going to change the answer.

That is a harder position than a difficult integration. A difficult integration is a cost. A refused integration is a design problem, because the feature that justified the product still has to exist somehow.

The useful thing was that we found out while there was still room to change course. Had we discovered it two months later, the pivot would have landed on top of a finished interface built around data that never arrived.

Ask for live credentials and one real document in the first week of discovery, before the architecture is agreed. A platform's willingness to hand those over tells you more than any documentation page.

## Start your app project the *right* way

We deliver the complete blueprint before a line of code is written. User research, psychology-driven design and full technical specifications. You choose who builds it.

[See how we work](https://weareaffective.com/how-we-work) [Get started](https://weareaffective.com/get-started)

No commitment

## Why Access Assumptions Break So Often

The documentation describes what a system can do. It rarely describes who is allowed to ask. Those are separate questions, and the second one is answered by a security team, a legal team or a commercial team who have never heard of your project and have no reason to prioritise it.

There is also a gap between the people who sell a platform and the people who guard it. A pleasant call with a partnerships manager is not permission. The partnerships manager may genuinely believe it is.

Even when nothing is locked, teams struggle with the basics. [Postman, 2025](https://www.postman.com/state-of-api/2025/) found 93 per cent of teams still hit API collaboration problems, including gaps in documentation and difficulty finding out which APIs already exist.

> Documentation tells you what a system can do, never who is allowed to ask.

The same trap appears below the surface, in code you already own. On a wellness genetics product, we put a new interaction and emotional design layer over an existing functional codebase, and the handoff ran through an intermediary designer. That added distance between what the design intended and what the code could actually support. Applying a fresh layer to existing code is doable. It just needs watching very closely, because the constraints only show themselves once someone tries to build.

## Designing a Parallel Ingestion Route

Our alternative was to stop asking the platforms for anything. Production documents already travel by email, and they travel to predictable people. Certain roles within a production receive certain documents as a matter of routine. So we built ingestion around those roles instead, taking the emails tied to specific positions and processing the data from them.

The product got what it needed. The schedule change still landed in the portal. Nobody had to log into a third-party system, and no partner agreement had to be signed by a platform with no interest in signing one.

| Dimension | Direct platform integration | Role-based email ingestion |
| --- | --- | --- |
| Permission needed | Platform owner's approval | The production's own approval |
| Data source | Document store | Mail tied to a role |
| Setup effort | One-off, by us | One-off, by the production |
| Breaks when | Permissions change | A document skips the usual route |
| Time to build | Unknown, blocked | Known, under our control |

Reading that table, the second column looks worse on paper and better in practice, because every line in it was something we could actually deliver. A route you control and can test beats a better route that depends on a decision somebody else keeps deferring.

## Making the Workaround Invisible

The biggest risk was that the new route felt like an extra step. That would have undone the point of the feature. People wanted integration so data arrived without anyone fetching it, so a workaround that asked users to do more work each day had no value at all.

So we designed for a single moment of setup and then silence. Someone configures the role-based ingestion once at the start of a production, and after that the documents simply appear where people expect them. No daily forwarding, no reminders, no second place to check.

We had learned a version of this on a group travel product. There, we [redesigned checkout so the lead booker did not carry every passport number](https://weareaffective.com/learning-centre/what-a-travel-ota-learned-by-distributing-the-booking-form-across-the-whole-grou) and personal detail alone. Individual travellers could be invited to fill in their own information, and the booking updated as each person finished their part. The lead booker only completed the minimum needed to hold the reservation.

That worked because it was an addition people opted into, with manual entry still there for anyone who needed it. A parent entering their children's details has no one to invite, and the flow never punished them for that. The same principle held on the production portal. The alternative route had to sit underneath existing habits rather than asking anyone to form new ones.

## Accessibility Under Time Pressure on Set

We also worked on a [document portal for the film industry used by a wide mix](https://weareaffective.com/learning-centre/what-film-industry-document-portal-users-taught-us-about-designing-for-people-wh) of people, and accessibility became an active design priority rather than a compliance exercise. The reason was the setting. People open this thing on set, in bad light, with ten seconds to find the right version of the right document before they are needed somewhere else.

So the design was large-scale and very easy to move around. Everything in it was built around reaching information as quickly and as simply as possible. Big targets, obvious hierarchy, short routes to the file someone actually wanted.

Timing matters as much as layout. Most building management and concierge apps hand you the full directory of information the moment you finish onboarding, which ignores how people feel at that point. On a product where we controlled the sequencing, we treated when information appeared as an emotional design question rather than a filing question. The production portal borrowed that thinking, showing what was relevant to the day rather than everything the production had ever produced.

Design for the worst physical conditions your users will face, not the conditions in your office. If it works one-handed on a phone outdoors, it works everywhere else.

## Counting the Real Cost of a Pivot

Changing how data enters a product is never a small edit. On an alcohol buying and selling platform, we were forced to embed web elements rather than build a proper API layer, and that single constraint added roughly a 20% uplift in work across the whole length of the project. The client wanted the budget held where it was, so we dropped features towards the end to pay for it.

That is the trade almost nobody plans for. The work has to come from somewhere, and it usually comes out of the back end of the roadmap, where the things that made the product distinctive tend to live.

> Integration work rarely takes the budget, it takes the features you planned to build at the end.

On a travel product, [we integrated with a third-party aggregator at the client's request](https://weareaffective.com/learning-centre/what-happens-when-third-party-apis-break-or-shut-down). Partway through development the client worked out the aggregator's added costs made the financial model unworkable, and switched to a different supplier using a fundamentally different API style. We went back to the drawing board and re-engineered large parts of the integration layer. Later the client added a [third external service for specific bookings](https://weareaffective.com/learning-centre/what-happens-when-third-party-apis-break-or-shut-down), which meant another round of review, rewriting and security checks.

Underestimating this is [common enough to have a rule of thumb attached](https://weareaffective.com/learning-centre/what-are-the-most-common-mistakes-startups-make-when-building-their-first-app). [Planeks](https://www.planeks.net/api-cost-calculator/) suggests confusing API development with API integration can throw a budget out by three to five times.

## Taking Ownership When You Cannot Get Access

Sometimes the blocker is a person rather than a policy. On a trading platform for the drinks industry, we inherited a tightly coupled web product built by a third-party developer with no API layer exposed at all. When we needed to connect parts of the system together, we had to ask that developer how to reach the data, and the replies came slowly.

Waiting was costing more than acting. So we took the lead, wrote the API specification ourselves, built towards that spec, and had the third-party developer implement it. Owning the spec broke the deadlock and the project moved again.

Ownership cuts the other way too. On a social football product, the client held the App Store Connect Account Holder role because the account was registered in their name. They gave us admin access to most of it, and we set up three internal testing groups, one for our team, one for the client, and an external QA beta group for their testers. That let us control which builds reached which group.

As launch approached, the client started going in and sending already-uploaded builds to whoever they fancied, which caused problems we had little power to stop. The account was theirs, so the final say was theirs.

## Choosing a Different Third Party Entirely

We did proof-of-concept work for a company [building an app where people attach audio](https://weareaffective.com/app-development) to shared memories. Spotify was the obvious starting point, and we looked at it first. Two things ruled it out. There was no proper API for short clips, and users had to hold a Spotify account before they could hear anything, which chipped away at the experience for everyone else.

We moved to Deezer. It had a full API, it supported clips, and listening did not require the user to be logged in. That let us build a working proof of concept where people searched a catalogue larger than Spotify's and attached clips inside the app itself.

The switch paid for itself twice. When someone wanted the whole track rather than the clip, there was a natural upsell to a Deezer subscription, which opened an affiliate referral line sitting alongside the product's own income.

Buyers notice this stuff. [Inbox Insight](https://www.inboxinsight.com/b2b-tech-buyer-behavior-stats/#:~:text=%2A%2A90,%20makers.%20It) reports that 90% of B2B buyers say a vendor's ability to connect with their existing tools shapes whether that vendor gets shortlisted. The named brand is worth less than the integration actually working.

## Staging Integrations Until You Have Leverage

On a [toll management project, we spent real time explaining](https://weareaffective.com/learning-centre/what-the-toll-management-project-taught-us-about-betting-a-product-on-an-api-tha) to the client how APIs work and what it takes to set up a formal data-sharing relationship with an established toll operator. The honest answer was uncomfortable. A brand-new product with no users and no track record has almost nothing to offer an incumbent in exchange for access.

So we made the case for sequencing it. Launch using the preloaded credit model, which needed nobody's permission, and go after API integrations later, once the platform had users, revenue and a reason for an operator to take the call. The client accepted that staging.

This reframes access as something you earn rather than something you request. Credibility is the currency, and you cannot spend it before you have it.

The same logic applied to the film portal. Role-based email ingestion got the product live and useful. If it reaches a point where productions depend on it, the conversation with those document platforms starts from a different place entirely.

Write the version one that needs no one's permission. Keep the permissioned version on the roadmap as an upgrade, priced and scoped, so nobody mistakes it for a promise.

## How to De-Risk Access Before You Build

Everything above points at the same fix, which is moving the access question to the front of the project where it is cheap to answer. Discovery is where this belongs. [Nielsen Norman Group](https://www.nngroup.com/articles/discoveries-in-industry-revealed/) puts the reduction in project failure risk from more discovery time at 75%, and access testing is some of the highest-value discovery work available.

Here is the order we work in now.

1. Request live credentials in week one, before any architecture is signed off.
2. Make one real call against the real system with real data, not sample data.
3. Find out who approves partner access and how long their approval takes.
4. Design a fallback route in parallel, and price it properly.
5. Agree with the client, in writing, which route version one ships on.

Step four is the one that gets skipped, because designing two routes feels wasteful when everyone assumes the first will work. It costs a fraction of what a mid-build pivot costs, and it changes the conversation with the client from bad news to a decision between two things you have already thought about.

## Conclusion

The film production portal shipped with a route into the data that nobody had drawn on the original architecture diagram. Emails tied to specific roles went in, processed data came out, and the people using it on set never needed to know why. The large-scale, fast-to-read design mattered more to them than any of the plumbing underneath it.

What the project changed for us was sequencing. Access now gets tested before the design depends on it, because the alcohol platform taught us what a 20% uplift does to a fixed budget, and the travel product taught us what happens when a supplier changes halfway through. Both of those were recoverable. Both were also avoidable with a harder question asked earlier.

If you are planning a product around a system you do not own, the useful move is to find out today exactly what you are allowed to read. The answer shapes your roadmap whether you ask or not. Asking early just means you get to choose what to build instead.

If you are weighing up an integration you have not tested yet, or working out what to ship while access is still being negotiated, [let's talk about your integration plan](https://weareaffective.com/get-started).

## Frequently Asked Questions

What went wrong with the original integration plan?

The team assumed they could connect directly to the document platforms productions already used, and built the architecture, schedule and budget around that. Once they got real credentials, they found the platforms were completely closed to them, with no partner tier, sandbox or route to the permissions they needed.

Why are film industry platforms so tightly locked down?

Scripts, unreleased footage, cast details and locations all leak, and the platforms serving that industry have been built by people who have spent years dealing with the fallout. The security posture is deliberate rather than accidental, so it is not something a new product with no track record can negotiate away.

What did the team build instead?

They rebuilt how data entered the product entirely, ingesting emails tied to specific roles within a production and processing the data from there. There was no direct connection into any third-party platform, and users never had to think about why it worked that way.

Why is a refused integration worse than a difficult one?

A difficult integration is just a cost, more time, more engineering, more money. A refused integration is a design problem, because the feature that justified the product's existence has to be delivered some other way or dropped altogether.

What is the practical lesson about access promised on a call?

Access described verbally and access tested with real credentials are two very different things. Until someone has logged in and pulled real data, treat the integration as unproven no matter how confident the conversation sounded.

When should access be verified in a project?

Before the architecture, schedule and budget are drawn around it. The mistake here was letting product design run ahead of the commercial conversation, so verify the technical route early even if the partnership talks are still maturing.

Does using APIs widely make this risk less likely?

Quite the opposite. Because 99% of organisations report using APIs to connect applications and data, access has become a routine assumption, and routine assumptions are exactly the ones nobody bothers to test.

Did the pivot affect the user experience?

No. The email based ingestion route delivered the same outcome, with documents reaching the portal without users needing to understand the mechanism behind it. The cost of the pivot was absorbed by the team rather than passed on to the people using the product.

## Related Articles

[![We Are Affective](https://weareaffective.com/hubfs/we_are_affective_logo_mark.svg)](https://weareaffective.com)

20-22 Wenlock Road  
London, N1 7GU  
United Kingdom

+44 20 4572 8062  
[hello@weareaffective.com](mailto:hello@weareaffective.com)

<https://linkedin.com/company/weareaffective> <https://instagram.com/weareaffective> <https://facebook.com/weareaffective>

Services

[App planning & strategy](https://weareaffective.com/app-planning-strategy) [App design](https://weareaffective.com/app-design-agency) [App UX design](https://weareaffective.com/app-ux-design) [App UI design](https://weareaffective.com/app-ui-design) [App technical architecture](https://weareaffective.com/app-architecture) [Existing app audits](https://weareaffective.com/app-audit)

Legal

[Privacy policy](https://app.termly.io/policy-viewer/policy.html?policyUUID=b8fa9921-7518-4fb5-8ddd-9dc7f5977ed2) [Terms](https://app.termly.io/policy-viewer/policy.html?policyUUID=8b6a6ad5-91bd-4176-a5f7-6d36b0398f70)

Case studies

[TravAI](https://weareaffective.com/case-studies/travai) [Meditech](https://weareaffective.com/case-studies/harley) [WorkingWeight](https://weareaffective.com/case-studies/workingweight) [SkinSync](https://weareaffective.com/case-studies/skinsync) [Three Lochs](https://weareaffective.com/case-studies/three-lochs) [Drift](https://weareaffective.com/case-studies/drift)

About us

[Our Story](https://weareaffective.com/about) [How We Work](https://weareaffective.com/how-we-work)

Guides

[Creating an app](https://weareaffective.com/how-to-create-an-app) [Building an MVP](https://weareaffective.com/building-an-mvp) [Cost and budgeting](https://weareaffective.com/app-development-cost) [App technology](https://weareaffective.com/app-development) [Planning and strategy](https://weareaffective.com/app-planning-strategy) [User research](https://weareaffective.com/app-user-research) [Onboarding design](https://weareaffective.com/app-onboarding-design) [User psychology](https://weareaffective.com/user-psychology-app-design) [Launch and growth](https://weareaffective.com/app-launch-growth)

 Copyright © 2026, weareaffective.com. All rights reserved.