Skip to main content

Company

We build assessment software and then run it

Most of the difficulty in assessment is not in building the platform. It is in the week it has to work.

Vision

Assessment that measures what it claims to

A score is a claim about a person, and it is used to make decisions about them — whether they qualify, whether they are hired, whether they can practise. That makes the software underneath it consequential in a way most software is not.

Our interest is in the gap between what an assessment intends to measure and what it actually measures. Interfaces that get in the way, items that do not discriminate, integrity controls that punish the wrong people: all of these are measurement defects, and all of them are engineering problems.

  • Accessibility treated as validity, not compliance
  • Integrity controls proportionate to the stakes
  • Evidence that survives being questioned

Mission

Be the team that is still there in exam week

The commercial model most assessment work uses — build, hand over, invoice, leave — puts the supplier's incentive at exactly the wrong point. Whoever built the system is gone before the first real sitting, and the institution discovers what was deferred at the worst possible moment.

We would rather stay on and be accountable for the thing running. It is a smaller business and a slower one, and it is the only version of this that we think is honest.

History

How we got here

TODO: dates are unconfirmed — see data/timeline.ts.

  1. TODO

    Seratlas founded

    TODO: what the company was set up to do, and what made it worth doing then.

  2. TODO

    First assessment platform in production

    TODO: the first system that ran a real sitting, and what it taught us.

  3. TODO

    Quizlyne launched

    TODO: what Quizlyne is, who it is for, and what it replaced.

  4. TODO

    Where we are now

    TODO: the current focus, stated plainly enough that it dates itself.

What that means in practice

Three consequences

These are the decisions the two sections above commit us to.

Small on purpose

Nobody is between you and the person writing the code. That caps how much we can take on at once, and we would rather say no than staff a project with a layer of account management.

We stay for the windows

The engagement does not end at handover by default. Whoever built it is still reachable during the sitting, which is the only time the build is genuinely tested.

We write down what we decided

Scope, assumptions and the arguments against each choice, in a document you keep. It is also what makes a second supplier possible later, which is the point.

Process

Four steps, and what each one is for

Short enough that you can tell where a project is without asking.

  1. 1

    Understand the assessment

    1–2 weeks

    What is being measured, for whom, and what happens to someone based on the result. The consequences set almost every technical requirement that follows.

  2. 2

    Shape and estimate

    1–2 weeks

    A written scope with its assumptions listed, and the parts we think are riskiest called out — including anything we would advise against building.

  3. 3

    Build in the open

    Varies with scope

    Short cycles against a working environment you can use from the first one. No demo-only builds, and no first look at the end.

  4. 4

    Operate through the windows

    Ongoing

    Running it when it matters, which is the exam period and the fortnight either side. Handover is an option, not the default assumption.

Where we are

Global presence

TODO: this section currently describes four placeholder offices. See data/offices.ts.

Countries with active users
TODO
Languages supported
TODO
Data residency regions
TODO
Support coverage
TODOTODO: hours, and in which zones
Team members
TODO

Regions we cover

  • TODO: City 01
  • TODO: City 02
  • TODO: City 03
  • TODO: City 04

Scoping

Start with the assessment, not the software

Tell us what is being measured and what depends on the result. That conversation is more useful than a feature list, and it is free.

  • A written scope you can circulate internally
  • The assumptions the estimate depends on, listed
  • An honest view on whether to build at all

Tell us what you are trying to deliver

A short description is enough to start.