The Push for European Sovereign Cloud: A Practical Guide for SaaS Founders in Europe

Direct answer: European sovereign cloud initiatives are accelerating because the EU wants critical data and workloads to run on infrastructure that isn't ultimately controlled by non-EU hyperscalers. For SaaS founders selling into Europe, this means data residency, hosting choices, and vendor lock-in are moving from a compliance footnote to a procurement gate that can decide whether a deal closes at all.

Through 2026, European digital sovereignty reporting has tracked a steady acceleration in sovereign cloud initiatives across the bloc, as EU governments and large enterprises work to reduce their structural dependence on non-EU hyperscale cloud providers. The pattern is consistent across the reporting: national and EU-level programs pushing for data to be stored and processed within European jurisdiction, under European legal control, with EU-based providers or EU-compliant deployment options positioned as the safer procurement choice. This isn't a single new law or a single new platform — it's a directional shift in how European public sector bodies, regulated industries, and increasingly mainstream enterprises evaluate any vendor that touches their data. A precise figure for how many procurement processes now include a sovereignty requirement isn't publicly available in this reporting, so it's worth reasoning from the trend itself rather than a number: when governments start funding sovereign cloud infrastructure and writing sovereignty language into public tenders, private-sector buyers who sell to or partner with those governments tend to adopt similar language in their own vendor requirements within a couple of procurement cycles. For a SaaS founder building a product that will be sold, resold, or embedded into European customers' workflows, that ripple effect is the part worth planning for now, not after a deal stalls on a data-residency question you weren't ready to answer.

What "European sovereign cloud" actually means right now

Sovereign cloud isn't a single technical standard — it's a bundle of related asks that keep showing up together in European buyer conversations. In practice, when a European enterprise or public-sector prospect raises sovereignty, they're usually pointing at some combination of: where the data physically sits, which legal jurisdiction governs access to it, whether a non-EU parent company (or a foreign government via legal process) could compel access to that data, and whether the operational staff and support functions touching the infrastructure are themselves EU-based.

The trend is real because it's backed by policy money and institutional pressure, not just marketing language from cloud vendors. European governments have been funding sovereign cloud programs and encouraging public bodies to prefer EU-controlled infrastructure, and that preference is starting to show up in how large European enterprises write their own vendor requirements — because enterprises that sell to government, or operate in regulated sectors like finance, healthcare, and critical infrastructure, inherit similar expectations from their own customers and regulators. None of this means non-EU cloud providers are disappearing from Europe. It means the default assumption in a growing share of European deals is shifting from "any major cloud provider is fine" to "show us exactly where our data lives, who can access it, and under what legal authority."

This shift is also visible in how European buyers talk about vendor risk more broadly. Where a few years ago a security questionnaire might ask generically about "data protection measures," a growing number now ask pointed questions about cloud provider ownership structure, the specific legal frameworks that could compel data disclosure, and whether a vendor has a documented plan for regional data separation even if it isn't fully implemented yet. That last point matters for smaller SaaS companies: buyers increasingly accept a credible roadmap as a starting point, provided it's specific and the vendor can speak to it with confidence rather than vague reassurance.

Why this is different from GDPR-era compliance conversations

GDPR trained European buyers to ask about data processing agreements and cross-border transfer mechanisms. Sovereign cloud asks a sharper question: not just "is this legally compliant," but "is this infrastructure structurally dependent on a jurisdiction outside our control." That's a harder question for a SaaS vendor to answer with a policy document alone — it increasingly requires an actual architectural answer about where workloads run and what your hosting stack looks like.

It also shifts who inside a prospect's organization asks the question. GDPR-era due diligence was often handled by a legal or privacy team reviewing a data processing agreement template against a checklist. Sovereignty questions increasingly come from a security or IT procurement function that wants an actual architecture diagram, a subprocessor list with regions attached, and sometimes a short technical call with your engineering team before sign-off. That's a different kind of scrutiny, and it rewards founders who've already done the underlying homework rather than founders who can produce a compliant-sounding paragraph on request but haven't verified it against their real infrastructure.

Why this specifically matters to SaaS founders selling into Europe

If you're a SaaS founder building for or selling into European customers, this trend touches you even if you have no plans to ever sell to a government agency directly. Enterprise buyers in regulated industries, and increasingly mid-market European companies who've absorbed sovereignty language from their own procurement teams, are starting to ask vendors — including smaller SaaS vendors — where their infrastructure sits as a standard due-diligence question, not an edge case.

For an early- or growth-stage SaaS company, this creates three concrete pressures:

• Longer sales cycles when the answer isn't ready. A prospect's security or procurement team surfacing a data-residency question mid-deal, with no prepared answer, tends to add weeks to a cycle that was otherwise close to signing.
• A widening gap between "compliant on paper" and "architecturally defensible." A privacy policy that says data may be processed globally reads very differently to a European buyer than a product that can demonstrably keep EU customer data within EU infrastructure by design.
• Competitive exposure to EU-native or EU-first competitors. As sovereign cloud becomes a talking point, competitors who can credibly say "EU-hosted, EU-controlled" gain a differentiator that costs you nothing to match technically but costs you real deals if you're unprepared to discuss it.

None of this requires panic or a full re-platform. It requires knowing, precisely, what your current architecture actually does with European customer data, and being able to say so clearly and specifically the first time a prospect asks.

There's also a segment-specific dimension worth naming directly. If your SaaS product sells primarily to small businesses or prosumer users, sovereignty questions may stay rare for a while longer — smaller buyers usually don't run formal vendor security reviews. But the moment your go-to-market moves upmarket into mid-market or enterprise European accounts, or into any regulated vertical, the odds that a deal includes a data-residency question rise sharply, and they rise fast enough that it's worth preparing before that shift happens rather than reacting once it does. Founders who wait until the first lost deal to investigate their own architecture tend to discover the gap at the worst possible moment — mid-negotiation, with a competitor already in the room who has a cleaner answer.

It's also worth being honest about what this trend does not mean. It doesn't mean every European buyer suddenly requires full data localization, and it doesn't mean non-EU cloud infrastructure is disqualifying on its own. Plenty of deals will still close on the strength of your product, your support, and your pricing, with sovereignty as a secondary consideration handled through documentation rather than a hard requirement. The risk isn't that sovereignty becomes universal overnight — it's that it becomes common enough, in exactly the segment of the market most SaaS founders are trying to grow into, that being unprepared starts costing real revenue.

What changes in practice for your product and infrastructure

The practical shift isn't "switch cloud providers overnight." It's about having deliberate answers to a small set of architectural questions that keep recurring in European sales conversations, and building your product so those answers are accurate rather than improvised.

Data residency and processing location

Where is customer data stored at rest, and where is it processed — including by any third-party subprocessors you use for things like analytics, email, or AI inference? A SaaS product built early without regional data separation often has customer data flowing through infrastructure in whatever region was cheapest or fastest to set up. Retrofitting genuine EU data residency later is a real engineering project, not a config flag, if your data model, backups, and third-party integrations weren't built with regional boundaries in mind from the start.

Vendor and subprocessor transparency

European buyers increasingly want a clear, current list of every subprocessor that touches their data, and where each one is based. If your product quietly depends on a chain of non-EU services for core functionality — logging, search, AI features, email delivery — that chain becomes part of the sovereignty conversation whether you've mapped it out or not. Founders who can produce this list accurately and fast look more credible than founders who have to go find out.

Contractual and operational control

Beyond where data sits, sovereignty conversations increasingly touch who can access it operationally — your own support and engineering staff, any outsourced operations, and any legal exposure to non-EU jurisdiction through your corporate structure or your cloud provider's terms. This is less about your marketing copy and more about whether your actual contracts and access controls hold up under a buyer's real due diligence.

Product architecture decisions that get easier or harder later

Multi-region deployment, tenant-level data pinning, and configurable hosting regions are the kind of architecture decisions that are dramatically cheaper to build in from the start than to bolt on after a customer base has grown. This is squarely the kind of problem Custom Software Development is built to solve deliberately — designing the data layer, deployment topology, and subprocessor boundaries so that "which region does this customer's data live in" is a supported, tested configuration rather than a scramble triggered by a lost deal.

Feature parity across regions

One detail that catches founders off guard once they start building regional separation: not every feature is equally easy to run identically across regions. AI-powered features that depend on a specific model provider, real-time search infrastructure, or third-party integrations that are only available in certain regions can end up with quiet feature gaps between your EU deployment and your primary deployment. Deciding upfront which features are core and must have EU-compliant equivalents, versus which are secondary and can lag, keeps a regional rollout from turning into an open-ended engineering commitment.

Support and incident response expectations

Sovereignty-conscious buyers sometimes extend their questions past infrastructure into how you'd respond to an incident — who gets notified, under what timeline, and whether your incident response process itself involves handling data outside the EU (for example, shipping logs to a non-EU-based observability tool for debugging). This is a smaller detail than the headline data-residency question, but it's exactly the kind of follow-up that comes up in a serious security review, and it's worth having an answer ready rather than discovering the gap live on a call.

What to do about it as a founder, not just an engineer

Treat this as a go-to-market and architecture question together, not purely a backend engineering task.

1. Audit your current data flows honestly. Map every place European customer data touches — your primary database, backups, analytics, email, AI/ML services, logging — and note the region and legal jurisdiction for each. Most founders are surprised by at least one link in that chain.
2. Decide your sovereignty posture deliberately. You don't need full EU-only infrastructure to compete — you need an honest, defensible answer. That might mean EU-hosted primary infrastructure with clearly documented exceptions, or a roadmap toward regional deployment that you can describe credibly to a prospect today.
3. Build the answer into your sales process, not just your engineering backlog. Sales and founder-led selling teams should have a clear, accurate one-page answer to "where does our data live and who can access it" ready before a prospect asks, not drafted under deal pressure.
4. Treat accessibility and trust signals as part of the same due-diligence picture. European enterprise buyers evaluating a vendor's overall credibility often review the product experience itself alongside data practices — our guide on Web Accessibility Compliance: WCAG 2.2 Essentials for Business Websites covers the compliance bar that increasingly sits alongside data sovereignty on European procurement checklists, and Accessible Color Design: Contrast, Color Blindness, and WCAG Compliance covers a specific, easy-to-miss piece of that same bar.
5. Watch the broader regulatory pattern, not just this one trend. Sovereignty is one instance of a wider European (and global) pattern of regulators tightening control over how digital products handle user data and access — our coverage of Australia's under-16 social media ban and the 2026 enforcement crackdown is a useful comparison point for how quickly a regulatory direction can turn into a hard product requirement once enforcement starts.
6. Prioritize by pipeline, not by theory. If you already have European enterprise or public-sector prospects in your pipeline, treat sovereignty readiness as immediate and revenue-linked work. If your European pipeline is still early-stage or mostly small-business, it's reasonable to prioritize the audit and documentation now while deferring larger architecture changes until the deal volume justifies the investment.
7. Revisit this at each fundraising or growth milestone. As your customer base and data volume grow, the cost of retrofitting sovereignty controls grows with it. Treating this as a recurring checkpoint — alongside security reviews and infrastructure scaling decisions — keeps it from becoming an expensive surprise later.

None of these steps require you to have every answer today. What they require is an honest, current picture of your own architecture, updated as your product and customer base change, so that whenever the question does come up — in a sales call, a security review, or an investor's diligence process — you're describing reality rather than guessing at it.

Pricing context: where this work typically falls

The scope of sovereignty-readiness work varies a lot depending on how far your current architecture is from where it needs to be. Here's how it typically maps to service tiers:

Scope	Typical tier	What's usually included
Data flow audit + documentation, minor config changes	Essential ($1,000)	Mapping current subprocessors and data regions, producing a clear data-residency answer for sales
Regional deployment changes, subprocessor consolidation, updated data architecture	Growth ($2,000)	Re-architecting parts of the data layer for regional boundaries, EU-hosted primary infrastructure setup
Full multi-region architecture, tenant-level data pinning, custom compliance tooling	Enterprise ($4,000+)	Ground-up custom software work for founders whose European enterprise or public-sector pipeline depends on demonstrable sovereignty controls

Key Takeaways

• European sovereign cloud momentum, per 2026 digital sovereignty reporting, is a directional shift in enterprise and public-sector procurement expectations, not a single new regulation to check off.
• SaaS founders selling into Europe should expect data-residency and subprocessor questions to appear earlier in sales cycles, even outside government-adjacent deals.
• Map your actual data flows and subprocessor chain now — most founders find at least one non-EU dependency they hadn't fully accounted for.
• Decide a sovereignty posture deliberately and be ready to describe it accurately, rather than improvising an answer mid-deal.
• Multi-region and data-residency architecture is far cheaper to build in early than to retrofit after your customer base has grown.
• Pair sovereignty readiness with adjacent trust signals like accessibility compliance, since European enterprise buyers often evaluate both together.

Getting this right is an architecture decision as much as a compliance one, and it's easiest to get right before a European enterprise deal is already on the table. If you want help figuring out where your product stands and what changes first, book a meeting with our team.

Frequently Asked Questions

What is European sovereign cloud?

European sovereign cloud refers to cloud infrastructure that is hosted, operated, and legally governed within the EU, reducing the risk that a non-EU government or parent company could compel access to the data. It's less a single product and more a set of expectations about jurisdiction, control, and transparency.

Why is sovereign cloud accelerating in Europe right now?

According to European digital sovereignty reporting from 2026, EU governments and enterprises are actively working to reduce structural reliance on non-EU hyperscale cloud providers, driven by concerns over legal jurisdiction and data control. This is showing up as funded infrastructure programs and shifting procurement preferences.

Does this trend only affect companies selling to European governments?

No. While government and regulated-sector procurement is where sovereignty requirements are most explicit, the expectations are spreading into mainstream enterprise buying as those companies adopt similar due-diligence questions from their own customers and regulators.

Do I need to move my entire infrastructure to an EU-only cloud provider?

Not necessarily. What matters more is having an accurate, defensible answer about where your customers' data lives and who can access it — that can mean EU-hosted primary infrastructure, regional deployment options, or a documented roadmap, depending on your customer base.

How do I know if my current SaaS architecture has a sovereignty gap?

Start by mapping every place customer data flows through your stack — primary database, backups, analytics, email, AI services, and logging — and note the hosting region and legal jurisdiction for each one. Gaps usually show up in third-party subprocessors rather than your core database.

What's the difference between GDPR compliance and sovereign cloud readiness?

GDPR compliance is largely about lawful processing and documented data transfer mechanisms. Sovereign cloud readiness goes further, asking whether your infrastructure is structurally dependent on a non-EU jurisdiction regardless of your paperwork.

Will European customers actually ask about this, or is it mostly a government issue?

European digital sovereignty reporting points to enterprise and regulated-sector buyers increasingly inheriting sovereignty language from public-sector procurement norms, so it is showing up in private commercial deals as well, particularly with larger or more risk-conscious buyers.

What happens if a European prospect asks about data residency and I don't have a ready answer?

In practice, an unprepared answer to a data-residency question tends to stall the deal while the prospect's security or procurement team escalates it internally, adding weeks to a cycle that might otherwise have closed quickly.

Can a small or early-stage SaaS company realistically compete on sovereignty with a startup budget?

Yes — the goal isn't matching a full sovereign cloud program, it's having an honest, specific answer about your current data flows and hosting choices. That's achievable at a modest scope of work, especially if addressed before your architecture grows more complex.

What is a subprocessor, and why does it matter for sovereignty conversations?

A subprocessor is any third-party service that touches your customers' data on your behalf — think analytics tools, email delivery services, or AI inference providers. European buyers increasingly want a full, accurate list of these, including where each one is based, since a single non-EU subprocessor can undercut an otherwise EU-hosted setup.

Does using an EU region on a major non-EU hyperscaler count as "sovereign"?

It depends on the buyer's specific requirements. Some accept EU-region hosting on any major provider as sufficient; more sovereignty-conscious buyers specifically want the parent company and legal jurisdiction to be EU-based too, since hosting region alone doesn't remove all legal-access risk.

How long does it typically take to make a SaaS product sovereignty-ready?

It depends entirely on your starting point. A data-flow audit and clear documentation can be a short, focused engagement, while re-architecting for genuine multi-region data residency is a larger custom software project, often spanning several sprints.

What's the first practical step a SaaS founder should take?

Audit your actual data flows and subprocessor chain before you need the answer for a live deal. Knowing exactly where data sits today is the foundation for every decision after it.

Should this be handled by engineering alone, or does it need founder involvement?

Both. The architecture work is engineering-led, but the decision about your sovereignty posture and how it's communicated in sales conversations needs founder-level judgment about your target market and risk tolerance.

Is sovereign cloud relevant if my SaaS product doesn't handle particularly sensitive data?

It can still matter, since sovereignty questions in procurement are often standardized checklist items rather than case-by-case risk assessments. Even lower-sensitivity SaaS products can face these questions simply because the buyer's procurement process asks them of every vendor.

How does this affect SaaS companies using AI features in their product?

AI inference often routes data through additional third-party services, which adds another link in your subprocessor chain that European buyers may ask about. Founders using AI features should map exactly where that inference happens and whether it introduces new non-EU dependencies.

What does "tenant-level data pinning" mean?

It's an architecture pattern where each customer's (tenant's) data can be assigned to a specific region or infrastructure instance, so a single SaaS product can serve both EU-residency-required customers and others without maintaining entirely separate codebases.

Are there specific industries in Europe where this is most urgent?

Financial services, healthcare, critical infrastructure, and public-sector-adjacent industries tend to move fastest on sovereignty requirements, since they inherit stricter expectations from their own regulators.

Could ignoring this trend actually cost me deals?

Based on the pattern described in the reporting — sovereignty language spreading from government procurement into broader enterprise buying — an unprepared answer to a data-residency question is a realistic point where a European deal can stall or be lost to a better-prepared competitor.

What role does Custom Software Development play in solving this?

Custom Software Development is where the actual architecture changes happen — designing data models, deployment topology, and subprocessor boundaries deliberately so regional data residency is a supported configuration rather than an afterthought. See our Custom Software Development service for how this is typically scoped.

How does pricing typically work for sovereignty-related architecture work?

It scales with scope: a data-flow audit and documentation typically sits at the Essential tier, regional deployment changes at Growth, and full multi-region or tenant-pinning architecture at Enterprise. The right starting point depends on how far your current setup is from your target posture.

Is this trend likely to reverse, or is it a long-term shift?

Based on the direction described in 2026 European digital sovereignty reporting — sustained policy funding and institutional procurement pressure — this reads as a structural, multi-year shift rather than a short-term spike, though the specific pace will vary by sector and country.

What should go into a one-page sovereignty answer for sales teams?

It should clearly state where primary customer data is hosted, list key subprocessors and their regions, and describe any options for regional data residency, written in plain language a non-technical buyer can act on quickly.

Does moving to EU hosting affect product performance for non-EU customers?

It can, depending on your architecture — serving European customers from EU infrastructure while maintaining performance for customers elsewhere usually requires a proper multi-region setup rather than a single relocated server.

What's a realistic first milestone for a founder starting this work?

Completing an accurate subprocessor and data-flow map, and having a documented one-page answer ready for sales, is a realistic and valuable first milestone before any infrastructure changes are made.

How do backups factor into data residency?

Backups are frequently overlooked in data-residency reviews — even if primary data sits in the EU, backups replicated to a non-EU region can undercut a sovereignty claim, so they need to be checked and documented explicitly.

Do European sovereignty expectations extend to customer support operations?

Increasingly, yes — some buyers ask not just where data is stored but who (and where) can operationally access it, including support and engineering staff, which can factor into vendor risk assessments.

What's the risk of overstating sovereignty claims to close a deal faster?

Overstating your data residency or subprocessor setup risks contractual and reputational exposure if a buyer's due diligence later finds a mismatch — accuracy matters more here than an impressive-sounding claim.

How does this connect to accessibility compliance for European buyers?

European enterprise procurement increasingly reviews a vendor's overall product trustworthiness holistically, and accessibility compliance under WCAG 2.2 is a related checklist item buyers evaluate alongside data practices — see our guide on WCAG 2.2 Essentials for Business Websites.

Should a SaaS founder prioritize sovereignty over other compliance work like accessibility?

They're not mutually exclusive and often get evaluated together by the same procurement teams, so it's worth treating both as part of one broader trust-and-compliance readiness effort rather than sequencing them strictly.

What does "legal jurisdiction" mean in this context, and why does it matter beyond physical location?

It refers to which country's laws govern access to your data — a server physically in the EU owned by a non-EU parent company can still be subject to that parent country's legal-access laws, which is why buyers increasingly ask about corporate structure, not just server location.

How can I find out which subprocessors my current SaaS stack depends on?

Start with your infrastructure provider's documentation, then trace every third-party integration your product uses for analytics, communications, storage, and AI features, noting each one's hosting region from its own published documentation.

Is there a difference between "EU-hosted" and "EU-sovereign"?

Yes — "EU-hosted" typically just means the servers are physically in the EU, while "EU-sovereign" implies EU legal and operational control as well, which is the stricter bar some buyers are starting to apply.

What if my SaaS product is still early-stage with few European customers?

It's still worth understanding your current data flows now, since architecture decisions made early are dramatically cheaper to adjust than retrofitting after your customer base and data volume have grown.

Can this trend affect fundraising conversations, not just sales?

It's plausible, since European investors evaluating a SaaS company's addressable market in the EU may factor in whether the company's architecture is compatible with sovereignty-conscious enterprise buyers, though this varies by investor and sector.

How do I talk about this with a technical co-founder who's skeptical it matters yet?

Frame it around the sales-cycle risk described in the reporting pattern — a specific, answerable procurement question that's increasingly common in Europe — rather than as an abstract compliance requirement, since that's usually what gets engineering buy-in.

What's the biggest mistake founders make when addressing sovereignty concerns?

Treating it purely as a marketing or contract-language problem, without actually verifying the underlying data flows and subprocessor chain, which then gets exposed the first time a buyer does real technical due diligence.

Does sovereign cloud only apply to data storage, or also to AI model usage?

It extends to AI usage as well — where inference happens and which provider processes the data matters, since AI features often introduce additional subprocessors that need the same scrutiny as other services.

How specific should I be when documenting my subprocessor list for buyers?

As specific as possible — name each subprocessor, its function, and its hosting region, since vague or incomplete answers tend to raise more concern with a European due-diligence team than a clear, itemized list.

What's the relationship between this trend and broader data privacy regulation in Europe?

Sovereign cloud builds on the foundation GDPR established around data protection, but shifts the emphasis from lawful processing toward structural control and jurisdictional independence, making it a related but distinct consideration.

Should I mention sovereignty readiness proactively in sales conversations, or wait to be asked?

Proactively addressing it, especially with enterprise or regulated-sector prospects, tends to build more credibility than waiting for the question, since it signals you've already thought it through rather than reacting under pressure.

How do multi-region deployments affect ongoing engineering maintenance?

Multi-region setups add operational complexity — deployment pipelines, monitoring, and data synchronization all need to account for multiple regions, which is why this is typically scoped as a larger custom software engagement rather than a quick fix.

Is there a way to test whether my current sovereignty posture would hold up to buyer scrutiny?

Simulating a buyer's due-diligence questionnaire internally — asking your own team to answer the data-residency and subprocessor questions a prospect might raise — is a practical way to find gaps before a real deal exposes them.

What's a reasonable timeline to budget for full sovereignty-readiness architecture work?

For a full multi-region or tenant-pinning architecture project, timelines typically span multiple sprints rather than days, since it touches data models, deployment infrastructure, and integration points across the product.

Does this trend affect how SaaS founders should evaluate new cloud vendors going forward?

Yes — when selecting new infrastructure or subprocessor vendors, it's worth factoring in their EU hosting options and legal jurisdiction upfront, since retrofitting that consideration later is more expensive than building it in from vendor selection.

How do I keep my subprocessor documentation current as my stack evolves?

Treating subprocessor mapping as a living document, updated whenever a new third-party service is added to your stack, keeps your sovereignty answer accurate rather than stale by the time a buyer asks.

What's the connection between this trend and other regulatory tightening happening globally?

It's part of a broader pattern of regulators worldwide tightening control over digital products' data handling and user protections — our coverage of the under-16 social media enforcement crackdown illustrates how quickly a regulatory direction can convert into concrete product requirements once enforcement begins.

Should SaaS founders expect sovereignty requirements to get stricter over time?

Based on the sustained institutional and policy momentum described in the 2026 reporting, it's reasonable to expect these expectations to tighten rather than loosen, though the exact pace and scope will vary across sectors and countries.

How should feature parity across regions factor into my sovereignty planning?

If some features depend on providers or infrastructure only available outside the EU, decide upfront which features must have EU-compliant equivalents and which can lag, rather than discovering the gap mid-rollout. Core functionality is usually worth prioritizing for parity first, with secondary features following as resources allow.

What's the best way to get started if I suspect my architecture has gaps?

Book a scoping conversation to walk through your current data flows and subprocessor chain against what European buyers are actually asking for — that's the fastest way to know whether you need documentation, targeted changes, or a larger architecture project.