How Altivane Is Built

A process decides what ships

Much of Altivane's code was written with AI, the same way many engineering teams now work. What matters is what happens next. Nothing goes in because it looked right; it goes in because it was reviewed and passed every check.

Every change is reviewed and tested

• Every change is reviewed before it's merged. Changes that write to a tenant, handle licensing or sign you in get a second, separate review.
• An automated test suite runs on every change: the engine, the reports, the documents, the workflows, and each page of the app.
• The build fails on a single warning, and code that hasn't passed the full check can't be published.
• A bug fix starts with a test that proves the bug exists, and that test stays, so the bug can't come back.

An overshare: tests make up nearly half of Altivane's code. It's boring, but we did it.

Tried on test tenants first

• Every screen is built and checked against a made-up demo company first.
• New reads are tried against real Microsoft 365 tenants, read only, before they ship.
• Changes are tried in a test tenant, on test objects made for the purpose, before they reach a release.

Careful by design

• Altivane runs on your computer, and your tenant data stays there. Nothing from your tenants is sent to us.
• It signs in with Microsoft's own sign-in, and asks only for the access each part needs.
• Every change it makes is written to the tenant's change log: who made it, when, and the values before and after.

Questions

If you'd like to know more about how something works, email info@altivane.com.au. The Security page covers access, sign-in and where data stays.