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.jsuses the properdefine([...])module pattern, reads runtime script parameters, is account-agnostic (handles sandbox_SB1→-sb1host 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: Dynamics readiness.