---
type: source
title: 'Source: NETSUITE_SUITEAPP_READINESS.md'
aliases:
  - NetSuite SuiteApp readiness
  - SuiteApp readiness
  - Built for NetSuite readiness
  - BFN readiness
modified: 2026-06-14
tags:
  - source
  - netsuite
  - suiteapp
  - readiness
  - squire
  - technical-proof
---

# Source: NETSUITE_SUITEAPP_READINESS.md

> What it would take to qualify as a SuiteApp — beyond the Oracle paperwork · what exists vs. net-new · snapshot 0dc4059

## What this source is

A capture of `docs/strategic/NETSUITE_SUITEAPP_READINESS.md` (converted from `NetSuite-SuiteApp-Readiness.docx`, snapshot 0dc4059). It answers one question: setting aside the Oracle/NetSuite paperwork (SDN application, Built-for-NetSuite review submission, fees), what engineering would the product need to qualify as a SuiteApp?

**Verify current program terms before budgeting** — Oracle periodically reorganizes the SuiteApp / "Built for NetSuite" (BFN) program and its technical checklist. Confirm the current BFN technical-standard checklist against Oracle's present SuiteCloud Developer Network materials before committing engineering time.

## Two different targets hide inside "SuiteApp"

| | Target A — "Integrates with NetSuite" / SDN listing | Target B — true "Built for NetSuite" SuiteApp |
|---|---|---|
| **What it is** | An external app that connects to NetSuite via the API and is listed as a verified integration. | An app that runs INSIDE NetSuite — packaged via SDF, made of SuiteScript + NetSuite-native objects, installed as a bundle into the customer's account. |
| **Where the product is** | Most of the way there. The connector, OAuth1/TBA path, and governance pacer are the substance. Main gap: V3 (prove against production-tier, not sandbox). | Partially scaffolded. A real embedded-host bootstrap SuiteApp exists; a full native SuiteApp does not. |
| **Effort** | Small — mostly V3 + the partnership paperwork. | A real project — sized below. |

Most people who say "make it a SuiteApp" loosely mean Target A. The question worth engineering planning is Target B.

## What already exists toward Target B (more than expected)

The repo already contains a working embedded-host bootstrap SuiteApp — the bridge that renders SuiteCentral inside NetSuite. Real, tested, and proof-carded:

- **A real SDF manifest** — `platform/netsuite-suiteapp/manifest.xml`, a genuine SuiteCloud project manifest (projecttype=ACCOUNTCUSTOMIZATION, declares the Suitelet + server-side-scripting features).
- **A production-grade SuiteScript 2.x Suitelet** — `SuiteCentralHostSuitelet.js` uses the proper `define([...])` module pattern, reads runtime script parameters, is account-agnostic (handles sandbox `_SB1` → `-sb1` host normalization), hard-fails on non-https token transport, never echoes leaky response bodies, guards non-JSON responses, validates the returned path, and sandboxes the embedded iframe.
- **A symmetric Business Central AL extension** — a counterpart `business-central-extension/` so the embed model is dual-ERP.
- **Tests + a proof card** — adapter unit tests, an adapter-conformance Playwright spec, and `embedded-platform-adapters.md` (which honestly notes its ceiling: no production browser-bearer path yet; first install must record evidence).

The platform already solves the hardest architectural part of running inside NetSuite — a secure, account-agnostic, token-safe way to render the product inside the ERP UI.

## What is NOT yet there — net-new engineering for a full SuiteApp

The existing scaffold is an embedded iframe host. A full native SuiteApp — where the product's logic runs as NetSuite-native objects — is a larger build:

- **An architecture decision first (the biggest one)** — how much runs in-account as SuiteScript vs. stays in the external Node service? This split decision sizes the entire effort.
- **SuiteScript for anything that runs in-account** — User Event scripts, Map/Reduce batch work, RESTlets must be written in SuiteScript 2.x, not the platform's TypeScript.
- **In-account governance-unit compliance** — NetSuite meters in-account script execution in "governance units"; the existing GovernancePacer paces OUTBOUND calls, a different metering system from in-account governance.
- **BFN technical-standard conformance** — no hardcoded internal IDs, correct SuiteScript module patterns, no hardcoded URLs/credentials, correct role/permission use, proper logging, clean install/uninstall — measured by NetSuite's tooling.
- **Data-custody reconciliation** — the "we don't host client data" boundary between in-account SuiteScript and the external AI/DLP service must be redrawn so egress gates and PII handling still hold.

## Honest sizing — three tiers, not two

| Target | Status | Effort |
|---|---|---|
| A — SDN / "integrates with" | Close | Mostly V3 (production-tier connector test) + paperwork. Weeks, not a project. |
| B — embedded-host SuiteApp (frame the UI in NetSuite) | Largely built | Bootstrap Suitelet + SDF manifest + BC extension exist, tested. Remaining: a real install + recorded evidence (overlaps the pilot). |
| B+ — full native SuiteApp (logic runs in-account) | Real project, not started | Architecture split decision + SuiteScript for in-account logic + governance-unit compliance + BFN checklist conformance. |

## The Squire angle

If a full SuiteApp is ever pursued, it should be **Squire-led**. Squire builds SuiteApps already — PaymentCentral, CustomerCentral, and the other Central products live INSIDE NetSuite. Squire has the SuiteScript expertise, SDF tooling, SDN membership, and BFN-review experience in-house. The platform brings the AI/governance substance; Squire brings the in-account packaging muscle.

## Recommendation

- **For the pilot:** nothing more on the SuiteApp axis — the embedded-host bootstrap already renders the product inside NetSuite. Do V3 (it serves this too).
- **For Target A (SDN listing):** pursue opportunistically — mostly V3 plus paperwork; Squire's existing NetSuite relationship is the shortcut.
- **For Target B+ (full native SuiteApp):** defer until the pilot proves value, then scope as a Squire-led build; make the in-account-vs-external architecture decision deliberately.

Companion brief: [[sources/35-businesscentral-dynamics-readiness|Business Central / Dynamics readiness]].