How we build

The way we build, written down.

These are the practices behind every Varynt product. They are also what we bring to software we build for clients.

Product

Start from the workflow: A product begins with the job someone does all day: a receptionist on a call, an account manager waiting on a client's approval. The screens follow that job, in that business's words. Desk, for example, is set up with your own questions and labels rather than ours.
One product, one job: We would rather make four products that each do one job well than one that does everything badly. They share what should be shared: who your people are and how they sign in.
Say what is not built: If a feature is planned, it is listed as not available yet, with no date we cannot keep. Nothing on our sites is a promise dressed as a feature.

Access is decided on the server: Every request is checked against the person's role and the organization it belongs to. Hiding a button is never the control.
Each product owns its data: Every product keeps its own records and decides access to them itself. Nothing passes between products unless you connect them.
Messages are not fire-and-forget: In Work, Desk and Invoice an email is recorded before it is sent and retried if the mail relay is down, so a notification is never silently lost.
Tests that do not depend on luck: Automated test suites run in more than one order, so a test that only passes because another ran first is caught before release.

Releases with a way back: Before a release changes anything, the databases are backed up and the backup is restored and checked. Every step can be rolled back.
Documentation is part of the product: Every product has public documentation, written alongside the software: 155 pages today.
Fast, accessible public pages: Our sites are prerendered HTML, readable with scripts off, keyboard-navigable and measured before they ship.

Get in touch

Our engineering team takes on custom projects with the same practices we use on our own products.