What Humanness is built on, why those choices were made, and what they mean for the people who will use it. Written for a technical reader, and readable by a non-technical one.
Humanness is not a survey tool with a chart bolted on. It is a measurement platform, and the engineering underneath it was chosen so that the experience stays fast for the person answering and the numbers stay trustworthy for the person acting on them.
The whole stack on one page, and the four principles behind it.
React, server rendering, streaming, and why the assessment feels instant on a five year old phone.
Node.js, TypeScript end to end, and the class of failure that never reaches production.
PostgreSQL, a typed data access layer, and a scoring engine that is deterministic and tested.
Where the models sit, what they are given, and what happens when a model is unavailable.
A single design system, WCAG conformance, and full localisation.
Containers, regions, horizontal scale, and what happens when a release goes wrong.
Testing, review, and how a change gets from a keyboard to your users.
What you need to run it, how it connects to what you have, and where it is going.
Humanness is a modern cloud native web platform, built on the same technology foundations used by the largest consumer products in the world, and deployed as a fully managed service. Nothing needs to be installed by you.
| Layer | Technology |
|---|---|
| Interface | React 18, with a component driven architecture and accessible primitives built on Radix UI. |
| Rendering | A hybrid server and client rendering engine with React Server Components, streaming responses and route level code splitting. |
| Runtime | Node.js, running the same language on the server and in the browser. |
| Language | TypeScript end to end, with strict type checking enforced in the build. |
| Data | PostgreSQL, accessed through a fully typed data layer with versioned migrations. |
| Intelligence | Frontier large language models, called server side over streaming APIs. |
| Presentation | A tokenised design system with a declarative styling engine, plus a composable charting layer. |
| Delivery | Containerised immutable builds, deployed to regional infrastructure behind a global edge network. |
Response rates fall when a page takes too long. Work is done on the server so the phone in someone's hand does as little as possible.
Types, schemas and tests are structured so that a whole category of mistake cannot reach a build, let alone a user.
The database, the runtime and the deployment model are deliberately proven technology. Novelty is spent on the product, not the plumbing.
No servers, no agents, no client software, no database for your team to maintain. A browser is the entire requirement.
The interface is built in React, the component library that powers Facebook, Instagram, Netflix, Airbnb and a large share of the modern web. React is used here not for fashion but because a measurement product is full of state, and React is the most rigorously proven way to manage it.
Many web products send an empty page and a large bundle of JavaScript, then ask the browser to assemble the interface. That is why so many tools feel slow on a mid-range phone. Humanness works the other way around. Pages are rendered on the server and streamed to the browser as finished markup, so the first thing a person sees is real content rather than a loading spinner.
Components that execute only on the server. Their code is never sent to the browser at all, so the download shrinks and data access stays behind the server boundary.
The page is delivered progressively as it becomes ready, so a slow section of a dashboard never holds up the rest of the screen.
A person taking an assessment never downloads the reporting or administration code. They receive only the part of the product they are using.
Charts, filters and the assessment flow are fully interactive on the client, with no page reload between questions.
An engagement measurement is only as good as its response rate, and response rate is sensitive to friction in a way most buyers underestimate. Every second of load time costs completions, and the people most likely to abandon are often the ones on the oldest hardware, the weakest connection, or the factory floor rather than the head office. Rendering on the server is how we keep those voices in the dataset.
An assessment that begins immediately, moves between questions without a visible page load, saves progress as they go so a closed tab loses nothing, and works identically on a laptop, a tablet and a phone.
Core flows are built on standard web form submissions handled by server actions, and then enhanced with client side interactivity. The practical consequence is that the critical path does not depend on JavaScript having finished loading. If a person on a poor connection submits before the page is fully interactive, the submission still works correctly rather than failing silently or losing their input.
| Technique | Effect |
|---|---|
| Automatic image optimisation | Modern formats, correct sizes per device, and lazy loading below the fold. |
| Self hosted subset fonts | No third party font request, no layout shift as text swaps, and no external dependency in the critical path. |
| Edge caching | Static assets served from a location near the user, globally. |
| Prefetching | The next likely route is fetched in the background so navigation is immediate. |
| Indexed query paths | Reporting queries are written against composite indexes so a dashboard stays fast as history accumulates. |
The current and previous two major versions of Chrome, Edge, Safari and Firefox, on desktop and mobile. The product is responsive rather than a separate mobile build, so there is one codebase, one behaviour and one release to validate. Reduced motion preferences are honoured, so animation is suppressed for anyone who has asked their operating system to suppress it.
People complete assessments in the browser they already have, from a link. There is no app store approval, no mobile device management policy to negotiate, and nothing for your service desk to deploy.
Humanness runs on Node.js, the server runtime behind a large share of the world's web infrastructure, and is written in TypeScript from the database boundary to the last button.
Because the same language runs on the server and in the browser, validation rules, scoring logic and data shapes are written once and used in both places. In products that split languages across the boundary, the same rule gets implemented twice and the two copies drift apart. That drift is a common source of the quiet defect where a screen shows one number and an export shows another.
If a database field is renamed, every place that reads it fails to compile. It does not fail later, in front of a user, as an empty value on a dashboard.
Values that may be absent are typed as such, so the code is forced to decide what happens when a person skipped an optional question rather than producing a nonsensical average.
Roles, assessment statuses and dimension names are modelled as fixed sets rather than free text, so an impossible value cannot be written at all.
Every request boundary is guarded by a runtime schema whose types are derived from the same definition, so validation and typing cannot disagree.
Type safety is usually presented as a developer convenience. Its real value to you is the change it makes to the cost of change. When a platform can be modified confidently, it keeps improving after purchase, and problems get fixed in days rather than being deferred into a release note. A codebase nobody dares touch is the most expensive thing a software vendor can hand you.
Type checking runs in the delivery pipeline and a failure blocks the merge. It is not a linting suggestion an engineer can wave past on a busy afternoon.
The data layer is where a measurement product either earns trust or quietly loses it. Ours is built on PostgreSQL, the relational database with the strongest reputation for correctness in the industry, accessed through a fully typed query layer.
Every change to the data model is a versioned migration, held in source control, reviewed like any other code, and applied in the same order in every environment. There is no manual alteration of a production database, which means the schema in front of your data is always the schema that was reviewed and tested.
Queries are generated from the schema, so the shape of every result is known at compile time and a renamed column cannot silently return nothing.
All values are bound rather than concatenated into query strings, which removes the standard route to SQL injection.
Reporting paths are indexed against the columns they actually filter and sort on, sized for organisations well beyond current customers.
Database connections are pooled so a burst of survey traffic does not exhaust the database, which is the classic cause of a launch day outage.
The scoring engine is the part of this platform we are most careful with, because it is the part your decisions will rest on. It converts individual responses into dimension scores, section readings, and the gap between how an organisation and a team are experienced.
The same responses always produce the same scores. No randomness, no model call, no dependency on when the calculation happened to run. A number can be recomputed and audited.
The engine is a standalone module with no knowledge of screens, so reporting, exports and the dashboard all read from one implementation. There is no second version of the maths anywhere.
The threshold behaviour, the small sample rules and the edge cases around partial responses each have explicit tests. Those are exactly the places a scoring engine misleads people, so they are the places we assert.
When methodology changes, the change is versioned and historical data is migrated deliberately rather than reinterpreted silently. Your trend line stays a trend line.
Results can be exported to spreadsheet formats for your own analysis, and structured data is available for a data warehouse where you want Humanness readings alongside other people metrics. Exports honour the same suppression rules as the interface, so exporting is not a route around the privacy guarantees.
Assessment content, dimension definitions and the interpretive guidance attached to a reading are held as structured, versioned content rather than hard coded strings. That is what allows a dimension to be renamed for your context, an assessment to be translated, or interpretive language to be tuned without an engineering release.
Humanness uses frontier large language models for two purposes: a private reflective companion for individuals, and drafting suggested actions for administrators. Both are additive. Neither is load bearing for measurement.
Any system that depends on a third party inference API will occasionally see that API slow down or fail. We treat that as an expected condition rather than an incident. Model calls have timeouts, failures are caught and reported to the user as a plain message rather than a broken screen, and no assessment, score, dashboard or export depends on a model being available. If every AI feature were switched off tomorrow, the measurement platform would work exactly as it does today.
Inference is behind an internal interface, so the underlying model can be upgraded or replaced without touching product code. We are not welded to one provider's roadmap.
AI endpoints are authenticated, entitlement checked and rate limited, so a scripted client cannot generate unbounded inference spend.
Language models are used to help a person interpret and act. They are never used to calculate a score, decide anything about an individual, or generate a number that appears in reporting. Measurement is arithmetic, and arithmetic is not a job for a model.
A workforce product is used by everybody in a workforce, which is a wider range of people, devices and abilities than most software has to serve. The presentation layer is built for that range rather than for a demo.
Colour, type, spacing and radius are defined once as design tokens and consumed everywhere through a declarative styling engine. A change to the system propagates to every screen, which is why the assessment, the dashboard and the emailed invitation look like one product rather than three. Components are built on Radix UI, a library of accessible primitives that handles keyboard interaction, focus management and screen reader semantics correctly by default.
This matters beyond compliance. An inaccessible assessment does not merely inconvenience people, it removes them from your dataset, and the people it removes are rarely a random sample.
The platform is fully internationalised. Interface text, assessment questions, dimension definitions and interpretive guidance are all held in translation catalogues rather than embedded in code, and a person's language preference follows their account across sessions and devices.
English, French and Portuguese ship today. Additional languages are a content task rather than an engineering project, which is why adding one is measured in weeks rather than in a release cycle. Where a term has no clean equivalent, we translate the meaning with a native speaker rather than the words with a machine.
Humanness is delivered as a fully managed service on our own cloud platform. You provision nothing, patch nothing and monitor nothing. What follows is what sits behind the browser tab.
| Element | Detail |
|---|---|
| Compute | Containerised application instances built as immutable images. The artefact tested is the artefact that runs. |
| Scaling | Horizontal, with instances added under load. Survey launches are the peak event in this product and the platform is sized for them. |
| Edge network | A global content and TLS termination layer in front of the application, absorbing volumetric attack traffic before it reaches us. |
| Regions | Europe West, US East, US West and Asia Pacific. Your deployment is pinned to one, spanning multiple availability zones. |
| Data | A dedicated managed PostgreSQL instance per client, on a private network with no public address. |
| Certifications | Our hosting regions operate in facilities holding ISO 27001, SOC 2 Type II and PCI DSS attestations. |
Deployments are rolling. New instances are started, health checked, and only then does traffic move to them, so a release does not require a maintenance window and users do not see an interruption. If a health check fails the previous version keeps serving and the release is withdrawn automatically. Rollback is the default response to a bad change, not a last resort after an hour of debugging a live system.
Nothing operational. No firewall rules, no allow lists, no infrastructure. If your network filters outbound traffic, allowing our domain is the only technical prerequisite, and we will confirm it in writing during onboarding.
| Measure | Target |
|---|---|
| Monthly availability | 99.9 percent, externally measured |
| Recovery point objective | Under 1 hour, via point in time recovery |
| Recovery time objective | Under 4 hours for a full regional failure |
| Backup retention | 35 day rolling window, encrypted, in your region |
| Planned maintenance | No downtime window required for routine releases |
We monitor application health, error rates, response times, database performance and queue depth continuously, with alerting on trends rather than only on failure. The point is to notice a service degrading on a Tuesday afternoon, not to be told about it by a customer on Wednesday morning. Uptime is verified by external monitoring from outside our own infrastructure, because a service asking itself whether it is up is not a measurement.
Backups are automatic, encrypted with the same standard as live data, stored in your region, and tested by performing real restores on a quarterly cycle. Point in time recovery means a restore can target a moment rather than only last night, which is what you need after an accidental bulk change rather than a hardware failure.
The architecture is horizontally scalable at both the application and the reporting layer, and the reporting queries are indexed for organisations well beyond our current customer base. Practically, an assessment launch to twenty thousand people is a traffic pattern we plan for rather than an event we would need notice of, though we would still rather you told us so we can watch it with you.
The honest measure of an engineering team is not whether it makes mistakes. It is what the system does when one is made. This is how a change gets from a keyboard to your users.
Test effort is spent where a defect would be most damaging and least visible, rather than spread thinly for the sake of a coverage percentage.
Thresholds, small sample rules, partial responses and the organisation to team comparison. A wrong number here would be believed.
Who can see what, and the suppression rules that protect individuals inside aggregated results.
Expiry, single use, revocation and the reset flow, which are the routes an attacker would probe first.
That every translated surface actually resolves, so no user is shown a raw translation key or an untranslated fragment.
Non-obvious decisions are documented next to the code that implements them, including the reason and the alternative rejected. Product behaviour is documented as user flows, and support material is generated from the product itself so it cannot drift from what the software actually does. The intent is that the platform remains maintainable by people who did not write it.
What you need in order to run Humanness, how it connects to the systems you already have, and the direction of travel.
| Requirement | Detail |
|---|---|
| Client software | None. A current browser on any operating system. |
| Infrastructure | None. Fully managed service. |
| Network | Outbound HTTPS to our domain. No inbound access, no VPN, no fixed IP. |
| Ability to receive invitations from our sending domain. We will give you the records to allow list if your gateway is strict. | |
| Identity | Optional. Federation with your directory if you want it, direct login if you do not. |
| Your effort | A member list and a decision about departments. That is the extent of technical onboarding. |
We would rather do a small number of integrations properly than list twenty logos. If you need a specific connection, tell us during onboarding: it is usually a scoping conversation rather than a roadmap request.
You are buying a platform that will keep changing after the contract is signed, so it is fair to ask what governs those changes. Three commitments, and then what we are actually working on.
We will not change scoring methodology in a way that silently rewrites your history. Methodology is versioned, changes are announced, and historical data is migrated deliberately so a trend line stays comparable.
No release will widen what an administrator can see about a named individual. That boundary is the product, and it is not a feature we will trade for a competitive checkbox.
If something you have asked for is not planned, you will hear that rather than see it parked indefinitely on a roadmap slide. Clear disappointment is more useful to you than vague encouragement.
This document covers how the platform is built. The privacy volume covers what we do with personal data, including what our AI systems are and are not given. The security volume covers identity, authentication and the controls behind both. Between them they should answer a full procurement review. Where they do not, ask us directly and we will answer specifically rather than sending a brochure.