Is Cross-Platform App Development with Flutter Worth It in 2026? Pros, Cons, Costs & Decision Framework

Why Fora Soft wrote this playbook

We’ve shipped iOS and Android products since 2005 — native, React Native, Cordova, and Flutter, in that order — and we have the receipts of getting each one wrong before we got it right. Our portfolio includes Scholarly, ProVideoMeeting, Speed Space, TradeCaster, SuperPower FX, and TapeReal. Some of those are Flutter today. Some used to be Flutter. Some never should have been. We learned the difference the expensive way.

This playbook is the doc we now hand to founders before they sign a Flutter contract anywhere — with us or otherwise. It pulls together what is actually true about Flutter in 2026 (Flutter 3.41+, Dart 3.11, Impeller default on iOS, Android Impeller in stable rollout), where the framework genuinely earns its keep, and the four scenarios where choosing it will cost you more than two native teams would have.

Think of it as the conversation we’d have over a 30-minute call, written out so you can read it at your own pace and bring colleagues. If you want the call instead, we’re always one click away.

The verdict, in one paragraph

Cross-platform app development with Flutter is worth it when (a) your product’s differentiator lives above the platform layer — meaning UX, content, transactions, dashboards, social mechanics, marketplaces — (b) you ship to iOS and Android together, (c) you can tolerate a 4–8 MB engine binary, and (d) you accept that a senior native engineer will still be wired in for platform channels and OS-release ramps. Under those conditions Flutter shaves 30–40% off time-to-market and 35–50% off the build budget compared to two parallel native squads.

It is not worth it when your product’s differentiator is the platform layer: real-time A/V, on-device ML, AR, advanced camera/audio capture, watchOS/wearables, Vision Pro, CarPlay/Android Auto, and games. In those categories, Flutter saves you a few weeks early and costs you several months and one or two re-platform decisions later. We have rebuilt apps from Flutter to native for exactly this reason — multiple times.

How Flutter actually works in 2026

Flutter ships your Dart code together with a portable C++ rendering engine. Instead of mapping your widgets to UIKit/Views (the React Native model), Flutter draws every pixel itself. As of 2026 the engine is Impeller, default on iOS and rolling out to Android stable; it precompiles shaders ahead of time, eliminating the jank that used to spike on first cold-start with the old Skia path.

Practically, that means three things you should know before signing anything:

1. The look is identical across iOS and Android. Flutter does not call the OS to render a button; it renders the button. Material 3 Expressive on Android and Cupertino widgets on iOS are both available, but they’re Flutter’s reproduction of those design languages, not the OS’s. That’s a feature for design-led brands and a bug for apps that want to feel exactly like a native iOS or Android system app.

2. The bridge to native is via platform channels. When Flutter doesn’t cover a native API — CallKit, BLE, HealthKit, WidgetKit, ARKit, advanced camera APIs, custom MLKit pipelines, native CarPlay — you write a Swift or Kotlin module and message it from Dart. Each channel is a code path that has to be tested on every iOS/Android version you support.

3. Hot reload is the killer feature. Sub-second iteration on UI changes is genuinely transformative for design-engineering velocity. It’s the single biggest reason teams that ship a lot of UI to A/B test prefer Flutter to native — even at the cost of the engine overhead.

Pros — what Flutter genuinely gets right

1. One team, two stores. A typical Flutter project ships 75–85% of code shared between iOS and Android. With careful architecture (one repo, riverpod or bloc, freezed models, golden tests), you don’t fork code paths until you genuinely need to. Compared to running iOS and Android squads in parallel, that turns a six-month native build into a three-and-a-half-month Flutter build.

2. Velocity at the design layer. Hot reload makes A/B testing onboarding flows, paywalls, and detail screens cheap. Designers sit next to engineers and iterate against the real device. We’ve watched this collapse a two-week onboarding redesign into three days.

3. Pixel-perfect design fidelity. Because Flutter draws everything, your $40,000 Figma file looks like your $40,000 Figma file on every device. No more “our font shipped 2px off on Android 11”. For brand-critical consumer apps this is worth real money.

4. 60fps default. The Flutter scheduler targets 60fps and the Impeller renderer keeps it there on mid-range Android (Snapdragon 6-class) hardware. React Native’s old bridge dropped frames under load; the new architecture closes the gap, but Flutter’s baseline is still smoother out of the box.

5. Mature plugin ecosystem. pub.dev now hosts north of 50,000 packages. Firebase, Stripe, Adyen, RevenueCat, Sentry, Mapbox, Google Maps, Algolia, Auth0, Supabase, AWS Amplify — all officially supported. The boring infra is a one-line dependency.

6. Web and desktop are bonus output formats. Flutter Web isn’t at parity with hand-tuned React, but for an internal admin tool or a marketing-page product configurator, it’s a free byproduct of your mobile build. Same for macOS/Windows desktop — useful for ops dashboards.

Cons — where Flutter still hurts

1. The 4–8 MB engine binary. Every Flutter app drags the engine with it. For consumers in EU/US that’s invisible. For apps targeting low-bandwidth markets or App Clips/Instant Apps it’s a real install-funnel cost. Native iOS apps still routinely ship under 25 MB; Flutter equivalents start at 30 MB and climb fast.

2. Dart talent is a smaller pool. Stack Overflow’s 2025 survey put Dart at roughly a third of JavaScript’s footprint. You can hire excellent Flutter engineers; you cannot hire them at the same density as React Native or web React. That matters for staffing scale-ups.

3. Plugins lag native API releases by 6–12 months. When iOS 26 added Liquid Glass and watchOS 12 added new health metrics, official Flutter plugin coverage trailed by months. If you’re a launch-day-feature kind of product, you’ll write platform channels yourself or wait.

4. Real-time multimedia is genuinely worse than native. Frame-accurate audio, sub-frame video sync, custom camera buffers, low-latency RTC pipelines — you’re always pushing through platform channels, and the channel itself is the bottleneck. We have benchmarks of WebRTC in Flutter that drop 15–25% more frames than the equivalent native pipeline on identical hardware.

5. Wearables, Vision Pro, CarPlay, Android Auto: not first-class. watchOS support is community-only and nowhere near production-ready. visionOS is on the roadmap, not in the SDK. CarPlay/Android Auto require native shells. If your product strategy has any of these on the 18-month plan, factor in native engineers anyway.

Performance benchmarks: Flutter vs native vs React Native

Buyers love a benchmark. Engineers know they always lie unless you’re measuring your own workload. Below are conservative ranges from our own profiling on identical hardware (iPhone 15 Pro, Pixel 8a) for a feed-style consumer app of comparable feature set, plus reproducible third-party data from the engine teams themselves. Treat them as a sanity-check, not a buying decision.

Read it like this: Flutter is closer to native than React Native on every dimension, and it’s indistinguishable from native on most. The exceptions are install size (the engine binary tax), real-time multimedia (the platform-channel tax), and idle memory (the engine pays for itself in RAM). For most consumer apps, none of those break the experience. For a video conferencing app or a wearable companion, all three do.

Flutter vs React Native vs Kotlin Multiplatform vs native

If you’re evaluating Flutter, you’re almost certainly also evaluating React Native, Kotlin Multiplatform Mobile (KMM), or two native squads. Here’s how they line up in 2026 for a typical 3-month MVP / 12-month v1 product trajectory:

Budget figures assume an Eastern-European or LatAm senior team using Agent Engineering, which compresses 25–35% of the typical agency timeline. They are conservative; we’ve quoted under these for tightly-scoped MVPs and well above for compliance-heavy products. See our full software estimation guide for how we build these numbers.

When Flutter is the right choice

After ten-plus Flutter shipping engagements at Fora Soft, we’ve narrowed the green-light category to seven product shapes. If yours fits cleanly into one of these, choose Flutter and don’t look back.

1. Marketplaces and e-commerce. Listings, search, cart, checkout, ratings — UI-heavy, transaction-heavy, no real-time multimedia. Flutter ships these in 3 months with one team. Compare to a native pair which would still be in alpha at that point.

2. Fintech & neo-banking front ends. Onboarding, KYC flows, dashboards, transaction lists, card management. The differentiator is design and trust, not platform. Nubank scaled from 500K to tens of millions of users on Flutter for exactly this reason.

3. Booking & on-demand services. Restaurant reservations, salon bookings, gym scheduling, tutoring marketplaces. Maps + lists + forms + payments. Flutter handles all four out of the box.

4. Internal enterprise tools. Field-force apps, inspection apps, sales dashboards, dealer portals. BMW Connected Drive’s dealer apps are Flutter. The audience is captive, the design is utilitarian, and platform parity is the win.

5. Content / news / publishing. Static-ish feeds, video clips at standard resolutions, audio playback, reading-mode UIs. Flutter’s text rendering is excellent and the install size doesn’t bite for established media brands.

6. MVPs that need to validate fast. If you’re six months from a Series A and need both stores live to interview customers, Flutter is the sane default. You can re-platform later if your differentiator turns out to be platform-specific. We’ve lived this transition with clients more than once.

7. Consumer apps that ship a lot of UI. If your roadmap is “30 new screens this year” rather than “deep platform integration this year,” Flutter’s velocity wins.

When NOT to use Flutter (and what to use instead)

This is the section we wish more buyers read first. We see at least one or two re-platform projects per quarter where the original team chose Flutter because it was fashionable, not because it fit. The pattern is always the same.

1. Real-time video / audio communication. Conferencing, live streaming, low-latency broadcast, voice rooms. Use native, or use native UI with a thin platform-channel wrapper around a battle-tested SDK. We’ve published a full guide to video conferencing development and a P2P-vs-SFU-vs-MCU breakdown for exactly this category.

2. Heavy on-device ML / AR. Face filters, computer vision pipelines, ARKit/ARCore experiences, on-device inference of LLMs or vision models. Native is faster, more memory-efficient, and substantially better-supported by Apple’s and Google’s ML toolchains.

3. Wearables and Vision Pro. watchOS support is community-grade, not production. Vision Pro/visionOS is on the Flutter roadmap, not in the SDK. If wearable parity or spatial computing is in your 18-month plan, plan native engineers anyway.

4. Games. Use Unity or Unreal. Flutter can technically render game-style UIs via Flame, but you’ll fight tooling, asset pipelines, and physics engines that Unity has spent twenty years polishing.

5. Apps where the differentiator IS the platform. Native CarPlay, Android Auto, watchOS, Liquid Glass design language, deep widgets/Siri intents/Live Activities. If you can’t describe your app without mentioning a platform-specific capability in the first sentence, you’re building a native app.

Cost model: what Flutter actually costs in 2026

Most cost articles online are either generic ranges or vendor sales pitches. Here is the actual breakdown we’d quote a founder for a typical Flutter MVP this quarter, with conservative assumptions and Agent-Engineering productivity baked in.

For a typical post-MVP v1 product (12 months, expanded feature set, scaling to first 50K–100K users), the same crew lands at $90K–$180K. Compliance-heavy products (HIPAA, PCI, SOC 2) add 15–25% for security review, audit logging, and penetration tests.

The same product built by two parallel native squads runs $80K–$140K for the MVP and $200K–$350K for the v1. The Flutter savings are real; they’re also a function of staying inside the green-light category from section 8. If you wander into the section 9 territory mid-build, the savings evaporate.

The hidden costs nobody quotes

1. Platform-channel maintenance. Every native module is a code path you maintain across iOS and Android version bumps. Budget 5–10% of build cost per year for keeping channels green.

2. Plugin churn. Open-source plugins go unmaintained. We’ve replaced abandoned plugins three times on a single project. Budget 30–60 hours/year per non-trivial plugin you depend on.

3. Flutter major-version migrations. Flutter 3 → 3.x introduced Impeller, the new plugin format, Material 3 by default, and Dart 3 sound null safety. Migrating a real codebase across these is one to four weeks. The next major bump will be similar.

4. Native engineer on retainer. Even on a Flutter-first product you want a senior iOS and a senior Android engineer reachable. They handle store rejections, signing chain drama, OS-release ramps, and the platform-channel work nobody scoped on day one. Plan a part-time slice each.

5. Larger app binaries cost App Store rejection rework. Apple applies install-size limits on cellular downloads (200 MB then 50 MB historically; check current rules). Flutter apps need --split-per-abi, deferred components, and asset trimming earlier than native apps do.

Mini case: when Flutter saved a launch (and the time it didn’t)

The save. A bookings-and-membership client came to us with a six-month native build that was 60% done and 100% over budget. Their differentiator was the booking funnel and the loyalty UI — not platform integration. We rebuilt the front end in Flutter in 11 weeks, kept their existing backend, and shipped to both stores 13 weeks after kickoff. Code shared across iOS and Android: 82%. Crash-free sessions on launch day: 99.6%. Their CFO sent a thank-you note specifically calling out the burn-rate slope chart.

The miss. A different client wanted a Flutter video conferencing MVP — group calls, screen share, low-latency. We pushed back; they pushed harder. Eight weeks in, the team had spent three of those weeks fighting platform-channel race conditions in the WebRTC plugin and another two debugging audio-route changes on iOS. We re-platformed to native iOS + native Android with shared backend and shipped six weeks later. The total clock time was the same as a native build from day one would have been. The lesson: section 9 is not optional.

Want a similar before/after assessment for your own roadmap? Book a 30-minute call and we’ll do the diagnostic on the spot.

A decision framework — pick Flutter in five questions

Run this with your CTO and lead designer before you sign anything. If you can answer “yes” to four of the five, Flutter is the right default. If you answer “no” to two or more, pivot to native or hybrid.

Q1. Do we need iOS and Android live within four months? If yes, Flutter’s velocity matters. If you have a year, native is fine and removes the engine tax.

Q2. Is our differentiator above the platform layer? If your unique value is content, transactions, social mechanics, dashboards, or design, yes. If your unique value is “we have the best AR experience on iPhone,” no.

Q3. Can we tolerate a 4–8 MB engine binary? For most consumer apps, yes. For App Clips, instant apps, or low-bandwidth-market apps, often no.

Q4. Do we have or can we hire one senior native engineer per platform on call? Platform channels need a real native engineer behind them. If you can’t access that talent on demand, your Flutter project will hit walls.

Q5. Are we shipping less than 5% real-time multimedia surface? If a video call screen and a recording mic toggle are a small slice of the app, fine — native-wrap them. If they’re the core experience, choose native.

Architecture and stack we recommend for Flutter projects

After more than a dozen Flutter projects we’ve converged on a stack that survives staffing changes, six-month feature pushes, and OS version bumps. Use it as your default; deviate only when a specific reason demands it.

State management: riverpod for new projects, flutter_bloc for teams that prefer the BLoC pattern. Avoid bare setState beyond toy screens.

Models & serialization: freezed + json_serializable. Generated immutable models, exhaustive switch on unions, free copy-with.

Navigation: go_router with type-safe routes. Deep links and web-fragment routing for free.

Networking: dio with interceptors for auth, retries, and observability. Strongly typed clients via retrofit.

Local storage: isar or drift for structured data, flutter_secure_storage for tokens and PII.

Auth, payments, observability: Firebase Auth or Supabase, RevenueCat for IAP, Sentry + Firebase Crashlytics + Datadog for end-to-end traces.

Testing: unit tests with flutter_test, widget tests for every leaf widget, golden tests for design-system components, integration tests via patrol.

CI/CD: GitHub Actions or GitLab CI + Codemagic or Bitrise for Flutter-aware build runners. Fastlane for store submission. Branch protection, mandatory PR reviews, golden-test diff bot.

Code-sharing pattern we trust

A Flutter monorepo we’d ship to a client looks roughly like this. The skeleton matters because it’s where you fight platform divergence early instead of late.

apps/
  mobile/                  # Flutter app (iOS + Android + Web/Desktop bonus)
    ios/                   # Xcode project, native modules, signing
    android/               # Gradle project, native modules
    lib/
      app/                 # routing, theme, top-level providers
      features/            # one folder per feature, screen + bloc + data
      shared/              # design system, core widgets, models
      l10n/                # localization arb files
packages/
  domain/                  # pure Dart, models + use-cases
  network/                 # dio + retrofit clients, generated DTOs
  storage/                 # isar/drift, key-value, secure storage
  design_system/           # tokens, typography, atoms, golden tests
  analytics/               # Firebase, Mixpanel, Datadog wrappers
native_modules/
  ios_callkit/             # Swift package, exposed via platform channel
  android_bluetooth/       # Kotlin module, exposed via platform channel
infra/
  firebase/                # rules, functions, indexes
  pipelines/               # GitHub Actions, Codemagic, Fastlane lanes

The win: every native module is a single, isolated Swift or Kotlin package. When iOS 27 ships and Apple changes a CallKit API, you fix one package. When you swap a backend, you fix one package. When a designer wants a new typography scale, you fix one package and golden tests catch every regression.

Five pitfalls that kill Flutter projects

1. Skipping golden tests for the design system. Without them, you ship visual regressions every sprint. Three weeks in, the designer files a bug, the engineer says “works on my machine,” and trust evaporates. Add a golden-test diff bot to your PR template on day one.

2. Letting setState sprawl. Flutter screens with 600 lines of setState spaghetti rebuild the world on every keystroke. Frame budgets crater. Refactor to riverpod or BLoC before screens cross 200 lines.

3. Trusting unmaintained plugins. Pin versions, audit the GitHub repo for the last commit date and open issues, and own a fork if a critical plugin goes silent. We have a checklist of every plugin’s health before any project starts.

4. No native engineer on the team. Sooner or later you need to debug a CallKit race condition, a HealthKit permission flow, or an iOS 26 keyboard regression. If your team is “all Flutter,” you’re a week away from blowing past the sprint.

5. Ignoring app size from day one. By the time the launch checklist asks, you have a 90 MB binary and one week to fix it. Track install size in CI from week one. Use deferred components and per-ABI splits early.

KPIs to measure if you ship Flutter

Quality KPIs. Crash-free sessions ≥ 99.5% (Sentry/Crashlytics). 90th-percentile frame time < 16 ms on the lowest-spec target device. Cold-start < 2.0 s on Android mid-range. ANR rate < 0.5%.

Business KPIs. Time from PR-merged to store-live < 24h on a release week. Designer-to-prod cycle for a single screen < 3 days. Cost per net-new screen < $1,500 in steady state.

Reliability KPIs. Plugin migration debt audit per quarter (open issues, last commit date). Native channel incident rate < 1 per release. App-size regression alerts in CI on every PR. SLA on store-rejection turnaround < 48h.

Compliance and security considerations

Flutter doesn’t change your compliance burden — the OS does — but a few patterns will save you a security audit later.

1. Auth and tokens. Use flutter_secure_storage for refresh tokens. It maps to Keychain on iOS and EncryptedSharedPreferences on Android, both backed by the platform secure enclave on supported devices.

2. SSL pinning. Pin via dio certificate-pinning interceptor or platform-side via network_security_config.xml + ATS exceptions. Pin at the network layer, not in Flutter only, or you’ll be defeated by a runtime hooking tool.

3. PII and HIPAA/GDPR. Encrypt local stores at rest, log audit events server-side, never log PII at the client (Flutter’s default debugPrint is dangerous in release). For HIPAA, treat Flutter as you’d treat any client; the rules apply equally.

4. Tampering and reverse-engineering. Dart compiles to AOT machine code on release; that helps but is not a guarantee. Use code obfuscation (flutter build --obfuscate --split-debug-info=...) and add a server-side integrity check (Play Integrity, App Attest) for high-value APIs.

5. Supply chain. Pin pub.dev plugin versions, mirror critical packages, and run dart pub outdated and pana in CI. We treat plugin supply chain like any other dependency — same way we’d treat npm or PyPI.

How Agent Engineering changes Flutter delivery

Most agency cost models still assume a senior engineer hand-types every line. Ours don’t. Fora Soft uses spec-driven agentic engineering to compress the boilerplate slice of Flutter work — freezed models, retrofit clients, BLoC scaffolding, golden-test fixtures, l10n harnesses — while keeping a senior in the loop on every commit.

Practically, we see three effects on a Flutter project:

1. Boilerplate is 60–80% faster. A new screen with state, networking, error states, and tests is a 60-minute task instead of a day. Multiply by 30 screens.

2. Migrations get cheaper. A Flutter 3 → future 4 migration that used to take three weeks compresses to ten days because spec-driven agents do the mechanical surface and humans do the design judgement.

3. Quotes go down without quality going down. The numbers in section 10 already include this productivity. We don’t markup the savings; we pass them through. That’s why our Flutter MVP quotes look 20–30% under typical agency rates without cutting senior review.

When to plan a re-platform off Flutter (and how)

Sometimes the right answer is to start in Flutter and re-platform later when the product’s differentiator changes. We have done this with three clients over the last 24 months. Here’s the playbook.

1. Decide based on roadmap, not codebase. If the next 12 months pull you into Vision Pro, watchOS, advanced ML, or real-time A/V, plan native. If they don’t, stay.

2. Keep the backend. Backends rarely need to change. Re-platforming the front-end is a 3–5 month project; touching the backend at the same time triples it.

3. Re-platform feature by feature behind a feature flag. Build the new native app screen by screen and ship a hybrid (native shell with embedded Flutter for not-yet-migrated screens) until parity. Do not big-bang.

4. Cap the Flutter feature freeze. When you start a re-platform, freeze new feature work in Flutter. Otherwise you build everything twice and miss the deadline.

5. Honest cost. A 3–5 month team-of-three native build, plus 1 month of overlap with the Flutter team, plus QA. For a typical product that’s $80K–$160K. That number is part of the original Flutter decision, even if you don’t spend it.

Companies running Flutter at scale (and what they tell us)

Decision-makers want social proof. Here’s the list we keep close, with a one-line read on each.

Google Pay, Google Classroom, Google Earth. Flutter is dogfooded across Google’s consumer surface area. The signal isn’t “Google likes Flutter”; it’s “Google maintains Flutter through OS releases and design-language shifts”.

Nubank. Latin America’s largest neobank ships Flutter to tens of millions. Their public engineering posts cite 30–40% faster feature deployment than their previous native pipeline.

BMW Connected Drive. Dealer-facing apps and parts of the customer experience moved to Flutter to reduce native overhead. Internal-tool category, not the in-car HMI.

Alibaba Xianyu. Marketplace consumer app at hundreds of millions of users. Heavy commerce surface; pure section-8 territory.

Toyota. Some embedded automotive infotainment uses Flutter; the company shared this publicly at Flutter conferences as evidence the framework is production-grade for non-game embedded surfaces.

eBay Motors. Marketplace use case. Same pattern.

What none of these are: video conferencing, game engines, on-device computer vision pipelines, or wearable companions. Pattern recognition matters.

Cross-platform vs PWA vs hybrid — when to consider alternatives

Flutter isn’t the only cross-platform option. Three specific situations are better-served by something else.

1. Use a PWA when: the user expects to access your product from a desktop browser too, you don’t need push notifications on iOS, you don’t need deep platform integration, and install friction is the bottleneck. We’ve made the case in detail in why PWAs could ruin your business — the title is provocative; the analysis is sober.

2. Use React Native when: your engineering org is a JavaScript/TypeScript shop, you have web-React expertise to redeploy, and you can tolerate the new-architecture migration. RN’s talent pool is 3–4× larger than Flutter’s; for fast scaling teams that matters.

3. Use a native shell with Flutter modules when: 80% of your app is content/forms/dashboards and 20% is real-time A/V or platform-specific. You get Flutter velocity on the boring screens and native fidelity where it matters. We’ve published the full native vs cross-platform decision matrix and mobile app development services explainer for buyers comparing all options.

How Fora Soft delivers Flutter projects

Three things matter for buyers comparing agencies.

1. Discovery before estimate. We always run a paid two-week discovery before quoting a build. It catches the section-9 traps before you sign anything. Read about our discovery process and the scoping playbook.

2. Senior-only delivery. Every Flutter engineer on our roster is a senior or above. We don’t learn on your codebase. The Agent-Engineering pipeline lets two seniors do the work of three mid-levels at the cost of one and a half.

3. Fixed-price & hybrid models. Most engagements are time-and-materials with a written estimate ceiling. For tightly-scoped MVPs we offer a fixed price. For long-term products we recommend a dedicated team with monthly check-ins. Customer success management is built in to every engagement.

Past clients on the record: AppyBee, Vodeo / Janson Media, MobyTap, Community Hill, and ALDA. Many of those engagements include cross-platform mobile work.

FAQ

What to read next

Ready to choose — or rule out — Flutter for your product?

Cross-platform app development with Flutter is worth it when your product fits the green-light category and you accept the trade-offs honestly. For content, commerce, fintech, dashboards, marketplaces, internal tools, and design-led consumer apps, Flutter ships 30–40% faster and 35–50% cheaper than two parallel native teams — and that math gets better with Agent Engineering on top.

It is not worth it when your differentiator IS the platform — real-time A/V, advanced AR/ML, watchOS, Vision Pro, or games — and trying to force-fit Flutter into those categories costs you the very speed you came for. Use the five-question framework in section 13, run it with your CTO, and decide before you sign. If you want a written verdict on your specific roadmap, that’s what we do on a 30-minute call.