Testing a PropTech App Before Launch: Listings, Payments and Roles

Test a PropTech app in four areas before launch: the listing lifecycle (draft to published to archived), rent and deposit payments including the unhappy paths, role-based access for landlords, tenants, agents and admins, and document access. Most property software fails where money moves or where one account can see another's records, not on the happy path everyone demos.

If you would rather have it tested for you, see how RAITHub would test this below. This is a reusable test plan for any property platform, whoever built it, and it pairs with the general pre-launch QA checklist.

What should you test first in a PropTech app?

The journeys that move money or hold personal data: a rent payment, a listing going live, a tenant reading only their own lease. Property software combines payments, documents and multi-party access, so it inherits the failure modes of all three. Name three to seven critical journeys as full sentences, then test each end to end on a production-like environment with realistic data.

Area	Minimum bar to pass	Automate or manual
Listing lifecycle	Every state transition is allowed only for the right role, and an archived listing stops appearing in search and public pages	Automate
Rent and deposit payments	Success, decline, refund, late fee charged once, and a webhook delivered twice all leave one correct record	Automate in test mode, one real transaction at launch
Roles and access	Every role does exactly what it should; a tenant cannot read another tenant's or another landlord's records	Automate
Documents	Leases, ID and inspection photos are reachable only by the parties to them, and private files are not publicly guessable URLs	Automate plus one manual check
Notifications and schedules	Rent reminders, lease-expiry alerts and receipts fire once, at the right local time	Automate with a fixed clock

How do you test the listing lifecycle?

A property listing moves through states: draft, pending review, published, let or sold, and archived. The bugs live in the transitions, not the states. Test that each transition is allowed only for the role that should make it, and that a listing leaving "published" disappears everywhere it was shown.

• Publish a listing, then confirm it appears in search, on the map and on its own page. Archive it, and confirm it disappears from all three, including any cached list.
• Try each transition as the wrong role: a tenant should not be able to publish; an agent should not publish another agency's draft.
• Edit a published listing's price and confirm the change shows everywhere, with no stale copy in a search index.
• Upload the number of photos your limit allows, then one more, and confirm the limit is enforced on the server, not only in the form.
• Submit a listing with a missing required field through the API directly, bypassing the form, and confirm it is rejected.

Listing moderation and its full state machine are covered in listing moderation for property portals. This post is about proving the states behave before real users arrive.

How do you test rent, deposits and other payments?

Test the unhappy paths. A successful card payment is the one case everyone demos; declines, duplicate webhooks and late fees are where rent money goes missing. Use the provider's test cards and test mode, never real cards. Stripe publishes a full set in its testing documentation.

• Run success, decline, insufficient funds and a refund for a rent payment, and confirm the lease balance, the receipt email and the landlord's ledger all update.
• Deliver the same payment webhook twice and confirm it changes the balance once. Stripe warns that an endpoint might receive the same event more than once and recommends recording processed event IDs (Stripe: webhooks).
• Test a late fee: it should be charged once past the grace period, never twice, and never while a payment is still processing on the last grace day.
• Test a deposit held and later partly returned, and confirm the returned amount and the retained amount both reconcile.
• Close the tab mid-payment. The rent record should end up clearly paid or clearly unpaid, never half-created.

The layered payment test plan, with test clocks for renewals and the full replay suite, is in testing payments and webhooks end to end. For the design of rent collection itself, see building an online rent collection system.

How do you test role-based access for landlords, tenants and agents?

Write a role matrix, then try to break it. Broken access control is A01, the top risk, in the OWASP Top 10:2025. Property apps have several parties with overlapping views, which is exactly where one account reaches another's records.

Action	Tenant	Landlord	Agent	Admin
Read own lease and payments	Allow	Allow, own units	Allow, own listings	Allow
Read another tenant's lease	Refuse	Refuse	Refuse	Allow, logged
Read another landlord's units	Refuse	Refuse	Refuse	Allow, logged
Publish or edit a listing	Refuse	Allow, own	Allow, own	Allow
Change own role or plan	Refuse	Refuse	Refuse	Allow
Open admin routes and APIs	Refuse	Refuse	Refuse	Allow

Test every "Refuse" cell with two accounts per role, through the API rather than the screens, because the screens hide what the API still allows. A Playwright loop keeps the matrix running after every change:

import { test, expect } from '@playwright/test'

const tokens = {
  tenant: process.env.TENANT_TOKEN,
  landlord: process.env.LANDLORD_TOKEN,
  agent: process.env.AGENT_TOKEN,
}

// A lease that belongs to a different tenant and a different landlord
const otherLease = '/api/leases/' + process.env.OTHER_TENANT_LEASE_ID

for (const [role, token] of Object.entries(tokens)) {
  test(role + ' cannot read another tenant lease', async ({ request }) => {
    const res = await request.get(otherLease, {
      headers: { Authorization: 'Bearer ' + token },
    })
    expect([401, 403, 404]).toContain(res.status())
  })
}

For writes, also read the record back afterwards: some endpoints return 403 but still change the row. The defensive auth plan in full, including self-promotion and session tests, is in testing login, roles and data access. Tenant isolation for multi-agency platforms is covered in finding a tenant leak.

How do you test document access?

Leases, identity documents and inspection photos are personal data. The common failure is a file stored at a URL anyone can guess or share. Test that a document is reachable only by the parties to it, and that a signed link expires.

• Copy a document URL from one tenant's session, log in as another, and open it. It must be refused.
• Open a private document while logged out. It must be refused, not merely hidden behind a page.
• If you use time-limited signed URLs, confirm an expired link stops working.
• Delete a tenant and confirm their documents are no longer reachable.

Buy, build or hire this testing?

Option	Choose this when	Trade-off
Off-the-shelf property SaaS (test the vendor's app, not your own code)	You are buying, not building, and only need to confirm the product fits	Little of your own code to test; you inherit the vendor's gaps and limits
Scanners plus your own Playwright suite	A developer can own the role matrix and payment replay suite and keep them current	Lowest cost to run; scanners cannot know your role rules, so you still design those tests
A freelance tester before launch	You want a quick outside look once	Variable depth on payments and access control; check their experience with money flows
A managed QA plan or a one-off pre-launch audit	You want listings, payments, roles and documents tested end to end before real tenants	An outside dependency; make sure the tests land in your repository

Doing it yourself is realistic: for an app with four roles and rent payments, plan 3 to 5 days for a developer who knows the stack. The main risk of going alone is testing only the cells and payment paths you expect to pass.

Why RAITHub for this

• Property money flows are everyday work. PropDesk, a property-management SaaS RAITHub built, has 4 roles, Stripe rent collection and 1,024 automated tests. BlockEstate is a multi-tenant listing and inquiry platform that reached MVP in 6 weeks.
• Tests at the database, the API and the screen, so access rules are proven where they are enforced, not only where they are shown.
• Honest limits. RAITHub's security testing is application-level testing against OWASP guidance. It is not a CREST- or PCI-certified penetration test and produces no compliance attestation. There is no standalone QA case study yet; the figures above are test suites for platforms RAITHub built.

When you don't need us

• It is a brochure site with listings but no accounts or payments. The hosting builder's own checklist is enough.
• You have a QA engineer who owns release testing. Give them this plan.
• You need a certified penetration test report for a procurement requirement. Use a certified firm; RAITHub is not SOC 2 or ISO 27001 certified.

How RAITHub would test this

• Scope: agree the roles, the payment flows and the document types on a free 15-minute call.
• Plan: a risk map of listings, payments, roles and documents, with a test for each risk.
• Test: the listing lifecycle, payments in test mode with a replay suite, every "Refuse" cell through the API with two accounts per role, and document access.
• Deliver: a ranked bug report with reproduction steps and a suggested fix, plus the matrix and payment tests as automated tests in your repository.
• What you receive: the report, the tests and a handover note. IP is yours; an NDA is standard.

The audit is fixed-price, quoted in writing after the call. See QA as a Service, AI-built app testing and, if you are still building, SaaS development and the PropTech industry page. To book it, ask for a pre-launch QA audit.

Documentation checked on 10 October 2026.

Frequently asked questions

What should you test before launching a PropTech app?

The listing lifecycle, rent and deposit payments including declines and refunds, role-based access for landlords, tenants, agents and admins, document access, and scheduled notifications. Start with the journeys that move money or hold personal data.

How do you test role-based access in property software?

Write a matrix of every action against every role, including anonymous visitors, then test each cell through the API with two accounts per role. Focus on the cells that should be refused, such as one tenant reading another tenant's lease, and automate them.

How do you test rent payments without real money?

Use your payment provider's test mode and test cards to run success, decline, insufficient funds and refund flows, deliver each webhook twice, and check that late fees are charged once. Make a single real low-value transaction only at launch.

How do you stop one landlord or tenant seeing another's data?

Enforce access at the database and the API, not only the screen, and test it by copying one account's record IDs and requesting them as another account. On a Postgres project, row-level security backs this up; test the policies directly on a staging copy.

How long does pre-launch QA take for a property app?

For an app with four roles and rent payments, plan 3 to 5 days for a developer who knows the stack: a day on the role matrix, a day or two on payments, and the rest on listings, documents and schedules. Fixing what it finds takes longer.

Is application-level security testing the same as a penetration test?

No. This is functional and application-level testing of your own access and payment rules against OWASP guidance. A penetration test is a broader, often certified engagement. If a customer or auditor needs a pentest report, use a certified provider.