PWA vs Native App: Which Should You Build?

Native apps offer peak performance and full hardware access, while PWAs provide cross-platform reach and lower development costs without app store submission constraints.

Evaluating whether to build a Progressive Web App (PWA) or a Native application is a foundational architectural decision that impacts your company’s capital allocation, operational velocity, and long-term user retention. In mobile product engineering, choosing the wrong stack can lead to substantial technical debt, prolonged time-to-market, or high customer acquisition costs. This strategic analysis examines the performance trade-offs, financial models, security frameworks, and platform-specific constraints governing both development paths, directly addressing the core dilemma of PWA vs Native App: Which Should You Build? to guide CTOs, product leaders, and enterprise decision-makers toward the most viable solution.

The Executive Summary: Bridging Business Goals with Technology

Selecting an application architecture requires aligning software capabilities with enterprise business models, unit economics, and targeted customer touchpoints. For decades, mobile product development defaulted to native software engineering under the assumption that only platform-native binaries could deliver enterprise-grade performance. However, the maturation of modern web standards—underpinned by ECMAScript advancements, browser-level multi-threading, and standardized hardware abstractions—has elevated Progressive Web Apps into a viable primary platform for many business verticals.

The tension between these two models lies in how value is delivered across the customer lifecycle. Native software development prioritizes execution speed, deep hardware access, and platform integration at the expense of development velocity and capital efficiency. Conversely, Progressive Web Apps leverage web distribution to eliminate onboarding friction, bypass app store operational restrictions, and reduce engineering overhead across fragmented device environments.

Product leaders must evaluate this architectural choice not merely as an engineering exercise, but as a core determinant of return on investment (ROI), go-to-market speed, and operational viability. Deciding between a native binary and an enhanced web runtime requires a holistic audit of your product's functional complexity, offline requirements, monetization mechanics, and organic acquisition funnels.

The Case for Native Apps: Performance and Hardware Integration

Native mobile applications are compiled directly into platform-specific machine code (Swift/Objective-C for iOS, Kotlin/Java for Android), executing directly against platform runtimes and framework layers (Cocoa Touch and Android Jetpack). This compilation pipeline yields direct, un-sandboxed access to device execution threads and graphic subsystems via Metal (iOS) and Vulkan (Android). When an application demands consistent 60 or 120 FPS render loops, extensive multi-threaded background processing, low-latency Bluetooth peripheral communications, or direct hardware sensor interaction, native architecture remains the standard.

Furthermore, native applications operate within the ecosystem’s native UI component libraries, automatically inheriting platform-specific ergonomics, dynamic typography scaling, accessibility features, and transition kinematics. For consumer brands where interface tactility directly drives micro-conversions, or enterprise tools interacting with external barcode scanners, thermal printers, and biometric authentication chips via Secure Enclave, native applications provide a direct line to device hardware.

The Case for PWAs: Cross-Platform Agility and Cost Efficiency

Progressive Web Apps utilize modern browser capabilities—specifically Service Workers, the Cache API, Web App Manifests, and asynchronous execution contexts—to deliver an app-like user experience over standard HTTP pipelines. By utilizing standard web technologies (HTML5, CSS3, modern JavaScript/TypeScript runtimes), an organization maintains a single codebase that executes across iOS, Android, macOS, Windows, and ChromeOS. This single-source paradigm eliminates the resource drain of maintaining separate engineering teams for disparate operating systems.

The financial and operational advantage of PWAs centers on frictionless deployment and distribution. PWAs bypass app store review queues, policy updates, and mandatory 15% to 30% developer platform fees on in-app purchases. Product updates, security patches, and A/B test variations deploy instantly to client runtimes via standard web servers and Content Delivery Networks (CDNs). For SaaS platforms, B2B workflows, and e-commerce enterprises where acquisition friction kills conversion funnels, PWAs merge the discoverability of web SEO with the retained engagement of an installable application.

Core Architecture and Performance Capabilities

To understand the operational trade-offs between PWAs and Native apps, engineering leaders must analyze the architectural stack separating application logic from underlying silicon. Native applications communicate directly with the mobile operating system's kernel through official platform Software Development Kits (SDKs). Progressive Web Apps run inside a sandboxed browser rendering engine—WebKit on iOS, Chromium/Blink on Android, and Gecko on alternative platforms.

This fundamental architectural difference governs memory allocation, thread management, peripheral availability, and compute-intensive operations. While modern JavaScript engines (such as V8 and JavaScriptCore) utilize Just-In-Time (JIT) compilation to deliver near-native compute speeds for business logic, layout rendering engines must still compute the Document Object Model (DOM), apply Cascading Style Sheets, and composite paint layers through an abstraction boundary that natively compiled views bypass entirely.

Native App Performance: Unrestricted API and Hardware Access

Native architectures achieve deterministic execution speed and low frame-time variance because they interact directly with platform drivers without intermediary virtualization. When executing complex computations—such as client-side machine learning inference via Apple CoreML or Android Neural Networks API (NNAPI)—the native application dispatches tasks directly to the device’s Neural Processing Unit (NPU) or GPU compute pipelines.

+-------------------------------------------------------------+
|                     Native Application                      |
|                  (Swift / Kotlin Binary)                    |
+-------------------------------------------------------------+
                              |
                              v
+-------------------------------------------------------------+
|              Platform Frameworks & OS Kernel                |
|              (Cocoa Touch / Android Jetpack)                |
+-------------------------------------------------------------+
                              |
                              v
+-------------------------------------------------------------+
|                       Device Hardware                       |
|           (CPU, GPU, NPU, Secure Enclave, Sensors)          |
+-------------------------------------------------------------+

Hardware access in native applications is practically unrestricted, subject only to user permissions and operating system security policies. Capabilities include:

• Background Processing: Unrestricted background audio streaming, continuous geofencing, high-precision background location tracking, and scheduled task synchronization.

• Hardware Peripherals: Low-energy Bluetooth (BLE) peripheral/central modes, Near Field Communication (NFC) tag reading and card emulation, ultra-wideband (UWB) spatial tracking, and direct USB host interfaces.

• Biometrics & Cryptography: Direct access to Apple Secure Enclave / Android Keystore for biometric signature generation via FaceID, TouchID, and platform-level hardware-backed credential storage.

• Advanced Rendering: Zero-overhead Metal, Vulkan, and OpenGL ES access for augmented reality (ARKit/ARCore), 3D spatial rendering, and computational photography.

PWA Performance: Service Workers and Browser Limitations

Progressive Web Apps operate within the security boundaries of the web platform. The core driver of PWA capability is the Service Worker—an event-driven, programmable network proxy running in a background execution context entirely distinct from the main browser UI thread. Service Workers intercept network requests, execute programmatic caching strategies via the Cache Storage API, and manage background data synchronization.

+-------------------------------------------------------------+
|                  Progressive Web App (UI)                   |
|                   (HTML5 / CSS3 / WebGL)                    |
+-------------------------------------------------------------+
           |                                     ^
           | PostMessage / Events                | Caching & Data
           v                                     |
+-------------------------------------------------------------+
|              Service Worker (Background Thread)             |
|              (Network Proxy, Cache, Web Push)               |
+-------------------------------------------------------------+
                              |
                              v
+-------------------------------------------------------------+
|             Browser Engine Sandbox (WebKit / Blink)         |
+-------------------------------------------------------------+
                              |
                              v
+-------------------------------------------------------------+
|                 Host Operating System Kernel                |
+-------------------------------------------------------------+

Despite Project Fugu (the Chromium capability project that brought Web Bluetooth, WebUSB, and File System Access APIs to the desktop and Android web), major mobile operating systems—most notably Apple iOS—place structural limits on browser execution contexts.

On mobile Safari (and all iOS browsers, which until recently were strictly bound to WebKit), background execution is heavily constrained. A Service Worker cannot run continuously in the background; it is terminated within seconds after the user backgrounds the browser or locks the screen. Memory consumption is monitored by the browser sandbox, which will terminate tabs or web processes that exceed platform thresholds (often 300MB–1GB depending on total device RAM), whereas native processes can allocate memory dynamically up to system thresholds.

Offline Functionality: How Both Approaches Handle Connectivity Loss

Offline reliability is essential for enterprise field services, logistics applications, and high-frequency commerce platforms. Both architectures approach offline state management through fundamentally different mechanisms.

Native applications use robust embedded database engines such as SQLite, Realm, or platform-native persistence models (Apple Core Data, Android Room). These databases support relational querying, binary blob storage, dynamic indexing, and ACID compliance. Data synchronization engines can run scheduled background threads via Android WorkManager or Apple BackgroundTasks framework to reconcile offline mutations with cloud endpoints whenever connectivity returns, even if the application is completely closed.

Progressive Web Apps handle offline states using the Cache Storage API for static assets (HTML, CSS, JavaScript chunks, images) and IndexedDB for structured client-side data. IndexedDB provides a transactional, object-oriented database capable of storing JSON documents, strings, and Blobs. By utilizing Google's Workbox library or custom Service Worker interception scripts, PWAs can execute advanced caching patterns:

• Stale-While-Revalidate: Returns cached assets immediately to ensure zero UI delay, while asynchronously fetching an updated asset from the origin server for subsequent sessions.

• Network-First with Cache Fallback: Queries the network for real-time operational data, defaulting to the IndexedDB local state if the network connection drops or times out.

• Background Sync API: Queues offline network requests (such as form submissions or order requests) and executes them automatically once network connectivity is re-established (extensively supported in Chromium/Android, though limited on iOS WebKit).

Financial and Operational Implications

The total cost of ownership (TCO) for a digital product encompasses initial capital expenditure, continuous release engineering, cross-platform QA regression cycles, infrastructure overhead, and platform marketplace commissions. When structuring digital product budgets, engineering leaders must balance upfront development speed against the long-term maintenance costs of supporting multiple parallel technology stacks.

Initial Development Costs and Time-to-Market

Building a native product across both major mobile ecosystems requires maintaining two independent engineering streams: an iOS codebase (Swift/SwiftUI) and an Android codebase (Kotlin/Jetpack Compose). This dual-track approach doubles the required engineering headcount, specialized tooling, and quality assurance overhead. While cross-platform compilation frameworks (such as React Native or Flutter) can consolidate some business logic, they introduce intermediary framework overhead and still require native platform bridges for specialized hardware tasks.

For a venture-backed startup or enterprise digital initiative testing a new market hypothesis, a PWA compresses time-to-market. Single-team web development velocity allows product organizations to iterate based on real customer data months before a native application clears app store staging pipelines.

Long-Term Maintenance and Codebase Management

The operational cost of software compounds post-launch. Operating system vendors introduce major platform updates annually (e.g., iOS 18 to iOS 19, Android 15 to Android 16), which routinely deprecate APIs, alter background processing rules, enforce new UI paradigms, and require binary recompilation with updated SDK versions.

Native teams must budget ongoing maintenance sprints solely to prevent bit rot and ensure compatibility with newly released hardware viewports (e.g., dynamic islands, folding displays, varying aspect ratios). If an engineering team manages an iOS app, an Android app, and a responsive web application, every business requirement must be written, code-reviewed, tested, and synchronized across three distinct codebases.

PWAs minimize long-term maintenance overhead by adhering to the foundational principle of the open web: backward compatibility. Web standards evolve gradually through W3C and WHATWG consortium consensus. A well-architected web application built according to semantic standards continues running predictably across browser runtime updates without mandatory maintenance overhauls.

The Hidden Costs: App Store Fees vs. Web Hosting Infrastructure

A critical line item often omitted from preliminary financial modeling is the structural platform commission extracted by centralized app marketplaces.

===================================================================
                    TRANSACTION ECONOMICS BREAKDOWN
===================================================================

[ Native App Store Channels (Apple IAP / Google Play Billing) ]
+-----------------------------------------------------------------+
| Gross Digital Transaction Value:                       $100.00  |
| Platform Fee (Standard Tier: 30%):                     -$30.00  |
| Platform Fee (Small Business Program: 15%):            -$15.00  |
| Net Retained Revenue (Excluding hosting/infra): $70.00 - $85.00  |
+-----------------------------------------------------------------+

[ Progressive Web App Distribution (Custom Payment Gateways) ]
+-----------------------------------------------------------------+
| Gross Digital Transaction Value:                       $100.00  |
| Payment Processing Fee (Stripe / Adyen ~2.9% + $0.30):   -$3.20  |
| Cloudflare / AWS Edge CDN Ingress/Egress:               -$0.05  |
| Net Retained Revenue:                                   $96.75  |
+-----------------------------------------------------------------+

For digital subscription businesses, SaaS platforms, digital content creators, and media enterprises, the 15% to 30% revenue share taken by Apple App Store and Google Play can undermine unit economics. While both platforms offer small business programs reducing the fee to 15% on the first $1 million in annual digital revenue, scaling past that threshold triggers the full 30% fee on digital goods, subscriptions, and unlockable features.

PWAs operate entirely outside these platform mandates. Because transactions occur within a standard web browser context, businesses can integrate third-party payment gateways (e.g., Stripe, Adyen, Braintree, direct merchant acquirers) that charge standard merchant interchange rates (typically 1.5% to 2.9% + transaction fee). Over millions of dollars in gross merchandise volume (GMV), this variance can fund an entire engineering department.

Conversely, PWAs require resilient web infrastructure, including high-availability Edge CDNs, Web Application Firewalls (WAF), serverless compute runtimes for server-side rendering (SSR), and automated multi-region caching to deliver sub-second time-to-interactive (TTI) metrics globally. However, cloud infrastructure costs scale linearly with traffic and remain an order of magnitude lower than native marketplace transaction fees.

Security, Compliance, and Ecosystem Risks

Risk management in software architecture extends beyond vulnerability vectors into platform governance, store rejection vulnerabilities, and enterprise data compliance (such as GDPR, HIPAA, and PCI-DSS). Product leaders must weigh the operational security profiles of both native binaries and browser execution contexts against the platform risks imposed by platform gatekeepers.

App Store Approval Processes and Rejection Risks

Deploying a native application introduces a platform intermediary into your release pipeline. Both the Apple App Store Review Guidelines and Google Play Developer Policies maintain strict, sometimes ambiguously enforced rules regarding:

• User interface layouts, design originality, and minimum utility standards.

• Mandatory utilization of platform in-app purchase systems for digital services.

• Data collection, tracking transparencies (e.g., Apple App Tracking Transparency - ATT), and user account deletion flows.

• Content moderation frameworks for user-generated content.

===================================================================
                  RELEASE VELOCITY PIPELINE COMPARISON
===================================================================

[ Native App Store Deployment Lifecycle ]
Code Commit ---> CI/CD Build ---> Binary Signing ---> Store Ingestion
    ---> Static Analysis Engine ---> Human Review Gate (24 - 72 Hours)
    ---> [ RISK: Rejection / Appeal Loop (3 - 10 Days) ]
    ---> Phased Rollout to User Devices (48 Hours for full client adoption)

[ Progressive Web App Edge Deployment Lifecycle ]
Code Commit ---> CI/CD Build & Test ---> Edge CDN Invalidation
    ---> Global Production Availability (< 60 Seconds)
    ---> [ Zero Third-Party Review Intermediaries ]

An urgent security patch or critical hotfix in a native application cannot reach end-users instantly. It must pass through platform review pipelines, which can take anywhere from 12 hours to several days. If a build is rejected during a critical marketing launch, the entire business operation stalls. PWAs give the organization complete operational sovereignty: continuous deployment pipelines update production assets within seconds without third-party gatekeeping.

Apple (iOS) and Safari Limitations for PWAs: What You Must Know

While Google actively advocates for and supports the Progressive Web App standard within the Chromium engine on Android, Apple has historically taken a more conservative approach toward PWA capabilities within its iOS ecosystem.

Key limitations on iOS include:

• Storage Eviction Policies: If a user does not open an installed PWA within a rolling 7-day period, iOS WebKit may purge its local cache and IndexedDB storage under certain conditions, forcing the app to re-fetch assets upon the next network-enabled launch.

• Restricted Web APIs: WebKit explicitly disables or omits APIs available in Chromium, such as Web Bluetooth, WebUSB, Web NFC, the Ambient Light Sensor API, and the File System Access API, citing user privacy and security architectures.

• Web Push Notification Constraints: While Apple introduced Web Push for PWAs added to the Home Screen starting in iOS 16.4, it requires the user to explicitly add the application to their home screen first and grant push permissions. The user cannot receive push notifications directly through standard mobile Safari navigation.

• Installation Friction on iOS: Safari does not support automated, custom-designed in-browser install banners on the same level as Android. Users must navigate through the native Safari share sheet and manually select "Add to Home Screen."

Data Security and Enterprise Compliance Considerations

From an enterprise security perspective, both architectures present distinct threat models and compliance profiles.

Native applications execute within dedicated OS-level sandboxes that isolate memory and file storage from other applications on the device. They can leverage the platform's hardware-backed cryptographic keystores to secure authentication tokens, encrypt local databases with AES-256 at rest, and implement rigorous Certificate Pinning to prevent Man-in-the-Middle (MitM) attacks on network requests.

===================================================================
                   SECURITY ARCHITECTURE VECTORS
===================================================================

Native Threat Vectors:
  * Reverse engineering of decompiled binaries (extracting API keys).
  * Compromised / rooted client device runtime inspection (Frida/Xposed).
  * Storage of unprotected tokens in shared preference files.

Progressive Web App Threat Vectors:
  * Cross-Site Scripting (XSS) exploiting the single shared origin.
  * Malicious dependency injection in complex JavaScript bundles.
  * Insecure caching of sensitive Personal Identifiable Information (PII).

PWAs operate within the browser sandbox, which protects the host operating system from malicious code. However, PWAs are susceptible to Cross-Site Scripting (XSS) attacks. If an attacker injects malicious JavaScript into a web application, they can access tokens stored in @@CODE0@@ or @@CODE1@@. To achieve parity with native compliance standards, enterprise PWAs must implement strict Content Security Policies (CSP), utilize @@CODE2@@, @@CODE3@@ cookies for session management, and ensure all asset distribution pipelines enforce Subresource Integrity (SRI) and modern TLS standards.

User Acquisition and Retention Strategies

Customer acquisition cost (CAC) and lifetime value (LTV) define the financial health of digital products. The technical architecture you choose directly influences top-of-funnel discovery, mid-funnel conversion rates, and long-term user retention.

Discoverability: SEO Benefits of PWAs vs. App Store Optimization (ASO)

The primary growth advantage of a Progressive Web App lies in its native integration with the web’s primary discovery engine: organic search. Every screen, product listing, and programmatic asset inside a PWA can have a unique Uniform Resource Identifier (URI). Search engine crawlers can index these deep URLs, allowing organizations to deploy comprehensive programmatic Search Engine Optimization (SEO) campaigns that drive qualified search traffic directly into the application context.

Native applications rely primarily on App Store Optimization (ASO) within the Apple App Store and Google Play Store. ASO is constrained by limited keyword fields, opaque ranking algorithms, and crowded marketplace categories. While universal links can route search traffic into an installed native app, users who do not have the app installed encounter an intermediary web page prompting them to download the binary from the app store, introducing friction into the acquisition funnel.

===================================================================
                     ACQUISITION FUNNEL LEAKAGE
===================================================================

[ Native App Store Acquisition Funnel ]
1. Search Ad / Social Link Clicked
   | (100% Traffic)
2. Redirected to Apple App Store / Google Play
   | (20-40% Drop-off: User abandons page or lacks Wi-Fi/storage)
3. User Authenticates & Waits for 50MB-200MB Download
   | (10-20% Drop-off: Install fatigue, slow cellular connection)
4. User Launches App & Meets Mandatory Onboarding / Permissions
   | (15-30% Drop-off: Permission friction, account creation)
5. NET RETAINED ACTIVE USERS AT CORE VALUE: ~20% - 35%

[ Progressive Web App Acquisition Funnel ]
1. Search Ad / Organic Link Clicked
   | (100% Traffic)
2. Instant Page Render via Edge CDN & Service Worker Caching
   | (5-10% Bounce Rate: Typical web performance variance)
3. Immediate Interaction with Core Application Features
   | (Frictionless consumption, progressive conversion)
4. Optional Single-Click "Add to Home Screen" Prompt
5. NET RETAINED ACTIVE USERS AT CORE VALUE: ~65% - 80%

Installation Friction: App Store Downloads vs. Add to Home Screen (A2HS)

The native installation funnel requires significant user commitment. Users must navigate away from their current task, load the app marketplace, enter their biometric or password credentials, download an executable binary ranging from 30MB to upwards of 200MB, and open the app from their home screen. For transactional utilities, media outlets, and direct-to-consumer e-commerce, each step in this download funnel introduces user drop-off.

Progressive Web Apps eliminate this download barrier. Users land on a responsive web application and can complete their primary objective—such as purchasing a product, reading content, or utilizing a calculation tool—within seconds.

Once the user recognizes value in the product, the PWA offers an Add to Home Screen (A2HS) installation. This installs a lightweight manifest footprint (often under 2MB), placing an icon on the user’s home screen and app launcher that opens in a standalone window without browser chrome. This process delivers an app-like presence without the friction of the marketplace funnel.

Push Notifications: Re-engaging Users Across Different Operating Systems

Push notifications are a powerful vector for driving customer re-engagement, retention, and lifetime value.

Native applications have long possessed mature, comprehensive push notification architectures via Apple Push Notification service (APNs) and Firebase Cloud Messaging (FCM). Native apps can display rich media notifications, deliver dynamic notification badges, execute background data downloads upon notification arrival (silent push), and update system-level widgets directly from remote payloads.

Progressive Web Apps utilize the standardized Web Push API and PushManager interface. On Android/Chromium, Web Push is highly mature, operating reliably even when the browser application is completely closed. On Apple iOS, Web Push is fully supported provided that:

• The user is running iOS 16.4 or later.

• The application has been explicitly added to the Home Screen as a PWA.

• The user explicitly grants notification permissions via a user-initiated gesture (such as clicking a "Subscribe to Notifications" button inside the PWA).

While PWAs now support push messaging across both major mobile operating systems, organizations requiring silent background data sync or dynamic iOS badge updates without installation must account for native ecosystem advantages.

Strategic Decision Matrix: Which Should You Build?

Making the final architectural choice between a Progressive Web App and a Native application requires evaluating your product's technical requirements, development budget, time-to-market constraints, and monetization strategy.

When to Invest in a Native Application

Investing capital in a dual-track native application (or a native cross-platform framework such as Flutter or React Native) is recommended when your product requires:

• Deep Hardware Integration: Continuous background BLE communication, custom peripheral integrations, low-latency audio processing pipelines, or ARKit/ARCore spatial experiences.

• High Compute Performance: Complex 3D rendering engines, local client-side video/image manipulation, high-framerate action gaming, or heavy local machine learning inference.

• Enterprise Device Policies: Deep enterprise mobility management (EMM) distribution, MDM device enrollment, and zero-trust local keystore isolation.

• Platform UX Alignment: Products where user adoption depends on matching the default user experience paradigms, haptics, and interface design of iOS and Android.

When a Progressive Web App is the Smarter Choice

A Progressive Web App is the more efficient architectural approach when your organization prioritizes:

• Unified Distribution & Rapid Iteration: SaaS products, B2B enterprise portals, workflow productivity tools, and direct-to-consumer e-commerce platforms.

• Cost-Efficient Cross-Platform Reach: Startups and enterprises seeking to validate market fit, deploy unified updates, and conserve engineering capital by maintaining a single TypeScript/Web codebase.

• Unrestricted Monetization: Products structured around digital content sales, recurring memberships, or course subscriptions that cannot sustain a 15% to 30% app store fee.

• Search-Driven Acquisition: Products that rely on organic SEO, content marketing, and friction-free social sharing to acquire users at a low marginal cost.

The Hybrid Approach: Starting with PWA and Scaling to Native

Software architecture does not have to be a binary, irreversible choice. Many successful digital products follow a phased platform evolution:

===================================================================
                  PHASED PLATFORM MATURATION MODEL
===================================================================

[ PHASE 1: Market Validation & Low-Friction Acquisition ]
Deploy high-performance Progressive Web App (PWA).
  * Consolidate capital into a single Web/API engineering team.
  * Optimize organic SEO funnels and refine core product-market fit.
  * Avoid marketplace review bottlenecks and establish direct billing.

                                |
                                v

[ PHASE 2: Ecosystem Expansion & Store Presence ]
Wrap the mature PWA using Trusted Web Activities (TWA) on Android 
and PWABuilder / WKWebView shells on iOS.
  * List on Google Play and Apple App Store with minimal overhead.
  * Capture branded store search queries while maintaining a single codebase.

                                |
                                v

[ PHASE 3: Specialized Native Bifurcation (If Required) ]
Introduce native modules or compile dedicated native clients ONLY for 
subsets of power users requiring deep hardware access or offline synchronization.

By structuring your software architecture around clean API boundaries, reusable design systems, and decoupled backends, you can launch rapidly with a Progressive Web App today, validate your commercial viability, and introduce native mobile binaries as your balance sheet and functional requirements evolve.