Your website, not a black box.
Every client gets a portal. Watch your build move stage by stage, message us without digging through email, keep your brief in front of you, and settle invoices in one place.
Everything about your site, in one place.
Your build, stage by stage
Nine stages, from discovery through to care after launch, laid out end to end. You can always see which one you are in, what is happening inside it, and what we need from you to move on.
Your brief, in your words
Tell us about your business once, in the portal, and it stays there for the whole project. Change it whenever something shifts and your team sees the update straight away.
Messages, not email threads
Talk to us in the portal. Everything about your project lives beside the project, not scattered across inboxes.
Reports you can read
On a care plan, you get a report on what your site is doing, in plain English. No dashboards you need training to interpret.
Invoices and payments
See what is owed, what is paid, and settle it without chasing a PDF through your email.
Care after launch
On a care plan, the portal is where you see what has been done to keep your site healthy.
The portal runs on our own platform.
Your project details, your contact information and your invoices live in software we built and run ourselves, in Australia. Here is exactly how it is protected. We publish the architecture because knowing it does not help anyone bypass it.
Argon2id Password Hashing
Passwords are hashed with Argon2id, a memory-hard algorithm designed to resist GPU and ASIC attacks. A server-side pepper is mixed in before hashing, so even if the database is stolen, breach databases and rainbow tables are useless. Every password is also checked against the Have I Been Pwned database in real time.
AES-256-GCM Field Encryption
Every sensitive data field (names, phone numbers, email addresses, business numbers, credentials) is individually encrypted using AES-256-GCM before it reaches the database. Each data category uses a separately derived encryption key, so compromising one category cannot expose another.
Mandatory Two-Factor Authentication
Every account requires a second form of verification. No exceptions, no opt-outs. We support TOTP authenticator apps, FIDO2/WebAuthn passkeys and hardware keys, and email verification codes. Backup codes are individually hashed. High-security actions like changing your password require TOTP or a passkey.
Immutable Audit Trails
Every data change (create, update, delete) is permanently logged with the timestamp, user identity, IP address, and the exact old and new values. Every login attempt (success and failure) is recorded. No entry can be edited, deleted or suppressed, and no API exists to do it, not even for administrators. Erasing an entire organisation under the Privacy Act is the one thing that removes its trail.
Database-Level Tenant Isolation
Your data is isolated from every other business using PostgreSQL Row-Level Security policies enforced at the database engine level. Every table is scoped to your organisation. Cross-tenant queries are architecturally impossible through the application layer.
Real-Time Security Monitoring
The platform continuously scans for brute force attacks, credential stuffing, session anomalies, and 2FA abuse. Suspicious IP addresses are automatically blocked. Account lockouts, progressive login delays, and rate limiting work together to stop attacks before they succeed.
The full security architecture
We don't believe in security through obscurity. These are open, auditable standards, and knowing the algorithms doesn't help bypass them. The security comes from the keys, not from keeping the method secret.
Password Security
Passwords are the first line of defence. We treat them accordingly: hashed with the strongest available algorithm, checked against known breaches, and enforced with strict policies.
- Argon2id hashing: memory-hard, resistant to GPU and ASIC brute-force attacks
- Server-side pepper mixed in before hashing: breach databases are useless even with a full database dump
- Real-time Have I Been Pwned (HIBP) checking on every password change using k-Anonymity (only the first 5 characters of a SHA-1 hash are sent, never the password itself)
- 12-character minimum, and a password must satisfy at least four of five checks: lowercase, uppercase, number, special character, or a length of 15 and over
- Password history: your last 5 passwords cannot be reused
- 90-day password age policy, configurable per organisation, which prompts you to set a new password at your next sign-in
- Progressive delays between failed login attempts: each failure increases the wait
- Automatic account lockout after repeated failures
Data Encryption
Sensitive data is encrypted at the field level before it reaches the database. Even with full database access, an attacker gets meaningless ciphertext without the encryption keys.
- AES-256-GCM authenticated encryption: the same standard used by governments and financial institutions worldwide
- HKDF (HMAC-based Key Derivation Function) generates a separate encryption key for each data category from a single master key
- Key categories include: identity (names), contact details (phone, email), billing information, authentication secrets, addresses, credentials, and communications
- Compromising one key category does not expose data from any other category
- Every encrypted value uses a unique random nonce: identical plaintext values produce different ciphertext
- Encryption keys are stored in environment configuration, never committed to source code, and never logged
- Encrypted fields include: names, phone numbers, email addresses, ABNs, billing emails, TOTP secrets, API credentials, addresses, and communication records
Authentication & Sessions
Session tokens are never stored in plaintext. Every session is bound to a device, enforced with timeouts, and can be revoked instantly.
- Session tokens are hashed with SHA-256 before database storage: a stolen database reveals no usable tokens
- Auth tokens are httpOnly cookies: JavaScript cannot access them, preventing XSS token theft
- 5-minute access tokens with 7-day refresh tokens: short-lived access limits the damage window
- 30-minute inactivity timeout: walk away and your session locks
- Device fingerprint binding: sessions are tied to the browser and device that created them
- Maximum 5 concurrent sessions per user: the oldest session is automatically revoked when you exceed the limit
- Refresh token rotation: each refresh issues a new token and invalidates the old one, detecting theft if a stale token is reused
- Explicit session revocation: users and admins can kill any session immediately
Two-Factor Authentication
Two-factor authentication is mandatory for every user on the platform. There are no exceptions and no opt-outs. We support multiple methods to fit different security needs.
- Every new account starts with email verification codes for an initial 5-day grace period
- After 5 days, users must upgrade to a TOTP authenticator app (Google Authenticator, Authy, etc.) or a FIDO2/WebAuthn passkey
- WebAuthn support includes hardware security keys (YubiKey), biometric authentication (Touch ID, Face ID, Windows Hello), and platform authenticators
- Backup codes are generated for account recovery: each code is individually hashed with SHA-256 before storage, so a database breach reveals no usable codes
- TOTP replay protection: the same code cannot be used twice within its time window
- High-security actions (password changes, 2FA configuration, session management) require re-verification with TOTP or a passkey, not just a session cookie
Tenant Isolation
Every organisation's data is isolated from every other organisation at the database level. This is not application-level filtering. It is enforced by the database engine itself.
- PostgreSQL Row-Level Security (RLS) policies are active on every table containing organisation data
- Every database transaction sets a session-level organisation scope: the database engine automatically filters all queries to that organisation
- Every organisation-scoped table has a mandatory organisation_id foreign key with CASCADE delete: orphaned cross-tenant data is structurally impossible
- Admin and background tasks must explicitly request RLS bypass: there is no default path to cross-tenant data
Security Monitoring
The platform doesn't just log threats. It actively watches for them in real time and responds automatically.
- Continuous audit log scanning every 2 minutes for attack patterns
- Brute force detection: identifies IP addresses with abnormally high login failure rates and blocks them automatically
- Credential stuffing detection: recognises patterns of valid-username, invalid-password attempts across multiple accounts from the same source
- Session anomaly detection: flags sessions that change device fingerprints or exhibit unusual behaviour
- 2FA abuse detection: identifies accounts receiving excessive verification code requests
- Account lockout spike monitoring: detects coordinated attacks targeting multiple accounts simultaneously
- Automatic IP blocking for sustained attacks with configurable thresholds
- Email alerts to platform administrators for all detected threats
Audit Logging
Every meaningful action is recorded permanently. These logs exist for regulatory compliance, dispute resolution, and forensic analysis. They cannot be tampered with.
- Every data mutation (create, update, delete) is logged with the user identity, timestamp, IP address, and user agent
- Old and new values are captured on every update: you can see exactly what changed, when, and who did it
- All login attempts (success and failure) are recorded with IP address and device information
- Permission changes, role assignments, session events, and administrative actions are all logged
- Individual audit entries cannot be edited, deleted or suppressed, and no API exists to do it, not even for administrators. The one exception is a full organisation erasure under the Privacy Act, which removes that organisation's audit trail along with the rest of its data
- Nothing prunes audit history on a schedule, so the record stays available for as long as your organisation's account exists
- Audit logs are accessible to organisation admins for their own organisation's data
API Hardening
The API layer is the perimeter. Every request is validated, every response is controlled, and every error message is sanitised.
- Many endpoints use Pydantic response schemas that whitelist the exact fields returned, so adding a database column does not silently expose it through those routes
- Error messages are sanitised: no stack traces, internal paths, database details, or implementation hints are ever returned to clients
- Rate limiting on all authentication endpoints with progressive penalties
- Global rate limiting at 1,000 requests per minute per IP address
- Rate limits apply to authenticated traffic as well, keyed by IP address rather than by account
- CORS (Cross-Origin Resource Sharing) restricted to configured domains: cross-origin requests from unknown sites are blocked
- Security headers on every response: HSTS, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy
- Request size limits to prevent payload-based denial of service
- Trusted host validation to block host header poisoning and domain fronting
- HTTPS enforced in production with automatic redirect
Backup Security
Your database is backed up automatically on a schedule, and those backups stay on the server. Off-site backup storage is not switched on yet.
- Automated database backups on a regular schedule, held on the server itself and pruned after 30 days
- Each dump is size checked as soon as it is written, and one that comes back too small is discarded and the run is flagged as a failure
- Off-site copies are not being produced today. The capability is built and waiting on us to enable it, and it will not ship a backup off the server unencrypted
- When we do enable it, off-site copies are encrypted with AES-256-GCM under a backup key held separately from the data encryption key, so compromising one would not expose the other
How we compare to what's typical.
Not named competitors, just what you typically get elsewhere, plus what Australian regulations actually require.
| Feature | Devalo | Most SaaS | AU regulations |
|---|---|---|---|
| Data encrypted at rest | ✓ Always | Varies | Recommended for sensitive data |
| Mandatory 2FA for all users | ✓ Enforced | ✗ Usually optional | Expected for financial services |
| Immutable audit logging | ✓ Complete | ✗ Limited or paid add-on | Required for financial services |
| Data isolated per business | ✓ Database level | Varies | Required under Privacy Act 1988 |
| Australian data residency | ✓ App and database | ✗ US/EU by default | Recommended for sensitive data |
| Password breach monitoring | ✓ Real-time | ✗ Rarely offered | Not mandated, best practice |
| Session security & timeouts | ✓ Enforced | Varies | Recommended for all platforms |
| Real-time threat monitoring | ✓ Automated | ✗ Manual review or none | Best practice for all platforms |
| Encrypted backups | Built, not yet switched on | ✗ Rarely encrypted | Recommended for sensitive data |
Australian compliance, designed in.
Most business software is built in the US and retrofitted for Australian law afterwards. Devalo is designed and operated in Australia, engineered around the Privacy Act 1988 from day one.
- Privacy Act 1988
- Designed to APP standards from the database up.
- Right to erasure
- Full data-export and deletion flows wired into the admin panel.
- AU data residency
- Our application and its database run in Australia. Some specialist providers we rely on handle data overseas, including payments, email delivery, SMS, bot protection and error reporting.
Want to see it? Ask for a walkthrough.
Happy to show you the portal before you commit to anything. No sales pitch, just a look at what you would be using.