--- title: "Open source libraries: Legal requirements every dev must know" description: Open source licences carry real legal obligations. Learn what copyleft, attribution, patent clauses and commercial restrictions mean for your codebase. image: https://weareaffective.com/hubfs/learning-centre-images/open-source-libraries-legal-requirements-every-dev-must-know.webp --- [Skip to content](https://weareaffective.com/learning-centre/open-source-libraries-legal-requirements-every-dev-must-know#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 # Open source libraries: Legal requirements every dev must know Table of Contents Pull up the dependency list for a typical production app and you will find dozens of open source libraries sitting quietly underneath the code your team actually wrote. Most of them were added in minutes, evaluated on functionality, and merged without anyone reading a licence file. That is normal. It is also how teams end up with legal obligations they did not know they had accepted, obligations that can force rewrites, [block distribution, or expose the business](https://weareaffective.com/learning-centre/going-mobile-7-ways-that-a-mobile-app-will-help-your-business) to litigation. > Open source does not mean free of conditions. Every library carries a legal contract. Open source does not mean free of conditions. Every library carries a licence, and that licence is a legal contract. The conditions vary enormously. Some require almost nothing. Others require you to publish your entire codebase. Some grant you a patent licence that evaporates the moment you file a patent claim of your own. A few prohibit commercial use outright. The gap between knowing a library exists and understanding what its licence actually demands of you is where most compliance failures begin. This article works through the licence families you will encounter, what they demand, and where teams consistently get caught out, covering dependency trees, compatibility conflicts, platform rules, patent clauses, and the practical steps for keeping your codebase clean. The goal is not to make every developer a lawyer. The goal is to make sure no one on your team adds a library without understanding what they are agreeing to. ## How Open Source Licences Actually Work Copyright law, by default, gives the author of a piece of software all rights over it. Without a licence, no one else can legally use, copy, modify, or distribute that code. An open source licence is the author's way of granting those rights to everyone, but almost always with conditions attached. When your project incorporates an open source library, you are accepting those conditions. There is no negotiation and no opt-out. You either comply or you are infringing copyright. The conditions differ by licence but fall into a few recurring patterns. Some licences require you to include a copy of the licence text with any distribution of your software. Some require you to make your source code available. Some restrict commercial use. Some say you cannot use the author's name to endorse your product. Some grant you rights over the author's patents that you would not otherwise have, and then take those rights away if you sue. #### Where the obligation attaches The obligation typically attaches at distribution, meaning when you ship the software to someone else. A library you use only in internal tooling, never distributed outside your organisation, carries a different risk profile from a library bundled into a [consumer app. SaaS products sit](https://weareaffective.com/learning-centre/why-most-business-apps-fail-and-how-your-digital-business-can-avoid-the-same-fat) in an interesting middle ground: you are running the software on your servers and users access it remotely, which some licences treat as distribution and others do not. Knowing exactly when your obligations activate is the first thing to establish for any given dependency. ## The Licence Families You Will Encounter in Production Code Open source licences cluster into a handful of families, and understanding the families matters more than memorising individual licences. The two main families are permissive and copyleft, with several important subdivisions within each. Permissive licences place minimal conditions on use and distribution. The MIT licence, the BSD licences (two-clause and three-clause), and the Apache 2.0 licence are the most common. They generally require attribution and licence notice preservation, and little else. You can incorporate permissive-licensed code into a proprietary product and ship it without publishing your own source. #### The copyleft family Copyleft licences require that derivative works be distributed under the same licence, or a compatible one. The GNU General Public Licence (GPL) and its variants are the canonical examples. The GPL comes in version 2 (GPLv2) and version 3 (GPLv3), and they are not interchangeable. The GNU Lesser General Public Licence (LGPL) is a weaker form that applies copyleft only to the library itself, not necessarily to code that links against it. The GNU Affero General Public Licence (AGPL) extends the GPL's reach to cover network use, closing the SaaS loophole. The Mozilla Public Licence (MPL) is a file-level copyleft that sits between permissive and full copyleft in its demands. | Licence | Attribution required | Source disclosure | Copyleft scope | | --- | --- | --- | --- | | MIT | Yes | No | None | | Apache 2.0 | Yes | No | None | | LGPL | Yes | Library only | Library-level | | MPL 2.0 | Yes | Modified files | File-level | | GPL v2/v3 | Yes | Full program | Full program | | AGPL | Yes | Full program + network | Full program + SaaS | ## The design layer your *developers* need We deliver complete UX/UI design and technical specifications your development team can build from immediately. No guesswork, no back and forth, no mid-project surprises. [See how we work](https://weareaffective.com/how-we-work) [Get started](https://weareaffective.com/get-started) No commitment ## Copyleft Obligations and What They Demand of Your Codebase Copyleft is the mechanism that makes open source spread. The logic is that if you benefit from free software, the software ecosystem benefits if you contribute back. In practice, copyleft obligations can be an unwelcome surprise for teams building proprietary products. GPL requires that if you distribute a work that incorporates GPL-licensed code, you must distribute the complete corresponding source code under the GPL as well. "Distribute" here means giving the software to another party, including shipping a product to customers. The source code you must provide covers your entire linked program. For a commercial product whose value lies in its proprietary code, that obligation can effectively prevent you from using a GPL library at all. > Copyleft obligations can reach your entire linked program, not just the library itself. LGPL softens this for dynamic linking. If your code links against an LGPL library dynamically, and a user could swap out the library for a modified version, the copyleft generally does not reach your surrounding code. Static linking is murkier territory, and legal opinion varies. If you statically link an LGPL library into your app, seek proper legal advice before assuming you are clear. AGPL extends GPL to cover software accessed over a network. If you run an AGPL-licensed server component and users interact with it remotely, you must provide the source. This closes the loophole that allowed companies to use GPL code in SaaS products without releasing source, because technically they were never distributing the software to users. Check every GPL and AGPL dependency before it enters production. If a library carries one of these licences, your team needs to decide whether dynamic linking is viable, whether a commercial licence exists, or whether a different library should be used entirely. ## Permissive Licences Are Not Obligation-Free Permissive licences are the most business-friendly family, but treating them as obligation-free is a mistake that causes real problems at distribution time. MIT, BSD, and Apache 2.0 all carry at least some requirements, and failing to meet them is still a licence violation. MIT requires you to include the original copyright notice and the full MIT licence text with any distribution of the software. This means in your compiled app, in your documentation, in any package you ship, there needs to be a copy of every MIT licence from every MIT-licensed library you include. For a typical mobile app, that list can run to hundreds of entries. The obligation is real even if it is rarely enforced aggressively. #### Apache 2.0 and the notice file Apache 2.0 adds a requirement to preserve any NOTICE file that the original project includes, and to include attribution in your own NOTICE file if you distribute the software. It also explicitly grants patent rights from contributors to users, which is one reason Apache 2.0 is popular in commercial contexts. The three-clause BSD licence adds a non-endorsement clause: you cannot use the names of the project or its contributors to promote your own product without written permission. That sounds minor, but press releases and marketing copy occasionally trip over it. The practical consequence is that every build you ship to users needs a complete, accurate set of attribution notices for every dependency. This is not onerous if you have tooling to generate it. Without tooling, maintaining it by hand across a dependency tree of any size is error-prone and typically incomplete. Generate your attribution and licence notice file automatically as part of your build pipeline. Tools like FOSSA, Scancode, or the licence-checker npm package can produce the full list from your dependency manifest. Do this once and keep it running on every build. ## When API Choice Is a Compliance Decision The licence on a library is not the only legal consideration attached to a third-party integration. Platform terms of service and API usage policies carry their own obligations, and in our experience, teams treat these as technical questions when they are actually legal ones. On a proof-of-concept project for a company [building an app to share memories](https://weareaffective.com/app-development) with audio attached, we initially looked at integrating with Spotify for short audio clips. Spotify lacked a robust API for clips, and users would have needed a Spotify account, which eroded the user experience. We switched to Deezer, which had a robust API, supported clips, and did not require users to be logged in. The technical route became simpler as a result. Working with Spotify without a proper API would have required significant workarounds and custom-built technical solutions to stay within Spotify's rules. Using Deezer's official API in the way Deezer intended meant we were fully compliant without any of those workarounds, simplifying both the architecture and the compliance burden. A secondary benefit emerged too: when users wanted to hear a full track, there was a natural upsell to a Deezer subscription, creating affiliate referral revenue alongside the product itself. The lesson here is that the right API choice and the compliant API choice are often the same choice. Fighting the architecture to stay within a platform's terms of service usually signals that you are using the platform in a way it was not designed for, and that carries risk regardless of whether you are technically inside the rules. ## Dependency Trees and the Licences You Did Not Know You Accepted When your project adds a library, it also adds every library that library depends on, and every library those depend on. A dependency tree for a modern JavaScript project can contain several hundred packages. Each one carries a licence. Most developers are aware of the libraries they chose directly. Almost no one checks the transitive dependencies. This matters because a GPL-licensed package three levels deep in your dependency tree carries the same obligations as one you added deliberately. The fact that you did not know it was there is not a defence. Your package manager installed it, your build included it, and if you distribute your software, you are distributing that GPL code. The obligation attached the moment it entered your build. #### How transitive dependencies get missed The way this usually goes wrong is through an indirect dependency update. A library you depend on releases a new version that adds its own new dependency. Your automated dependency updates pull in the new version. Three months later, someone does a licence audit and finds a copyleft library that has been shipping in production since the update. According to [Veracode's survey of 2,000 developers](https://beta.darkreading.com/application-security/79-of-third-party-libraries-in-apps-are-never-updated), 63% of respondents said they always look at licensing when evaluating a new third-party library. The figure does not extend to transitive dependencies, which is where the real exposure tends to sit. Checking the direct libraries you add is the minimum. Checking the full tree, and re-checking it after dependency updates, is the actual requirement. ## Attribution, Notices, and Distribution Requirements Attribution is the one obligation that runs across nearly every open source licence. Even the most permissive licences expect you to preserve copyright notices and include the licence text. The question is not whether you need to do this but how, and where, and for which licences. For mobile apps, the standard practice is an in-app licences screen, typically in settings or an about section, listing every open source component, its version, its copyright holder, and its licence text. Both Apple and Google's app store guidelines expect this for apps that use open source libraries. It is not prominently enforced at review, but it is a contractual obligation under the library licences themselves. #### What distribution actually triggers For web apps and server software, the picture is more varied. A compiled JavaScript bundle served to a browser is a distribution, and the attribution obligations of any included libraries apply. A server-side component that users never receive directly sits in a different position, though AGPL-licensed components change that calculation as noted earlier. Binary distributions of desktop apps need complete attribution just as mobile apps do. GPL additionally requires that you provide, or offer to provide, the complete corresponding source code. For mobile apps, this means making the source available at no charge, typically for at least three years. Shipping a GPL-licensed component in a compiled app without making source available is a violation, full stop. There is no workaround that preserves the GPL library and avoids the source disclosure requirement. ## Licence Compatibility: When Two Libraries Cannot Legally Coexist Licence compatibility is the question of whether two differently-licensed libraries can legally sit in the same distributed work. Two permissive licences are almost always compatible with each other. A permissive licence and a copyleft licence may or may not be compatible, depending on the specifics. Two copyleft licences from different families often are not compatible at all. The canonical incompatibility is GPLv2 and Apache 2.0. Apache 2.0 includes conditions, specifically patent retaliation clauses, that are not present in GPLv2. Including both in a single GPLv2-licensed work is a conflict the Free Software Foundation has formally identified. GPLv3 was partly written to resolve this by including its own patent provisions, making GPLv3 and Apache 2.0 compatible. But GPLv2 and GPLv3 are themselves incompatible in one direction: you can use GPLv2 code in a GPLv3 work only if the GPLv2 code was released as "GPLv2 or later." The practical consequence is that a product combining libraries from incompatible licence families cannot legally be distributed in its combined form. The fix is to find an alternative library with a compatible licence, seek a commercial licence from the library author, or restructure the architecture so the incompatible components are not combined in the same distributed work. None of these are quick fixes discovered the week before launch. Check licence compatibility when you add any copyleft dependency, not just at audit time. If your project already contains a GPL library, every new addition needs to be checked against it for compatibility before it is merged. ## Commercial Restrictions and the Clauses That Catch Teams Out Some licences prohibit commercial use explicitly. The Creative Commons NonCommercial variants are well known examples, though they are more common on content than on software. Less well known are licences that describe themselves as open source but include clauses restricting commercial use, clauses that the Open Source Initiative does not consider compliant with the open source definition. The Business Source Licence (BSL or BUSL) is one example. It allows free use up to a specified limit, such as a number of production servers or a revenue threshold, with a condition that the software converts to a fully open source licence after a set period, typically four years. Some teams have added BSL-licensed libraries without noticing the commercial use restriction and only discovered the problem when the product scaled past the free tier. #### Commons Clause and similar additions The Commons Clause is an addendum that has been attached to permissive licences like Apache 2.0 by some projects. It restricts selling the software itself or a product whose primary value is the software. A library released under "Apache 2.0 with Commons Clause" is not straightforwardly permissive, and teams treating it as such have added a commercial restriction to their stack without realising it. The Server Side Public Licence (SSPL), created by MongoDB, extends copyleft so far that offering the software as a service triggers a requirement to release the source of the entire service stack, including operational infrastructure. For most SaaS businesses, that obligation is not compatible with a proprietary model. ## Patent Grants and Termination Clauses Patent law and copyright law are separate, and most older open source licences address only copyright. This creates a risk: a contributor to an open source project might hold patents that the project's code necessarily infringes, and without an explicit patent grant in the licence, using the library is copyright-compliant but potentially patent-infringing. Apache 2.0 addresses this with an explicit patent grant. Contributors to Apache 2.0 projects grant users a licence to any patents they hold that are necessarily infringed by the contribution. This is one reason Apache 2.0 became the preferred licence for commercial open source. GPL version 3 similarly includes patent provisions. #### Termination clauses and what triggers them Both Apache 2.0 and GPLv3 include patent termination clauses. Under Apache 2.0, if you initiate patent litigation against any contributor or user of the project, claiming that the project infringes your patents, your licence to use the project terminates automatically. You lose the right to use the library. Under GPLv3 the mechanism is similar. The practical implication is that a company whose legal strategy includes aggressive patent litigation may find that strategy incompatible with using certain open source libraries, because initiating a patent claim would strip them of the rights they need to ship their product. This is not a theoretical risk for companies operating in patent-heavy sectors. ## When Platform Rules Add Another Layer of Legal Obligation Publishing to the Apple App Store or Google Play adds another layer of obligations that sit on top of your library licences and interact with them in non-obvious ways. Both platforms have distribution agreements that restrict what you can include in a submitted app, and those restrictions can conflict with certain open source licences. Apple's App Store terms have historically been considered incompatible with GPLv2. Apple's standard app distribution terms impose usage restrictions on downloaded apps, such as limiting installs to authorised devices. The GPL forbids imposing further restrictions on users' rights beyond what the GPL itself requires. Apple's distribution restrictions are arguably "further restrictions" of that kind, making a GPLv2-licensed library incompatible with App Store distribution. The FSF has held this position. Some GPLv2 projects include an App Store exception in their licence to address it. > Platform distribution agreements can conflict with open source licences, turning a routine submission into a violation. We saw the practical weight of platform rules on a peer-to-peer currency exchange product we built, where users could exchange leftover foreign currency with other travellers at interbank rates. We built the core transfer mechanism well but did not factor in anti-money laundering requirements. Apple flagged the product as a potential vehicle for money laundering due to its unlimited transfer capability. We had to retrofit several layers of compliance: more stringent KYC checks, enhanced transfer security, and hard limits on the number of transfers between any two parties. Platform [compliance is not a final-step checklist](https://weareaffective.com/learning-centre/how-much-should-i-actually-spend-on-strategy-before-i-start-building). It shapes architecture from the start. ## Retrofitting Compliance Is Expensive The cost of discovering a compliance problem after a product is built is almost always higher than the cost of getting it right during development. This applies to licence compliance as much as it applies to any other form of legal or regulatory compliance. Research from Globalscape found the cost of non-compliance is [nearly three times the cost of compliance](https://www.globalscape.com/resources/whitepapers/data-protection-regulations-study). The figure covers regulatory compliance broadly, but the dynamic maps directly onto open source licence problems. The currency exchange project is one illustration. We had to go back through a shipped product and rebuild significant portions of it to meet compliance requirements that should have been part of the original design. The retrofit cost time, budget, and in that case contributed to the client eventually running out of funds and abandoning the product. #### What retrofit actually looks like A copyleft compliance problem discovered late might require replacing a library with an alternative, which means finding a compatible replacement, migrating the integration, retesting, and re-auditing. If the library is deeply embedded, the migration can touch large portions of the codebase. Attribution failures require generating and distributing corrected notice files to anyone who received the non-compliant version. A GPL violation that has been distributing proprietary source without disclosure is a live infringement claim until it is resolved, and resolving it may require releasing code the business considers proprietary. The sports club app project we worked on is a different kind of illustration. We warned the client early on that the budget would spiral out of control and they risked exhausting funding before launching anything. Those warnings went unheeded. What should have reached market in three to four months [never launched after twelve to fourteen months](https://weareaffective.com/learning-centre/what-scope-creep-actually-costs-a-sports-club-app-that-spent-twelve-months-growi), and the budget nearly doubled. Ignoring professional advice has a cost that compounds over time, and licence compliance is no different: address it while the code is new or pay more to address it later. ## Conducting a Licence Audit Before You Ship A licence audit before a major release is the minimum checkpoint for any product that will be distributed to users. The goal is a complete map of every licence in the dependency tree, with each one checked against your distribution model, your other dependencies, and your platform requirements. The process works in steps. 1. Generate a full dependency manifest, including transitive dependencies, using your package manager's lock file. 2. Run a licence detection tool across the manifest to identify the licence for each package. 3. Flag any copyleft licences (GPL, AGPL, LGPL, MPL) and any licences with commercial restrictions. 4. Check flagged licences for compatibility with each other and with your distribution model. 5. Check platform-specific restrictions against any GPL-family licences. 6. Verify that attribution obligations can be met for every permissive licence in the tree. 7. Produce a licence notice file for inclusion in the distributed product. Any library that cannot be resolved to a compliant state needs a decision: find an alternative, obtain a commercial licence from the author, or restructure the architecture. Document the outcome for every flagged library. The documentation is useful both for internal sign-off and for due diligence if the business is ever acquired or audited. ## Tooling for Ongoing Licence Management A one-time audit before launch is necessary but not sufficient. Dependencies update. New packages get added. A library that was MIT-licensed when you added it may relicence under different terms in a future major version. Ongoing licence management requires tooling integrated into your development workflow, running automatically rather than depending on someone remembering to check. Several tools address this at different points in the pipeline. FOSSA integrates with version control and CI systems, scanning every commit for licence changes and flagging issues before they reach production. It maintains a licence policy that can block merges containing prohibited licences. Scancode is an open source scanner that identifies licences from source code as well as manifests, useful when a package's declared licence does not match the actual licence text in the code. The npm licence-checker, pip-licenses for Python, and go-licenses for Go are lighter-weight tools that generate licence reports from package manifests without full source scanning. #### Embedding licence checks in CI The practical setup is to run licence scanning on every pull request that changes dependencies, with a policy file that lists permitted licences, licences requiring review, and prohibited licences. The pipeline fails automatically on a prohibited licence, requiring a deliberate decision before the dependency can be merged. This puts the licence question at the point of adding the dependency, where it is cheapest to address, rather than at audit time, when the library is already embedded in the product. On the performance coaching survey app, we used iOS's built-in libraries to handle QR code generation entirely within the native app, meaning nothing was stored externally. The compliance benefit was direct: using platform-native libraries meant no third-party licence obligations for that functionality at all. Where platform-native options exist, they are worth considering precisely because they eliminate the licence question along with the dependency. ## Conclusion Licence compliance is not a legal team problem that arrives after the engineers have finished. It is a development problem that starts with the first dependency and continues through every update, every new library, and every platform submission. The obligations are real, they differ significantly by licence family, and they interact with each other and with platform rules in ways that require deliberate attention rather than assumptions. The pattern we see across projects is consistent. Teams who check licences at the point of adding a dependency spend almost no time on compliance overall. Teams who defer that check to audit time spend [a great deal of time on it](https://weareaffective.com/learning-centre/5-things-that-make-the-difference-between-so-so-apps-and-stellar-apps-what-your-), often under pressure, often discovering problems that require architectural changes. The anonymous messaging app we built required [authentication upfront because the legal requirements](https://weareaffective.com/learning-centre/what-curiosity-looks-like-in-a-first-session-and-why-most-products-design-past-i) of the product demanded it, not because it was the easiest UX choice. The alcohol buying and selling platform project, where embedding web elements instead of building a proper API layer added approximately 20% uplift in work across the project, shows how a technical shortcut taken to avoid a compliance question costs more than the compliance would have. On the peer-to-peer currency exchange product, retrofitting AML compliance after Apple rejected the app cost far more than designing for it from the start would have. The direction of travel is always the same: address the requirement early, or pay more later. A clean dependency tree, correct attribution, and a licence policy running in your CI pipeline are achievable with a modest investment of time. They protect the business, protect the product, and remove a class of late-stage surprises that have derailed more than a few otherwise well-built products. [Let's talk about your licence compliance strategy](https://weareaffective.com/get-started) ## Frequently Asked Questions Do I have legal obligations when I use an open source library? Yes, every open source library comes with a licence that functions as a legal contract. When you incorporate a library into your project, you are accepting its conditions whether you have read them or not, and failing to comply means you are infringing copyright. What is the difference between permissive and copyleft licences? Permissive licences such as MIT, BSD, and Apache 2.0 place minimal conditions on how you use and distribute the code. Copyleft licences impose stricter requirements, and in some cases they can require you to publish your entire codebase if you distribute software that includes them. When do my licence obligations actually begin? Obligations typically attach at the point of distribution, meaning when you ship the software to someone outside your organisation. Internal tooling that never leaves the company carries a different risk profile from a library bundled into a consumer app or mobile product. Does using a library in a SaaS product count as distribution? This depends on the specific licence, as SaaS sits in a middle ground where users access software remotely rather than receiving a copy of it. Some licences treat remote access as distribution and others do not, so you need to check the terms of each dependency used in your SaaS application. What are patent clauses in open source licences and why do they matter? Some licences, such as Apache 2.0, grant you rights over the author's patents that you would not otherwise have. These rights can be revoked automatically if you file a patent claim against the author, which is an important commercial consideration for businesses that are active in patent litigation. Can open source libraries be used for commercial purposes? It depends on the licence. Some licences permit commercial use with minimal restrictions, whilst others prohibit it outright. Checking for commercial use restrictions before adding a dependency is essential, particularly for any product generating revenue. Why is it risky to add libraries without reading the licence file? Adding a library without reviewing its licence means you may be accepting legal obligations without realising it. These obligations can range from including licence text in your distribution to being required to open source your entire codebase, and discovering them late can force costly rewrites or block product releases. Do I need to check the licences of indirect dependencies as well as direct ones? Yes, your legal obligations extend to the full dependency tree, not just the libraries your team added directly. A library you chose may itself depend on others with stricter licence terms, so auditing the entire tree is necessary to understand your compliance position accurately. ## 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) 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.