Selling Platfio Implementations Into the Enterprise

Selling Platfio implementations into enterprise customers is possible. Agencies have already delivered Platfio-powered apps across different industries, markets, and operating environments.

The business case is similar to the SMB clients you have likely already sold to: better customer experiences, more efficient workflows, faster launches, and software that can be easily managed by non-technical stakeholders.

Enterprise stakeholders will simply ask more detailed technical questions about infrastructure, integration, security, ownership, and support before they approve the opportunity. This guide gives you the language and decision points you need to answer those questions, reassure technical stakeholders, and keep the deal moving forward.

Deployment Models

Platfio-hosted tenant

For most customers, the app runs as a tenant in Platfio’s GCP infrastructure.

Keep this section brief:

• fastest path to launch
• shared operational responsibility
• standard Platfio maintenance and upgrades

Platfio-hosted single tenant

For enterprise customers that need more isolation without owning the infrastructure, the app can run as a single tenant in Platfio’s GCP infrastructure.

Keep this section brief:

• dedicated tenant isolation
• Platfio-managed infrastructure
• simpler operations than client-owned infrastructure

Client-owned single tenant

For enterprise customers, Platfio can be deployed into the client’s own GCP environment.

Keep this section brief:

• stronger client-side infrastructure control
• clearer enterprise procurement fit
• more implementation and support planning

Note: this requires both the agency and the individual app to be on an enterprise plan.

Frontend

Core

Platfio includes a configurable frontend layer with core modules for auth, segments, products, bookables, subscribables, forms, pages, and more.

These modules can be implemented and customized with no code. Most client requirements should start here: configure the module, adjust the page structure, connect the right data, and keep the app inside the standard Platfio upgrade path.

Extension / Customization

When the standard modules are not enough, custom frontend features can be added with HTML, CSS, and JavaScript.

We recommend LitJS for custom application features because it works well for focused, reusable UI components inside the Platfio app. Custom pages and components can use window.access to reach Platfio-provided helpers, including authenticated Firebase SDK access, Capacitor plugins, and other platform services exposed to the app.

Use frontend customization for client-specific user experiences, custom interaction flows, or specialist UI that should live inside the deployed application.

Backend

Core backend services

Every Platfio module includes pre-configured backend functions that are deployed with the application.

For example, when an order is made, a Cloud Function runs the checkout, product, notification, and fulfilment behavior configured through the no-code interface. The exact behavior depends on the checkout settings, product details, automations, and module configuration already set up inside Platfio.

Default Cloud Functions include:

• OrderWritten
• BookingWritten
• SubscriptionWritten
• SubscriptionPaymentWritten
• FormSubmissionWritten
• UserWritten
• UserSegmentWritten
• UserCounterWritten

No-code and low-code backend services piggyback on these core application events.

No-code custom backend services

Platfio automations and webhooks can hook into application events and respond without custom code.

Use this layer when a client needs to send a webhook to an external service, trigger an internal workflow, notify a team, update a record, or run a sequence of configured steps in response to something happening inside the app.

Low-code custom backend services

Automations can also include custom Node.js where a workflow needs more logic than the standard no-code steps provide.

Use this layer for lightweight backend extensions that still belong inside Platfio’s automation system: data transforms, conditional logic, small integrations, or workflow steps that need code but do not need a separate deployment surface.

Platfio-deployed Cloud Functions

For deeper backend customization, custom Cloud Functions can be deployed through the Platfio interface.

Use this layer when the client needs custom backend behavior that should still be deployed and managed through Platfio: custom APIs, heavier integrations, specialized processing, or backend workflows that should live beside the deployed application.

Build your own backend

For enterprise clients that want full control, you can deploy your own backend infrastructure into the client’s cloud environment and connect it to the Platfio frontend.

Custom frontend code can make authenticated HTTP requests to your backend services. Requests can include the authenticated user’s bearer token, and your backend can use Firebase Admin SDK credentials, including a service account, to verify the user and authorize the request before running custom infrastructure.

CI/CD

Platfio-managed CLI

Platfio’s CI/CD is designed around a command line tool that builds and deploys applications consistently across environments.

In 99% of implementations, that CLI runs on Platfio’s infrastructure. It deploys the application either into a Platfio-hosted tenant or into a client-owned single-tenant GCP environment, depending on the deployment model chosen for the enterprise client.

Client-owned GitHub Actions

Some enterprise clients require the full build and release process to run inside their own infrastructure.

For those implementations, Platfio can install the CLI into a GitHub Actions environment owned by the client. This keeps the deployment workflow aligned with the client’s infrastructure ownership, procurement, and security requirements.

GitHub Actions is the preferred environment for this path because some deployments need to run on a Mac runner. That requirement means the CLI cannot always be moved into another build environment, such as Cloud Build, unless that environment will only update the backend and web application.

Integration Patterns

Platfio recommends choosing one of the following integration patterns. They move from the fastest setup to the highest-control enterprise model.

No-code Webhooks / Endpoints

Use webhooks and endpoints when Platfio needs no-code controls for sending events out and receiving events back in through a Zapier-style integration platform. This pattern uses HTTP requests, platform triggers, and secret URL authentication.

flowchart LR
  subgraph ClientGCP["Client GCP app environment"]
    subgraph Records["App Data Layer"]
      Auth["Firebase Auth"]
      Firestore["Firestore"]
      Storage["Cloud Storage"]
    end

    subgraph Services["Core Firebase services"]
      Functions["Cloud Functions"]
      Scheduler["Cloud Scheduler"]
    end

    NoCodeIO["Webhook / Endpoint"]

    Auth <--> Functions
    Firestore <--> Functions
    Storage <--> Functions
    Scheduler --> Functions
    Functions <--> NoCodeIO
  end

  subgraph ClientSide["Client-side integration path"]
    direction TB

    subgraph IPaaS["Integration platform as a service"]
      Provider["iPaaS provider<br/>(Zapier-style)"]
    end

    subgraph Client["Client enterprise environment"]
      Integration["Custom integration service"]
      Service["Existing internal services<br/><small>e.g. users, notifications,<br/>orders, bookings</small>"]
      Record["Client systems of record<br/><small>e.g. Salesforce, SAP,<br/>Databricks, MongoDB, MySQL</small>"]

      Integration <--> Service <--> Record
    end
  end

  NoCodeIO <-->|"HTTP request<br/>platform trigger<br/>secret URL auth"| Provider
  Provider --> Integration
  Provider --> Service
  Provider --> Record

Low-code Automations

Use low-code automations when an automation should trigger a custom Node.js step, or when a network request should trigger an automation that can then run a custom Node.js step.

flowchart LR
  subgraph ClientGCP["Client GCP app environment"]
    subgraph Records["App Data Layer"]
      Auth["Firebase Auth"]
      Firestore["Firestore"]
      Storage["Cloud Storage"]
    end

    subgraph Services["Core Firebase services"]
      Functions["Cloud Functions"]
      Scheduler["Cloud Scheduler"]
    end

    Automation["Automation trigger<br/>HTTP automation trigger"]
    Node["Custom Node.js step<br/>send / process request"]

    Auth <--> Functions
    Firestore <--> Functions
    Storage <--> Functions
    Scheduler --> Functions
    Functions <--> Automation <--> Node
  end

  subgraph Client["Client enterprise environment"]
    Integration["Custom integration service"]
    Service["Existing internal services<br/><small>e.g. users, notifications,<br/>orders, bookings</small>"]
    Record["Client systems of record<br/><small>e.g. Salesforce, SAP,<br/>Databricks, MongoDB, MySQL</small>"]

    Integration <--> Service <--> Record
  end

  Node <-->|"HTTP request<br/>REST API<br/>shared secret auth"| Integration

Custom integration services

Use custom integration services when the integration needs a dedicated place for mapping, retries, credentials, routing, and operational logging outside the no-code automation path.

Direct custom integration service

flowchart LR
  subgraph ClientGCP["Client GCP app environment"]
    subgraph Records["App Data Layer"]
      Auth["Firebase Auth"]
      Firestore["Firestore"]
      Storage["Cloud Storage"]
    end

    Integration["Custom integration service"]
    Trigger["Custom trigger"]

    Trigger --> Integration
    Auth <--> Integration
    Firestore <--> Integration
    Storage <--> Integration
  end

  subgraph Client["Client enterprise environment"]
    ClientIntegration["Custom integration service"]
    Service["Existing internal services<br/><small>e.g. users, notifications,<br/>orders, bookings</small>"]
    Record["Client systems of record<br/><small>e.g. Salesforce, SAP,<br/>Databricks, MongoDB, MySQL</small>"]

    ClientIntegration <--> Service <--> Record
  end

  Integration <-->|"HTTP request<br/>REST API<br/>shared secret auth"| ClientIntegration

Enterprise API gateway option

Use an enterprise API gateway when the client wants the strongest control over inbound traffic, authentication, policy enforcement, and system access.

flowchart LR
  subgraph ClientGCP["Client GCP app environment"]
    direction LR

    subgraph Sources[" "]
      direction TB
      Trigger["Pub/Sub events or<br/>Cloud Function triggers"]

      subgraph Records["App Data Layer"]
        direction TB
        Auth["Firebase Auth"]
        Firestore["Firestore"]
        Storage["Cloud Storage"]

        Auth --> Firestore --> Storage
      end

      Trigger --> Auth
    end

    Integration["Custom integration service"]

    subgraph Boundary["API boundary"]
      direction TB
      HttpClient["Outbound API service<br/><small>Cloud Run</small>"]
      HttpGateway["API HTTP gateway<br/><small>Cloud Load Balancer or Apigee</small>"]
      BoundaryNote["Use Secret Manager,<br/>Cloud Armor / CDN,<br/>logging, metrics, and traces<br/>(as appropriate)"]

      HttpClient --> HttpGateway --> BoundaryNote
    end

    Trigger --> Integration
    Auth <--> Integration
    Firestore <--> Integration
    Storage <--> Integration
    Integration --> HttpClient
    Integration <--> HttpGateway
  end

  subgraph Client["Client enterprise environment<br/>(abbreviated)"]
    direction TB
    Gateway["API gateway"]
    EnterpriseClient["Outbound API service"]

    Gateway ~~~ EnterpriseClient
  end

  HttpClient <-->|"HTTP request<br/>gRPC API<br/>mTLS auth"| Gateway
  HttpGateway <--> EnterpriseClient

  style Sources fill:transparent,stroke:transparent
  style Boundary fill:transparent,stroke:transparent
  style BoundaryNote fill:transparent,stroke:transparent,color:#4b5563
  linkStyle 0 stroke:transparent,fill:none
  linkStyle 1 stroke:transparent,fill:none
  linkStyle 2 stroke:transparent,fill:none
  linkStyle 3 stroke:transparent,fill:none
  linkStyle 4 stroke:transparent,fill:none

Enterprise data ownership

Use a client-owned system of record pattern when the deployed applications should use Platfio for authentication and application delivery, but all business data should remain inside the client’s enterprise environment.

In this model, Android, iOS, and web applications sign users in through Firebase Auth. Firebase Auth can use SAML or OpenID Connect to connect to the client’s existing identity provider for single sign-on. Firebase Cloud Messaging can also stay in the app environment for push notifications, since most enterprises do not want to operate that service themselves. After sign-in, the applications call the client’s application API gateway directly with the authenticated user’s bearer token.

flowchart LR
  subgraph Apps["Client applications"]
    Android["Android app"]
    IOS["iOS app"]
    Web["Web app"]
  end

  subgraph ClientGCP["Client GCP app environment"]
    Auth["Firebase Auth"]
    FCM["Firebase Cloud Messaging<br/><small>optional</small>"]
  end

  subgraph Identity["Client identity environment"]
    IdP["Client identity provider"]
  end

  subgraph Client["Client enterprise environment"]
    Cdn["Cloud CDN and Cloud Armor<br/><small>optional</small>"]
    Gateway["API gateway and client<br/><small>optional</small>"]
    Integration["Custom integration service"]
    Queue["Enterprise event bus<br/><small>Kafka, RabbitMQ,<br/>Azure Service Bus,<br/>Amazon SQS, Google Pub/Sub</small>"]
    Service["Existing internal services<br/><small>e.g. users, notifications,<br/>orders, bookings</small>"]
    Record["Client systems of record<br/><small>e.g. Salesforce, SAP,<br/>Databricks, MongoDB, MySQL</small>"]

    Cdn --> Gateway --> Integration --> Queue --> Service --> Record
  end

  Android --> Auth
  IOS --> Auth
  Web --> Auth
  FCM --> Android
  FCM --> IOS
  FCM --> Web
  Auth <-->|"SAML / OpenID Connect<br/>single sign-on"| IdP
  Android --> Cdn
  IOS -->|"HTTP request<br/>REST or Graph API<br/>Firebase Auth bearer token"| Cdn
  Web --> Cdn

  classDef optional fill:#f4f1ff,stroke:#9b7cff,stroke-dasharray: 4 4,color:#4b5563,opacity:0.72
  class Cdn,Gateway,Queue,FCM optional

How to Choose

Use this simple rubric:

Pattern	Use when	Integration and auth model
Platfio-hosted tenant	The client wants the fastest path, managed operations, and standard delivery.	Platfio owns the primary infrastructure path.
Platfio-hosted single tenant	The client needs stronger tenant isolation, but still wants Platfio to manage the infrastructure.	Platfio runs a dedicated single tenant inside Platfio’s GCP infrastructure.
Client-owned single tenant	The client needs infrastructure ownership, stricter procurement requirements, or deeper enterprise controls.	Platfio is deployed into the client’s GCP environment.
No-code webhooks / endpoints	The integration can flow through an iPaaS provider for simple trigger-based workflows.	Mapping happens in the iPaaS layer; authentication can use a secret URL or simple bearer token handling.
Low-code automations	The integration needs custom Node.js logic without requiring an iPaaS provider for mapping.	Mapping can happen inside Platfio automation logic; API keys and shared secrets can be retrieved from Secret Manager.
Custom integration services	The integration needs dedicated mapping, retries, credential handling, routing, or operational logging, and API key or shared secret authentication is sufficient.	A custom service owns the integration boundary and can use API key or shared secret authentication.
Enterprise API gateway option	The client needs the custom integration pattern, but requires mTLS for authentication.	The client API gateway becomes the controlled enterprise entry point and enforces mTLS.
Client-owned system of record	The client wants Platfio application delivery while minimizing data stored in Platfio-controlled services.	Firebase Auth and optional Firebase Cloud Messaging may still store required identity or messaging data, but business data should prefer the client’s systems of record.

FAQs From Enterprise Architects

When presenting Platfio to a CTO, enterprise architect, CISO, VP Engineering, or Head of Platform, these are common questions agencies should be ready to field during the sales process.

Error handling

When fielding questions from enterprise architects about error handling, always note the following:

• Design idempotency into integration services and event handlers wherever practicable.
• Use retries with exponential backoff and timeouts.
• Use dead-letter queues for failed or unprocessable events.
• Use compensating actions when consistency needs to be repaired across systems.
• Use observability with correlation IDs so failures can be traced across the integration boundary.

Authentication

When fielding authentication questions from enterprise architects, always map the required authentication strength back to the integration pattern:

• Use no-code webhooks and endpoints when a secret URL is sufficient, or when the client accepts simple bearer token handling. Note: some iPaaS providers can decode bearer tokens; Platfio can send and decode them, but no-code shared secrets are stored in Firebase behind security rules, not Secret Manager.
• Use low-code automations when API keys (shared secret authentication) are sufficient and the workflow needs more control. Note: low-code automations can retrieve secrets from Secret Manager during triggers and workflow actions.
• Use direct custom service integrations when API keys (shared secret authentication) are sufficient and the client does not require gateway-level policy enforcement.
• Use mTLS in the enterprise API gateway option when the client requires stronger authentication at the enterprise boundary.
• As in the enterprise data ownership model, Firebase Auth can use a custom provider to connect the client’s existing identity provider, provided it supports SAML or OpenID Connect. The enterprise environment can then verify the signed-in user’s JWT using the Firebase Admin SDK and a service account issued for token verification.

Authorization

When fielding authorization questions from enterprise architects, always clarify where access decisions will live:

• By default, Platfio includes a role-based access control system where users are staff members, managers, or directors. In enterprise situations, these roles will often be insufficient, so the segments module can be used to create customer segments that correspond to custom roles or attributes, assign them to users, and support RBAC or ABAC authorization flows enforced by Platfio’s standard Firestore and Cloud Storage security rules.
• Platfio does not include an out-of-the-box ACL system. ACLs can be implemented from scratch based on the client’s systems of record, or with custom entities in Firestore enforced by security rules.
• For service-to-service communication, prefer service accounts with cloud provider IAM patterns that implement the principle of least privilege. For example, a custom integration service might use a service account to call the orders service, with that service account explicitly granted the Cloud Run Invoker role for that service.

APIs

When fielding API questions from enterprise architects, always connect the API style to the integration pattern:

• REST APIs are generally well understood by all parties and are a strong default option.
• GraphQL may be preferable in the enterprise data ownership model, where the app reads from the enterprise’s systems of record through an integration service and multiple calls may otherwise be required to render a page.
• For multi-cloud service-to-service communication, gRPC may be the organization’s preference when it wants lower latency and stronger type safety across enterprise API gateway boundaries.

Testing

When fielding testing questions from enterprise architects, always explain that test coverage can be built to the client’s specifications:

• Platfio supports testing across application and integration code.
• Unit tests will be written for custom source code in your integration to the client’s required level of code coverage.
• Integration tests can use Firebase emulators where Firebase services are part of the flow.
• End-to-end tests can use Playwright, which is available in Platfio’s testing platform by default, or be built elsewhere to test full user and integration flows in the Platfio application.
• Quality of tests matters more than quantity of tests; the goal is useful confidence in the flows that matter.

Observability

When fielding observability questions from enterprise architects, always clarify what each team can see and who owns investigation:

• Agree on logs, metrics, and traces.
• Use correlation IDs across the Platfio and enterprise boundary.
• Define alerting ownership and escalation paths.
• Clarify which team investigates which classes of failures.
• For frontend observability, use tag manager integrations where appropriate; Google Analytics can support marketing analytics, while tools such as PostHog can provide a more complete product usage picture.

Multi-region support

When fielding multi-region questions from enterprise architects, always separate the default configuration from enterprise-specific requirements:

• By default, Firebase is configured in a single region.
• If the business need requires lower latency, higher availability, or stronger geographic resilience, Firestore can be implemented multi-region.
• Confirm which Firebase services support the required regional model before committing to the architecture.

Disaster recovery

When fielding disaster recovery questions from enterprise architects, always tie the answer to the deployment model and operating responsibilities:

• Agree recovery time objectives and recovery point objectives.
• Clarify backup requirements and restore ownership.
• Identify dependencies on downstream enterprise systems.
• For client-owned single tenant deployments, align disaster recovery controls with the client’s GCP, identity, network, logging, and incident response processes.

Scale

When fielding scale questions from enterprise architects, always frame the conversation as a joint architecture review:

• Platfio infrastructure is designed to be stateless, horizontally scalable, and automatically scaled.
• Scale discussions should include downstream enterprise service limits.
• Discuss rate limits, queueing, and backpressure on services Platfio relies on inside the client’s environment.
• Frame this as shared planning, not criticism of the client’s systems.

Data consistency

When fielding data consistency questions from enterprise architects, always clarify the consistency model:

• Identify the source of truth for each business object and, where needed, each important field. The client system might own customer identity while Platfio owns workflow status, app activity, or operational state.
• Decide whether the integration uses one-directional sync from Platfio to the client’s system of record. This is simpler and often the right MVP choice; after records are sent, they should be locked or treated as non-editable in Platfio.
• If the integration needs bi-directional sync, agree the conflict rules up front: which system wins, how field-level differences are merged, how duplicate or out-of-order events are handled, and what sync delay is acceptable.
• Define how records are matched across systems, including external IDs, mapping tables, duplicate handling, merge behavior, and whether deletes become hard deletes, soft deletes, or archives.
• Explain retry behavior, idempotency, and where eventual consistency is expected, using plain language about what users may see while data is still syncing.
• Plan reconciliation and repair paths for drift between systems, including audit logs, exception queues, manual review ownership, and compensating actions where cross-system state needs to be fixed.

Schema flexibility

When fielding schema flexibility questions from enterprise architects, always explain how schema change will be handled:

• Use Platfio configuration for standard fields and standard modules.
• Use custom integration services for mapping and transformation.
• Use versioned contracts when client systems evolve independently.
• Agree how breaking changes, optional fields, and deprecated fields will be managed.