Your SuiteScript, reviewed and graded. $1,500 flat, delivered in writing.
A senior engineer reads your scripts line by line and scores them across five categories — performance, governance-limit exposure, SuiteScript 2.0→2.1 migration debt, error handling, and security. You get a written, prioritized findings report. No live call, no sales pitch attached to the results.
One submission, five scored categories, one written report.
Send the scripts you want reviewed — a Suitelet, a User Event script, a RESTlet, a related family of scripts. An engineer holding SuiteFoundation and SuiteCloud Developer certification reads the source and grades every finding against a fixed rubric, not a generic linter pass.
Performance
Query patterns — SuiteQL vs. saved search vs. record.load loops — search paging, submitFields opportunities, and any per-record work that should be batched.
Governance limits
Per-script-type unit budgets, concurrency exposure under load, and whether unbounded loops carry a getRemainingUsage() guard.
2.0→2.1 migration debt
@NApiVersion headers and module syntax, and which scripts are realistic runtime-preference candidates versus scripts that need a real rewrite.
Error handling
try/catch coverage on every external call and record write, retry behavior, and what happens to a batch when one record in the middle fails.
Security
Authentication pattern, role and permission checks on externally reachable Suitelets and RESTlets, hardcoded internal IDs, and unvalidated external input.
How the review is graded.
Every finding gets logged against one of the five categories above, then scored on a fixed severity scale so the report reads the same way regardless of who wrote the code or how large the submission is. The scale exists to answer one question for each finding: does this need to be fixed before deployment, on the next release, on the standard backlog, or opportunistically.
Will fail in production at realistic volume, or exposes the account to unauthorized changes. Fix before deployment.
Fails or corrupts data under conditions that are common, not edge cases. Fix on the next release.
Doesn’t fail today, but costs real governance, execution time, or portability. Fix on the standard backlog.
Style, hygiene, and missing-guard findings that don’t change behavior yet. Fix opportunistically.
What the graded report actually looks like.
Sample report — built from a synthetic code sample for illustration. The snippet below was written to show the grading format, not pulled from a client engagement; nothing on this site is presented as a case study. Your report reviews your own SuiteScript.
The sample is a Suitelet that loads every open sales order in a loop and flags a subset for follow-up. It’s written to carry a handful of textbook issues — the kind a graded review is built to catch.
/**
* @NApiVersion 2.0
* @NScriptType Suitelet
*/
define(['N/record', 'N/search', 'N/https'], function(record, search, https) {
function onRequest(context) {
var orderSearch = search.create({
type: 'salesorder',
filters: [['status', 'anyof', 'SalesOrd:B']],
columns: ['internalid', 'entity']
});
var results = orderSearch.run().getRange({ start: 0, end: 1000 });
for (var i = 0; i < results.length; i++) {
var orderId = results[i].getValue('internalid');
var so = record.load({ type: record.Type.SALES_ORDER, id: orderId });
if (so.getValue('entity') === '4821') {
so.setValue('custbody_priority_flag', true);
}
so.save();
https.get({ url: 'https://hooks.example.com/notify?order=' + orderId });
}
context.response.write('Processed ' + results.length + ' orders.');
}
return { onRequest: onRequest };
});| Severity | Category | Finding | Why it matters |
|---|---|---|---|
| CRITICAL | Governance limits | record.load() inside an unbounded search-result loop. | Each call costs 10 units against a 1,000-unit Suitelet budget. At the search’s own 1,000-row cap, the loop requests roughly 10× its available governance and dies mid-batch with no checkpoint. |
| HIGH | Error handling | No try/catch anywhere in the request handler. | One record failing so.save() — a locked period, a missing mandatory field — throws an unhandled exception and stops the script for every order still queued behind it, with no partial-success record. |
| HIGH | Security | Writes triggered with no request-method or permission check. | onRequest mutates sales orders without checking context.request.method or asserting a role first. Deployed with a permissive access setting, this turns a URL into a mass-write endpoint anyone holding the link can trigger. |
| MEDIUM | Performance | getRange({start:0, end:1000}) silently truncates. | getRange() hard-caps at 1,000 rows per call. Past that count of open orders, the script processes the first 1,000 and returns as if it finished — no error, no log entry, no completion flag. |
| MEDIUM | Performance | Synchronous https.get() fired inside the per-record loop. | One external HTTP call per order, no batching, timeout, or retry/backoff. A slow response from the notification endpoint stalls the entire loop; a hard failure there isn’t caught either. |
| MEDIUM | 2.0→2.1 debt | @NApiVersion 2.0 header, function-expression module pattern. | A candidate for the 2026.1 “run 2.0 scripts on the 2.1 engine” validation path, but not opted in or tested against it, and carries none of the const/let/arrow-function syntax the rest of a modern codebase should share. |
| LOW | Governance hygiene | No runtime.getCurrentScript().getRemainingUsage() guard. | The loop’s iteration count isn’t fixed in advance and has no way to detect an approaching governance ceiling and stop cleanly or reschedule — the standard guard for this pattern is absent entirely. |
| LOW | Maintainability | Hardcoded internal ID (‘4821’); load+setValue+save for one field. | An internal ID won’t match across a sandbox refresh or a production/sandbox pair. Separately, load-then-save for one field costs three times the units of the equivalent record.submitFields() call (30 vs. 10 for a transaction record). |
What you get back.
Written findings report
Every finding scored Critical/High/Medium/Low, with the line reference it lives on and a specific fix recommendation.
Prioritized fix list
Ordered by severity, so if nothing else gets touched this quarter, you know what to schedule first.
Recorded video walkthrough
A short Tella recording narrating the top findings on screen, in place of a call — watch it whenever, replay the parts that matter.
NDA on request
Signed before anything changes hands, at no charge and no delay to scope confirmation.
Frequently asked questions.
What do we actually send you for the review?
Export or share the scripts you want graded — a folder of .js files, a zipped SDF project, or read access to the file cabinet folder they live in. No login credentials to your account are required and none are requested; the review works entirely from script source, not from live production data.
Is $1,500 the whole price, no matter how much code we send?
$1,500 covers one submission reviewed as a single pass — typically a script or a related family of scripts, such as a Suitelet plus the User Event script it triggers. Larger submissions, like a full custom-record framework or a dozen unrelated scripts, are scoped per engagement and quoted within 24 hours of seeing what’s in scope, before anything is charged.
Do you need access to our NetSuite account?
No. The review reads script source, not your live account. Sharing a sandbox file cabinet link instead of pasting code into an email works fine, but production login access is never requested and never required to complete a review.
How long does it take to get the report back?
Turnaround depends on how much code is in scope, so it’s scoped per engagement and quoted within 24 hours of receiving your scripts — alongside written confirmation of exactly what’s being reviewed. That estimate comes back in writing; no call is involved in getting it.
Do we get a call to walk through the findings?
No — everything here is async by design, including the largest submissions. Scope gets confirmed in writing, the report is a written document with line-level references, and a short recorded video walkthrough narrating the top findings is included so nothing gets lost the way it can on a live call.
Who actually performs the review?
An engineer holding SuiteFoundation and SuiteCloud Developer certification reads every script line by line. The grading, prioritization, and fix recommendations in the report reflect a human read of your specific code, not an automated linter pass handed back as-is.
If the report finds critical issues, are we obligated to hire SoftXone to fix them?
No. The report is a standalone deliverable — findings, severity, and fix recommendations written clearly enough for your own team or another developer to act on. If you’d like SoftXone to implement the fixes, that’s scoped and quoted separately at standard developer rates; it’s never bundled into the review price or implied as a required next step.
What if our scripts are a mix of SuiteScript 1.0, 2.0, and 2.1?
That mix is common and the review covers all three. 1.0 and 2.0 scripts get flagged for migration debt specifically, with a note on which are realistic candidates for an incremental move and which need a rewrite. Each script is graded against what’s realistic for its current version — the report calls out version debt separately rather than failing everything against a 2.1-only standard.
Can we see what the report actually looks like before paying?
Yes — the sample report on this page is built from a synthetic SuiteScript snippet written specifically to demonstrate the grading format: severity, category, finding, and rationale, the same structure your own report follows. It isn’t excerpted from a real engagement; real reviews are never shared without the client’s permission, which is also why nothing on this site is presented as a case study.
Getting started.
Send the scripts. Get scope confirmed in writing within 24 hours, and a graded report back on a timeline quoted within 24 hours of receiving them.
Start the conversation →