Replace spreadsheets, shared inboxes and manual workarounds with software your staff, customers and suppliers sign in to, where each person sees only what they should.
Secret scanningCommitted key revoked and removedContained
EnvironmentsTest and live kept separateManaged
ReleaseNew release to approveDecision needed
Illustration · not live data
01Who it's for
Is this service right for you?
It makes sense when an off-the-shelf product no longer fits the way your organisation works, or when the data involved is too sensitive to leave to workarounds.
Built for
Businesses running key processes on spreadsheets, email and manual re-keying
Organisations that need a secure portal for customers, members or suppliers to log in and share documents
Teams whose off-the-shelf software no longer fits and costs more in workarounds than it saves
Government, health and education teams that must show how an app protects personal information
You probably need it if…
A key process runs on spreadsheets, shared inboxes and copying data between systems
Customers or suppliers email documents back and forth because there is nowhere secure to share them
Off-the-shelf software covers half of what you need and the rest is manual workarounds
You hold sensitive data and need to control who can see it and where it is stored
02What's included
What you get
What we build
Customer and supplier portals
Secure portals where customers, members or suppliers sign in to view records, upload documents, track jobs or make requests. Each user sees only what their role allows, and every sign-in can require multi-factor authentication (MFA).
Internal tools
Web apps that replace spreadsheets and manual steps: job tracking, approvals, rostering, asset registers and intake forms. Your team gets one place to work, with an audit trail of who changed what.
Dashboards and reporting
Dashboards that pull data from your existing systems into clear, up-to-date reports. Access is limited by role, so sensitive figures are only visible to the people who need them.
Secure by design
Secure architecture and code
We design authentication, authorisation, input handling, logging and data storage with security in mind from the first sprint. Code is peer reviewed against OWASP guidance, and secrets are kept out of the codebase.
Secure hosting and releases
Development, test and live systems are kept apart, with least-privilege access to each. Application programming interfaces (APIs) only expose what each role needs, and third-party packages are kept current so known vulnerabilities are patched.
Support
Support and change
After launch we can host, monitor and update the app, and build new features as your needs change. You receive documentation and access to the source code repository.
Development
Who can see what, decided before the first line of code
We map roles and permissions with you during planning: what a customer, a staff member and an administrator can each view or change. Building those rules in early is far easier than adding them after launch.
03In detail
Custom software & web apps, in depth
What is custom software?
Custom software is an application built for the way your organisation works, instead of a product you adapt yourself to. For most of our clients it is a web app that staff, customers or suppliers open in a browser and sign in to. Because Catharsis tests and secures systems for a living, we design every app on the assumption that someone will try to break it.
How do we build security into the app?
Broken access control, weak authentication, unvalidated input and exposed secrets appear year after year in the OWASP Top 10, the list of critical web application risks published by the Open Worldwide Application Security Project (OWASP). We address them in the design, not after launch:
Threat modelling. Before building, we map what the app holds, who might attack it and how, and turn the answers into security requirements in the scope.
Access control first. We define user roles and what each one can see and do before writing screens, so one user can’t see another’s data.
Strong sign-in. MFA is available or required, depending on the sensitivity of the app.
Validated input. Form fields and API requests are checked on the server, not just in the browser.
Secrets kept out of code. Keys and passwords live in a secure store, not in the repository.
Dependency and secret scanning. Third-party packages are checked for known vulnerabilities, and changes are scanned for accidentally committed keys.
Logging. Important actions are recorded so you can see who did what, and when.
When the app exchanges data with other systems, we design those connections as part of the project, drawing on our integrations and automation work. Our secure development page sets out the standards behind this work.
Which weaknesses do we design against?
We design against the weaknesses in the OWASP Top 10, the most widely used list of serious web application risks:
Broken access control: every request checks who the user is and what they are allowed to see or do. One customer can’t open another customer’s records, and a staff member can’t approve their own request.
Weak sign-in and sessions: passwords are stored safely, multi-factor authentication is used where it fits, and sessions expire.
Injection: user input is validated and never run as code or as a database command.
Insecure design: business rules and misuse cases are planned at the design stage, not patched in later.
Misconfiguration and exposed secrets: secure defaults, no keys or passwords in the code, and each component gets only the access it needs.
Outdated components: third-party libraries are kept on supported versions.
As on our website builds, we plan for these in the design and check for them in code review.
Want an independent test? A penetration test can be scoped separately, before launch or whenever a significant change goes live. We can also look after the app day to day under a website care and hosting plan.
04The process
How it works
1Step 01
Discovery
We map the process the software must support, the people who will use it and the data it will hold. You get a written scope, an outline design and a quote, or a staged estimate for larger apps.
2Step 02
Design and prototype
Screen designs or a clickable prototype you can test with real users before development starts. We also agree the security requirements, such as roles, MFA and data retention.
3Step 03
Build in stages
We build in short stages and show you working software regularly, so you can change direction early rather than at the end.
4Step 04
Test and launch
Functional testing, a final review with you and a planned go-live, with user training and handover documentation.
05Frameworks
How this maps to the frameworks
Useful for your auditor, board or procurement team. The mapping shows where this service supports each framework. It doesn't replace a formal assessment.
Custom Software & Web Apps: framework mapping
Control
ASD Essentials
ASD maturity model (current)
ISO/IEC 27001
NIST CSF
Secure development life cycle
–Not applicable
–Not applicable
A.8.25, A.8.28
Protect (PR.PS-06)
Security requirements and threat model
–Not applicable
–Not applicable
A.8.26
–Not applicable
Separate development, test and live environments
–Not applicable
–Not applicable
A.8.31
–Not applicable
Role-based access and MFA
Identity services
Multi-factor authentication
A.5.15, A.8.5
Protect (PR.AA-05)
Dependencies kept up to date
–Not applicable
–Not applicable
A.8.8
Identify (ID.RA-01)
Audit logging
Visibility and response
–Not applicable
A.8.15
Protect (PR.PS-04)
06Pricing
Pricing and how to start
Pricing
Quoted for your environment
What changes the price
The price depends on the number of user roles, screens, integrations with other systems, reporting needs and the sensitivity of the data the app holds.
Discovery, written scope and outline design
Design or clickable prototype for key screens
Development with secure sign-in and role-based access
Secure hosting set-up with separate test and live environments
Custom software is priced on scope: the number of screens and user roles, the integrations with other systems, the reporting you need and how sensitive the data is. A simple internal tool costs far less than a customer portal with payments and several integrations. Larger apps are often delivered in stages, so you can launch a first version sooner and fund later features once it is proving its value. We scope and quote after discovery, before any development begins.
Should we build custom software or buy an off-the-shelf product?
Buy off the shelf when a product already fits most of your process and you can live with its limits. Build when your process is part of what makes you different, when workarounds are costing staff time every week, or when you need to control where and how sensitive data is stored. We will tell you honestly if an existing product is the better answer.
What is the difference between a website and a web app?
A website mostly publishes information: anyone can read it and only your team edits it. A web app is software people sign in to and work in, such as a portal, booking system or approval tool. It holds records that belong to different users, so it needs roles, permissions and audit trails that a brochure site does not. If you need both, we can build the app alongside your website.
Can a custom app connect to our existing systems?
Yes. Most of the apps we build exchange data with other systems, such as Microsoft 365, a customer relationship management (CRM) platform or accounting software. We connect through official application programming interfaces (APIs) where they exist, use the least access each connection needs and store credentials securely. Larger connection projects are covered by our integrations and automation service.
Where is our data stored?
You decide, and we design around it. For organisations with Australian data residency requirements, we can host the app and its database in Australian regions and document where every copy of the data lives, including backups. We will also explain which third-party services the app relies on and where they process data, so you can answer questions from customers and auditors.
Who owns the code?
Our standard approach is that you can reach the code and the documentation needed to run, change or move the app. We confirm ownership terms in writing before the project starts.
