Build vs Buy: What Building Proctoring In-House Costs

The easy part is a trap

Opening a webcam in the browser takes a few lines, and a demo that shows the candidate’s face in a corner looks like proctoring. It is not. A demo is not a system that has to produce a defensible verdict on an exam a candidate may contest. Judging the build on how quickly you can show a camera feed is how teams underestimate the work by an order of magnitude, because none of the expensive parts are visible in that first demo.

A useful way to frame the decision is the first question in this series: whether you need an LMS plugin, a browser SDK, or a REST API. Build-versus-buy is the same question one level up. If none of the integration surfaces fit, you are considering building the whole thing, and the parts below are what that means.

How small the integration is when you buy it

It helps to see the other side concretely. The entire browser-side integration when you buy it is one call to create a session and one to start it. Your backend mints the session with your API key, which never enters the browser, and reads the finished report afterward.

// The entire browser integration when you buy it.
import { ProctorLink } from '@proctorlink/sdk';

const session = ProctorLink.createSession({
  jwt: sessionJwt,   // session_jwt from POST /v1/sessions
  sessionId,         // session_id from the same response
});

// Safety net if the token outlives the exam: re-mint the SAME attempt_id
// (which resumes the same session) and hand the new token back.
session.on('token-expired', async () => {
  const { session_jwt } = await mintSession({ attempt_id: attemptId });
  session.updateToken(session_jwt);
});

await session.start();   // camera up, keyframes and events flowing

// when the attempt finishes:
session.stop();
session.destroy();

The server-to-server side is two calls: mint, then fetch. The browser only ever holds a short-lived token scoped to one attempt, so there is nothing for a candidate to lift.

// Your backend mints a session. Your API key never enters the browser.
POST /v1/sessions
access-token: <YOUR_ACCESS_TOKEN>
secret-token: <YOUR_SECRET_TOKEN>
content-type: application/json

{
  "external_user_id": "user-9f3c1a",   // your opaque ID, not a name or email
  "exam_id": "math-101-final",
  "attempt_id": "attempt-789",          // stable per attempt, enables resume
  "allowed_origins": ["https://exams.yourcompany.com"]
}

// After the attempt, fetch the finished report from your backend.
GET /v1/sessions/6a7b18df70e4f8ecf2597b6f

That is the whole integration surface. Everything in the subsystem table above sits behind these calls, maintained by someone else. For the full version of this integration in a framework, see how to add proctoring to a web application.

Build versus buy, concern by concern

Set side by side, the trade is clearer. Building gives you full control and a permanent maintenance bill. Buying trades some control for a surface you can integrate against in an afternoon and never have to patch when a browser changes.

The camera-permission row is a good example of value that is invisible until you hit it. ProctorLink mounts a cross-origin iframe enclave, and the camera permission binds to that enclave origin, so a candidate who has granted it once is not re-prompted on the next site that embeds it. Build it yourself and every customer domain prompts afresh. The reasoning is in why proctoring runs in a cross-origin iframe.

The compliance bill does not stop

The moment you capture a face, you are processing biometric data, and that obligation outlives any single release. Facial images and the face templates derived from them are biometric data under India’s DPDP Act, GDPR Article 9, and Illinois BIPA, the last of which carries statutory damages assessed per violation. Build the system yourself and you own all of it: explicit pre-capture consent, a chosen and documented retention period, honouring deletion requests, data minimisation, and a documented list of every sub-processor that touches a frame.

Buying does not remove this obligation, but a platform designed for it is built to support the parts you control: an opaque external_user_id so you are not handing over names or emails, periodic keyframes instead of continuous video, and frames that upload straight to object storage rather than through an API. The full breakdown of what each law asks is in proctoring and biometric data: DPDP, GDPR Article 9, and BIPA. If you serve Indian institutions specifically, see online exam proctoring in India. And if your route to market is Moodle, the best Moodle proctoring plugin comparison shows the buy option as a plugin rather than an SDK.

So which should you do?

Build when proctoring is the product you sell, the differentiation is in the detection itself, and you can staff a team to own capture, models, browser compatibility, and compliance for as long as the product lives. Buy when proctoring is a feature that makes your real product more valuable, when time to market matters, and when you would rather integrate against a maintained surface than carry a permanent detection-and-compliance team.

Across published deployments, ProctorLink has supported more than one million proctored exam sessions (methodology note below). Full cohort sizes and outcomes are on the case studies page, and the whole developer series starts from the knowledge hub.