How Do Developers Protect Apps During Building?

Building an app is an act of optimism. You have an idea, a team, and a budget, and the assumption is that if you build it well enough, everything else will fall into place. What rarely gets discussed at the start of a project is the layer of legal, structural, and technical decisions that sit beneath the product itself, the ones that determine who owns what, who is liable for what, and whether the app can even be deployed without going back to square one.

The decisions that are hardest to retrofit are the ones nobody asked about at the start.

We have seen what happens when those decisions are deferred. On a peer-to-peer currency exchange product we built, where travellers could swap leftover foreign currency at interbank rates, the core transfer mechanism worked well. What we had not factored in was anti-money laundering compliance. Apple flagged the product as a potential vehicle for money laundering because of its unlimited transfer capability, and we had to go back and retrofit Know Your Customer checks, enhanced transfer security, and hard limits on the number of transfers between any two parties. The work was real, the cost was real, and the delay was entirely avoidable if the compliance question had been asked before a line was written.

That project shaped how we approach protection during a build. The questions below cover the areas that matter most, and they are worth asking before the first sprint begins.

Who Owns the Code When the Build Is Done?

Intellectual property is the question that causes the most confusion after a project ends. When a client hires an external development team, there is a natural assumption that the client owns everything produced. That assumption is often wrong, and the contract is the only thing that makes it right.

In most jurisdictions, the default position is that the creator owns the copyright in the work they produce, unless a contract says otherwise. A developer or agency that writes code on your behalf retains intellectual property rights over that code unless those rights are explicitly assigned to you in writing. A statement in a proposal saying "the client owns the deliverables" is not assignment. Proper IP assignment is a specific legal clause in the contract, confirmed at the point of project completion.

What to ask before signing

Confirm whether the contract assigns all IP on delivery or on final payment. Some contracts assign IP only once the full fee is paid, which means a disputed invoice can leave you without clear ownership of a product you have been using for months. Check whether any pre-existing code, frameworks, or proprietary tools used by the developer are excluded from the assignment, and whether you get a licence to use them even if they are not transferred.

Work for hire versus assignment

Some contracts describe the work as "work for hire", which in certain legal frameworks means ownership rests with the commissioning party from the start. Others use a formal assignment clause that transfers rights on a specific date or condition. Neither approach is inherently better, but both need to be explicit. Vague language about "ownership" without specifying what is owned and when it transfers is a dispute waiting to happen.

What the Contract Should Say Before a Line Is Written

A contract that describes the finished product without addressing what happens when things go wrong is only half a contract. The parts that matter most to protecting both sides are the parts that cover process, not just outcome.

Scope definition is the first of these. A contract should describe what will be built, what is explicitly excluded, and what happens when a client wants to add something after sign-off. Without a clear change control clause, scope creep is inevitable and budget erosion follows. On a fitness and wellness product we worked on, the clients repeatedly approved designs and then walked back that approval when building began, claiming they had not understood what they were signing off on. Despite clear warnings from us that budget was being wasted on design iterations that would not materially improve the product, the cycle continued, and the project ended at the design and research stage with the budget fully spent and nothing built.

The contract could not force the clients to make decisions, but a tighter scope definition and change control process would have created a clearer paper trail when approvals were disputed.

Clauses worth including

• A definition of what constitutes a change request and how it is priced
• Sign-off procedures that require written confirmation from an authorised decision-maker
• A payment schedule tied to deliverable milestones, not just time
• Liability limits, particularly around third-party integrations and platform decisions
• A clause specifying what happens to work completed if the project is paused or terminated

Ask for a named point of contact with sign-off authority on the client side before the contract is signed. If no single person has that authority, decisions will be made by committee and approvals will be contested later.

Third-Party Code, Libraries and Licences

Almost every app built today relies on third-party libraries. These are blocks of pre-written code that handle common functions, things like authentication, payments, maps, or image processing, that would take significant time to build from scratch. Using existing code reduces development cost by 20-30% compared to building everything from scratch, according to Appinventiv, and the time saving is real. But the licence attached to that code matters as much as the functionality.

Open-source libraries come with licence conditions that vary considerably. Some, like MIT or Apache 2.0 licences, are permissive and allow commercial use with few restrictions. Others, like the GPL family, require that any product incorporating the code also be released as open source. Using a GPL-licensed library inside a proprietary commercial app without understanding that condition can mean the app itself becomes subject to open-source disclosure requirements, which is rarely what a commercial client intends.

Developers check functionality first and security last when selecting third-party libraries.

According to Veracode's survey of 2,000 developers, 67% always consider functionality when evaluating a new library, 63% always check licensing, and only 52% always consider security. The gap between those three numbers is where risk lives.

Updates and vulnerability windows

A library that is not updated carries whatever vulnerabilities it shipped with. The same Veracode research found that even in actively maintained repositories, libraries are added but never updated 73% of the time. The fix is often simple: 69% of vulnerabilities in third-party libraries involve only a minor patch that would rarely cause breakage. The problem is that without a defined process for monitoring and updating dependencies, those patches never get applied.

Ask your development partner for a software bill of materials at the end of the project, a list of every third-party library used, its version, and its licence type. This is a document you should own and keep updated.

Why Integration Assumptions Are a Hidden Risk

Integrations are where build projects most often encounter problems that nobody anticipated and nobody budgeted for. Two systems that should talk to each other often cannot, and the reasons are rarely obvious until someone actually tries to connect them.

On a buying and selling platform for bottles of alcohol, similar in concept to wine trading, we had already begun building the mobile product when we discovered we could not implement the planned API layer. The client's existing web application had been built by a previous developer in a way that made it too complex to expose cleanly via an API. We ended up having to embed web elements from the existing site directly into the mobile product rather than building a proper native integration. That approach was not as scalable or as robust as we would have liked, but it was the only option available given how the underlying system had been constructed.

The cost of a forced pivot

The workaround added approximately 20% uplift in work across the entire length of the project. Because the client wanted to maintain the original budget, we had to drop features towards the end to compensate. The client did not get a worse product because of anything done badly during the build. They got a constrained product because of a decision made by a previous developer, on a system that predated the mobile project entirely.

We encountered a similar situation on a production management tool for the motion picture industry. We expected to integrate directly with existing platforms used for storing production documents. When we finally gained access to those systems, they were far more locked down than anticipated. We pivoted to ingesting emails tied to specific roles within a production to process data indirectly, without a direct API connection. The challenge, as with the alcohol platform, was making the workaround feel natural to users rather than like an unnecessary extra step.

Before the build begins, request API documentation from any third-party system the product needs to connect to, and test access in a sandbox environment. An assumption about API availability that turns out to be wrong mid-build is expensive to fix.

Security Architecture: Decisions That Cannot Be Retrofitted

Security is cheapest when it is built in and most expensive when it is added afterwards. The architecture decisions made in the first weeks of a project, around data storage, authentication, encryption, and access control, set the boundaries of what is possible later. Changing them after the product is built is often equivalent to demolishing and rebuilding part of the structure.

Authentication is a good example. A product built with simple username and password authentication can have two-factor authentication added later, but doing so requires changes across multiple parts of the system, from the database schema to the front-end flows to any existing user records. If the product was designed from the start to support multi-factor authentication, the additional layer is a configuration choice. If it was, it is a rebuild.

Where credentials get exposed

One of the most common security failures is an API key or database credential left in a code repository. According to Serverion, 61% of organisations have accidentally exposed secrets such as API keys in public repositories. The fix is a combination of tooling and process: secrets management systems, environment variable handling, and pre-commit hooks that scan for exposed credentials before code is pushed. None of these are complex to implement when planned from the start. All of them are disruptive to retrofit.

Access control and privilege

Role-based access control, which determines what different users can see and do within a system, is another decision that shapes the entire product. Defining roles and permissions at the architecture stage means the product is built around them. Defining them after the product is built means every feature that touches user data may need to be reviewed and amended.

Compliance Requirements That Must Be Scoped Before Development

Compliance is not a layer you add to a finished product. The regulations that govern what data you can collect, how you can use it, how long you can keep it, and who you must notify if it is breached all have structural implications for how the product is built. Treating them as a checklist at the end of a project is how compliance failures happen.

The peer-to-peer currency exchange product we built is the clearest example of this we have seen directly. The core functionality worked. The product did exactly what it was designed to do. The compliance gap, specifically the absence of anti-money laundering controls, was not something that emerged from a flaw in the build. It emerged from a question that was not asked during scoping. The KYC checks, enhanced transfer security, and transfer limits that Apple required were all technically straightforward. Adding them after the fact, under pressure, with a delayed launch, was the expensive version of a conversation that should have happened in week one.

Regulations worth scoping early

The specific regulations relevant to a product depend on its sector, geography, and the nature of the data it handles. But some appear across many categories of product and are worth raising as explicit scoping questions.

• GDPR and equivalent data protection laws, if the product handles personal data
• AML and financial services regulations, if the product involves money movement
• Health data regulations such as HIPAA in the US or equivalent frameworks, if the product handles medical information
• Children's privacy laws such as COPPA or the UK's Children's Code, if the product is accessible to under-18s
• App store guidelines from Apple and Google, which carry their own content and functionality requirements

App store guidelines deserve particular attention because they operate as a final gate between a finished product and its users. Apple and Google can reject or remove an app for compliance failures, and their requirements are not always predictable from the product specification alone.

Data Retention, GDPR and the Right to Erasure

GDPR gives users the right to request that their personal data be deleted. That right is real and enforceable, and a product that cannot honour it is non-compliant. But the right to erasure is not absolute, and the tension between it and other legal obligations is something that needs to be resolved before the data architecture is built, not after.

On an anonymous messaging app we worked on, we had to address exactly this tension. GDPR requires that user data be removed on request. But anonymous messaging platforms carry a distinct risk of misuse, including bullying and the sending of inappropriate content, and if a user deletes their account after sending harmful messages, the data trail needed for any potential investigation disappears with it. The legal obligation to retain data for law enforcement purposes pulls in the opposite direction from the GDPR obligation to delete it on request.

How we resolved it

We implemented a data retention policy of approximately six months on that product. A user who deletes their account does not have their data immediately wiped. It is retained for a defined period, after which it is deleted in the normal course. If a police investigation requires access to that data within the retention window, it is available. After the window closes, it is gone. The policy does not fully satisfy either obligation in isolation, but it represents a proportionate and legally defensible position between the two.

This kind of decision cannot be made properly during a build sprint. It requires legal input, a clear understanding of the product's risk profile, and a data architecture that supports the chosen retention approach from the start. Building a product that stores data in a way that makes selective retention or deletion difficult is building a compliance problem.

In-App Safety and Reporting Structures

Safety features within a product are often treated as a secondary consideration, something to add once the core functionality is proven. That framing underestimates how structurally important safety is to products where user interaction carries inherent risk.

On the same anonymous messaging app, we added in-product reporting features that allowed users to escalate concerns about inappropriate or bullying messages directly to the client's admin team. This was not part of the original specification. It emerged as we got deeper into the project and began examining the safety implications of anonymous communication at scale. The reporting structure gave users a way to flag content without exposing their own identity, which mattered because the anonymity of the platform was its core feature and also its core risk.

What a reporting structure needs to do

A reporting feature is only as useful as what happens when it is triggered. The technical implementation is straightforward: a flag button, a category selection, a submission to an admin queue. The harder question is what the admin team does with that queue, how quickly they can review reports, and what actions are available to them. Building a reporting structure without designing the moderation workflow that sits behind it is building the appearance of safety rather than the substance of it.

Products that involve user-generated content, peer-to-peer communication, or communities of any kind need to treat safety architecture the same way they treat security architecture: as a structural decision that shapes the product from the start, with implications for the admin system, the data model, and the user interface.

Red Flags in a Spec or Contract

A well-written specification should describe what the product needs to do, how success will be measured, and what constraints the build must operate within. A poorly written one describes features without context, omits ownership and liability questions, and leaves the boundaries of the project undefined. The difference matters, and it is usually visible before the contract is signed.

The absence of these elements from a spec or contract is rarely malicious. It usually reflects inexperience or an optimistic assumption that things will work out. But an agreement that does not address what happens when things go wrong offers no protection when they do.

How to Protect Yourself When Working With an External Development Partner

Working with an external development team is a relationship that carries real dependencies. The code they write, the architectural decisions they make, and the tools and libraries they choose become part of your product. Protecting yourself means maintaining enough visibility into those decisions to understand what you are inheriting.

The most common failure mode is a client who treats a development partner as a black box: briefs go in, a product comes out, and everything in between is opaque. That approach works until something goes wrong and the client has no way to evaluate what happened, whether the decisions made were sound, or how to instruct another developer to pick up where the last one left off.

Maintaining access and documentation

1. Ensure the code repository is in an account you own, not the developer's. At the end of any project, you should be able to hand access to a new team without needing the previous developer's cooperation.
2. Request regular documentation of architectural decisions, particularly integrations, data structures, and security choices. This does not need to be elaborate; a brief written record of why something was built the way it was is enough.
3. Maintain admin access to all third-party services, app store accounts, cloud hosting, and payment platforms from the start. Never allow a developer to be the sole account holder for services the product depends on.
4. Run regular reviews against the original specification. A project that has drifted from scope without formal change control is accumulating hidden cost and risk.

A note on the bootstrap constraint

On a bootstrapped social football platform we worked on, scope expanded throughout the build because one of the client's own team members was driving design changes without accounting for their development cost. Midway through the project, we paused Android development entirely and reallocated the remaining budget to the iOS product. The client launched iOS-only, which addressed roughly half the potential market.

Because the target audience skewed younger and disproportionately towards Android, day-one adoption was half of what it could have been. The client subsequently had to introduce advertising and abandon their subscription model because the user base was too small to make subscriptions viable. Earlier visibility into the cost of those design decisions would have allowed a different choice to be made before it became unavoidable.

Conclusion

The decisions that shape how protected an app is are mostly made before the build begins. IP assignment, compliance scoping, integration testing, security architecture, data retention policies, and safety structures are all cheaper to design from the start than to retrofit once a product is live or under review.

The currency exchange product that needed AML compliance added after Apple's review, the alcohol platform that lost 20% of its budget to an integration workaround, the anonymous messaging app that needed a six-month data retention policy to balance GDPR against law enforcement obligations: in each case, the protection question was real, the answer was findable, and the cost of asking it late was substantially higher than asking it early would have been.

Protection during a build is part of building well. The scoping conversations, the contract clauses, the compliance questions, and the integration tests are the same work that produces a product worth protecting.

If you are planning a build and want to work through these questions before development starts, let's talk about your project.

Frequently Asked Questions