# Node.js project assessment brief

Use this editable brief to agree the application boundary, the work an individual or company will own, and the evidence needed before an engagement. Complete it with the same information for each candidate. The fictional example and proposed assessment below are planning aids, not a completed project or a measured provider result.

Prepared by: [name and role]

Project / repository: [reference]

Date and decision owner: [date; name]

Technical reviewer: [name; available review time]

## 1. Define the work

| Question | Your answer |
| --- | --- |
| What user action or operational problem needs changing? | [one observable outcome] |
| What exists today? | [UI, API, database, workers, integration; owners] |
| Which clients use the backend? | [web, mobile, partners; confirmed or proposed] |
| What is inside this engagement? | [specific endpoints, jobs or maintenance work] |
| What is outside it? | [explicit exclusions and dependencies] |
| Which constraints are observed? | [payloads, duration, traffic, hosting; source/date] |
| What is still unknown? | [question, owner and evidence needed] |

Fictional starting point: a customer portal needs an authorized customer summary combining a required record with optional recent activity. A future export may involve expensive computation. The summary request belongs to this assessment; implementing the export does not. Document who would own that later job and what measurements would inform its placement.

## 2. Assign application responsibilities

Node.js is a runtime; Next.js is a React application framework that can use it. A separate Node service is an architecture choice, not an automatic requirement for every Next application.

| Responsibility | Current owner / deployment | Proposed owner | Evidence or unresolved question |
| --- | --- | --- | --- |
| UI and rendering | [ ] | [ ] | [static/build-time or request-time needs] |
| Browser-facing requests | [ ] | [ ] | [authorization, validation, errors] |
| Shared API and business rules | [ ] | [ ] | [clients and release responsibilities] |
| Background or CPU-heavy work | [ ] | [ ] | [duration, isolation, recovery] |
| Data and external integration | [ ] | [ ] | [record authority, timeouts, limits] |
| Runtime, deployment and incident response | [ ] | [ ] | [host constraints, rollback, operator] |

Record the reason for keeping or separating each responsibility. Include the cost of another deployment, interface and monitoring path. A proposal must fit the chosen host's actual process, storage and connection constraints.

## 3. Record runtime observations separately from declarations

Run these inspection commands in the relevant project directory where Node and npm are available:

```sh
node --version
node -p "process.version"
node -p "process.execPath"
npm --version
npm pkg get engines packageManager type scripts
```

The first three identify a newly launched Node process. npm has its own version. The final command reads manifest fields; it does not execute scripts, install dependencies or prove compatibility. Confirm directory/workspace selection. Keep executable paths within your team when they disclose internal structure, and do not paste credentials or whole environment/configuration dumps into this brief.

| Context | Observed Node / executable | Observed npm | Declared requirement | Checked when / by whom |
| --- | --- | --- | --- | --- |
| Developer terminal | [ ] | [ ] | [ ] | [ ] |
| IDE task | [ ] | [ ] | [ ] | [ ] |
| CI or build container | [ ] | [ ] | [ ] | [ ] |
| Deployed service | [runtime diagnostic or startup record] | [if relevant] | [ ] | [ ] |

A terminal probe does not inspect an already-running service. Choose a compatible supported release line using the project's requirements and the [Node release schedule](https://nodejs.org/en/about/previous-releases); record the tests and build needed before changing it.

## 4. Propose a bounded paid assessment

Agree compensation, time limit, permitted tools and review criteria before work begins. Use synthetic data and provided local dependency stubs. Supply the starter project, synthetic identity helper and authorization contract so the assessment measures the intended Node work rather than an undocumented setup task.

Proposed task: implement or repair an authorized customer-summary endpoint that calls the stubs. The customer must belong to the identity's workspace. Define the response contract and finite request deadline in the brief. This is a proposed exercise, not code supplied or tested by this document.

| Case to prepare | Evidence requested |
| --- | --- |
| Authorized request with valid upstream response | Correct bounded response and a reproducible test. |
| Missing authority or a resource outside the caller's scope | Denial before reading protected upstream data; no secret leakage. |
| Malformed input or invalid upstream payload | Defined error behavior; tests identify the relevant boundary. |
| Required customer data fails or exceeds its deadline | Agreed error, bounded client response, and an explanation of cancellation versus continued work. |
| Optional activity fails | Explicit activity-unavailable marker, distinct from a successful empty activity list. |
| Repeated or overlapping reads | Explanation of connection/concurrency limits and any tested behavior; no invented load claim. |

Ask the candidate to explain how expensive synchronous work could delay other requests, why `async` alone does not move computation to another thread, and how a future export might change the design. Keep writes, retrying side effects, billing, real credentials and a production rollout outside this exercise unless separately scoped.

Record: [commit], [runtime], [run instructions], [actual test output], [known limits], [reviewer questions]. Distinguish an observed result from a proposed improvement. An assessment does not establish production load, security or full operational readiness.

## 5. Compare delivery ownership

| Responsibility | Client | Individual / provider | Evidence to request |
| --- | --- | --- | --- |
| Requirements and acceptance | [owner] | [owner] | [same bounded brief and acceptance record] |
| Code review and technical decisions | [owner] | [named role] | [review example; escalation path] |
| Dependency and runtime maintenance | [owner] | [owner] | [upgrade, compatibility and recovery process] |
| Deployment and incidents | [owner] | [owner] | [logs/metrics, alert recipient, rollback instructions] |
| Access, source and handover | [owner] | [owner] | [organization-owned access; reproducible setup] |

For a company, request the proposed team roles and responsibility split rather than relying on a public service page or company-wide résumé. Record substantiated experience, unanswered questions and commercial assumptions separately. Compare equivalent scope before comparing price.

Decision: [proceed, revise the scope, request evidence or stop]

Reason and evidence: [ ]

Next action, owner and review date: [ ]

Related guides: [Node.js companies](https://nomadicsoft.io/blog/top-node-js-development-companies), [hiring Node.js developers](https://nomadicsoft.io/blog/tips-to-hire-node-js-developers), [Node.js and Next.js architecture](https://nomadicsoft.io/blog/node-js-vs-next-js-choosing-the-best-framework-for-backend-development), and [checking Node.js versions](https://nomadicsoft.io/blog/master-node-js-quick-guide-to-check-node-version-from-the-command-line).