The problem
Need exists
everywhere.
Millions of people face needs that fall through the gaps. Not emergencies, necessarily, but real and pressing difficulties that leave people isolated, unsafe, or without basic necessities.
An elderly person living alone who cannot maintain their home. A family displaced overnight by a medical crisis. A community shelter that cannot source enough supplies to meet demand.
At the same time, communities contain an enormous and largely untapped reserve of generosity. Tradespeople with spare capacity. Businesses with surplus stock. Individuals with an afternoon free and a willingness to help.
What has been missing is the infrastructure to connect the two reliably, safely, and at scale. HelpNet is that infrastructure.
How it works
Simple by design.
Powerful in practice.
The platform supports two types of interaction, and within each, participants take one of two contextual roles. Roles are not fixed identities — the same person or organisation may be a Requester in one interaction and a Provider in another.
Interaction types
Type 01
Task-based help
A service or piece of work is performed. A tradesperson installs handrails. A motel owner provides accommodation. A volunteer mows a lawn. The Provider shows up and does something.
Type 02
Contribution-based support
Goods, funds, or resources are provided. A retailer donates stock. A business funds a community initiative. A supplier fulfils an order for a shelter. The Provider gives something.
Roles
Requester
Anyone who identifies and posts a need. An individual, a family, a charity, a community group, or a government body. The Requester describes what is needed, where, and why.
Examples: elderly resident, community shelter,
displaced family, local council
Provider
Anyone who steps forward to meet a need. A tradesperson, a business, a volunteer, a retailer with surplus stock. The Provider commits to helping and is held accountable through verified identity.
Examples: local builder, national retailer,
motel owner, skilled volunteer
Initiation modes
Pull mode
Requester-led
A Requester posts a need. Nearby verified Providers express interest. The Requester reviews the shortlist and chooses. The most common flow.
Push mode
Provider-led
A Provider browses open needs and proactively offers to help. The Requester reviews the offer and accepts. Enables generous Providers to seek out where they can add value.
Real world examples
Task-based
A pensioner posts a request for bathroom handrails to be installed. A local builder accepts the job. A nearby hardware store provides the fittings at no cost.
Task-based
A parent whose child is hospitalised unexpectedly needs somewhere to stay. A motel owner three streets from the hospital offers a week of free accommodation.
Contribution-based
A homeless shelter needs 20 sleeping bags ahead of winter. A national outdoor retailer donates the full order, with visibility to their wider customer base as a result.
Who participates
Individuals
Any verified adult, whether seeking help or offering it.
Businesses
Local traders, national retailers, service providers with capacity to give.
Non-profits
Charities and community groups posting needs or coordinating help.
Community groups
Clubs, associations, and local organisations on either side of an interaction.
Government bodies
Local and state entities coordinating community support programs.
Participation is anchored to geography so that needs and offers are matched within relevant local areas. The platform is designed to scale nationally and globally. Every participant is identity-verified, ensuring that every interaction is grounded in real accountability.
For businesses and organisations
Giving on HelpNet
is not a cost. It is a platform.
Businesses and organisations that participate as Providers on HelpNet are not simply donating goods or time. They are building a visible, verified, and ongoing relationship with the communities they serve.
Every contribution is recorded, attributed, and surfaced to a growing network of individuals, families, and organisations who can see exactly who showed up and helped.
In a landscape where consumers and partners increasingly evaluate businesses on their social impact, HelpNet provides something most CSR programs cannot: proof, at a community level, that the commitment is real.
What businesses receive
Impact profile
A verified public profile logging every contribution made, visible to the entire HelpNet community and searchable by the general public.
Contribution badges
Tiered recognition badges earned through sustained giving. Displayed on the business profile and available for use in their own marketing materials.
Platform visibility
Active Providers are featured within the platform to members in their geographic area, creating genuine brand exposure within a highly engaged, trust-based community.
Impact reporting
Automated reports showing the real-world outcomes of contributions. Ready to use in annual reports, grant applications, and CSR documentation.
Contribution points
A points system that accumulates with every task completed or resource donated. Points unlock advertising credits, featured placement, and priority matching with high-visibility needs.
Tax documentation
Where applicable, HelpNet generates documentation to support charitable deduction claims, reducing the administrative burden of in-kind and monetary contributions.
The business case in practice
Hardware retailer
Donates fittings for an elderly resident's bathroom safety installation. Earns a verified contribution badge, featured placement in the local area feed, and a ready-made CSR story for their next community report.
National outdoor retailer
Donates 20 sleeping bags to a homeless shelter. The contribution is logged, badged, and surfaced to thousands of platform members, many of whom are their core customer demographic.
Local motel
Offers a week of free accommodation to a family in crisis near a hospital. Accumulates contribution points, builds a public reputation for community care, and fills a room that would otherwise sit empty.
Across all of these interactions, the business does not simply give and walk away. They become part of a story that the community tells about itself, and about who showed up when it mattered. That is a return on investment no advertising campaign can replicate.
Recognition tiers
Tier 1
Community supporter
First contribution. Entry badge. Basic platform visibility.
Tier 2
Active contributor
Sustained engagement. Featured in local area feed. Ad credit unlocked.
Tier 3
Community champion
High-volume provider. Priority matching. Impact report generated.
Tier 4
Platform partner
Strategic contributor. Co-branded recognition. White-glove reporting.
Architecture overview
How HelpNet
is built.
A web-first platform built as a modular monolith on Next.js, hosted on Vercel, with Supabase as the primary backend. The architecture is designed to move quickly without accumulating debt that blocks scale. Modules are clearly bounded internally and can be extracted into independent services later if specific workloads demand it.
Design principles
01
Web first
Next.js on Vercel delivered to all surfaces. Mobile apps follow once the product is validated.
02
Third-party where possible
Auth, IDV, maps, and comms delegated to proven providers. Build only what is unique to HelpNet.
03
Safety by design
IDV enforced at the point of real-world commitment. No unverified user can accept or be assigned to a job.
04
Modular monolith
Single application with bounded internal modules. Extract services later when specific workloads justify it. Notifications and Geo are the most likely first candidates.
Layer overview
Client
Next.js web app (React, responsive) — Vercel
↓
Gateway
Next.js API routes — auth, rate limiting, routing
Supabase Edge Functions — webhooks, long-running tasks
↓
Application modules (modular monolith)
Jobs
Users
Organisations
Notifications
Reputation
Safety
Geo
Contributions
↓
Supabase platform
PostgreSQL + PostGIS
Supabase Auth
Supabase Storage
pgmq (async queues)
Row Level Security
↓
Third-party integrations
Auth0
ConnectID / Onfido
Google Maps / Mapbox
Twilio / SendGrid
Sentry
PostHog
Async processing: Long-running work — notification fan-out to many Providers, impact report generation — runs in Supabase Edge Functions or dedicated workers, not Vercel serverless functions, due to execution time limits. Async fan-out is handled via Postgres triggers and pgmq, keeping the queue layer inside Supabase rather than requiring a separate queue service at MVP.
Application module
Jobs module
The heart of the platform. Manages the full lifecycle of a job from creation through to completion, and orchestrates matching between Requesters and Providers.
Responsibilities
| Concern | What it does | Type |
|---|
| Job CRUD | Create, read, update, delete job records. Stores type, description, location, urgency, deadline, photos, and status. | owns |
| State machine | Manages transitions: draft to open to matched to in progress to completed (or cancelled). | owns |
| Matching | Calls the Geo module to find nearby Providers when a job opens. Applies capability tags, availability, capacity limits, urgency weighting, and mutual exclusions to rank the shortlist. | calls geo |
| Requester selection | Presents a ranked shortlist of interested Providers with ratings, distance, and profile info. Requester chooses. Falls back to highest-rated interested Provider if Requester does not act within the time window. | owns |
| Assignment | Records who was chosen. Enforces IDV check via Users module at point of commitment. Provider and org context stored on the committed record. Execution is always via JobAssignment. | calls users |
| Job assignment records | Stores assigned users, their acting organisation if any, and their role (lead, worker). Separate from the committed Provider record. | owns |
| Completion events | On completion, triggers reputation and contribution attribution via Postgres triggers and pgmq. | emits |
Job lifecycle
draft
→
open
→
shortlisted
→
matched
→
in progress
→
completed
A job can move to cancelled from any state.
Matching flows
Pull mode — requester-led
1
Requester posts a need with type, urgency, location, description, and optional photos
2
Job opens. Geo module finds nearby verified Providers. Capability tags, availability, and capacity are applied to rank the list
3
Matched Providers are notified and can express interest within a time window
4
Requester sees a shortlist with ratings, distance, and profile info, and chooses their preferred Provider
5
If Requester does not act within the window, the highest-rated interested Provider is auto-assigned
6
IDV is enforced on the chosen Provider. Job moves to matched
Push mode — provider-led
1
Provider browses open jobs feed filtered by location, capability tags, and type
2
Provider signals an offer to the Requester
3
Requester reviews the offer with ratings and profile info, and accepts or declines
4
On acceptance, IDV check is enforced on the Provider
5
Job moves to matched and work begins
Matching inputs
Matching is deliberate product logic, not a simple radius query. The following inputs inform the ranked shortlist shown to a Requester:
Geo proximity
Distance from Provider's location to the job. Provider sets a preferred radius; jobs outside it are excluded.
Capability tags
Providers declare what they can do. Jobs declare what is needed. Only Providers with matching tags surface in results.
Availability windows
Provider sets available days and times. Urgent jobs are matched only to Providers who are available in the required window.
Capacity limits
Providers with too many open jobs in progress are excluded or ranked lower to ensure quality of delivery.
Urgency weighting
Jobs marked as immediate surface higher in Provider feeds and notify more aggressively.
Mutual exclusions
Providers and Requesters who have previously flagged concerns about each other are excluded from matching.
Key data model
Job {
id: uuid
type: task_based | contribution_based
status: draft | open | shortlisted | matched | in_progress | completed | cancelled
urgency: immediate | within_week | flexible
deadline: timestamp?
requester_user_id: uuid
requester_org_id: uuid?
provider_user_id: uuid? // committed provider only
provider_org_id: uuid? // execution is via JobAssignment
location: point (lat/lng)
description: text
photos: string[] // Supabase Storage keys
created_at, expires_at, completed_at: timestamp
}
JobAssignment {
id: uuid
job_id: uuid
assigned_user_id: uuid
acting_org_id: uuid?
role: lead | worker
}
Application module
Users module
Manages every verified individual on the platform. Owns identity verification state, profile data, child safety credentials, and role eligibility. Every real-world interaction flows through a verified User.
Responsibilities
| Concern | What it does | Type |
|---|
| User profiles | Stores name, contact details, location, capability tags, availability windows, and profile data for every individual. | owns |
| Identity verification | Manages IDV status and method. ConnectID (bank-verified) is the primary path. Onfido is the fallback for users whose bank does not participate. Records idv_method alongside status. | calls ConnectID / Onfido |
| Child safety credentials | Records state-specific Working With Children credentials (Blue Card QLD, WWCC NSW, WWCC VIC, etc.) as a polymorphic ChildSafetyCredential. Required for roles involving close-quarters interaction with children. | owns |
| NDIS screening | Records NDIS Worker Screening clearances for interactions involving vulnerable adults. | owns |
| Auth integration | Links platform user records to Auth0 JWT identities. Auth0 tokens are verified against Supabase RLS policies. | calls Auth0 |
| Eligibility checks | Exposes an internal API used by the Jobs module to confirm a user is verified before assignment. | owns |
Key data model
User {
id: uuid
auth_id: string // Auth0 sub, linked to Supabase RLS
name, email, phone: string
location: point (lat/lng)
idv_status: pending | verified | failed
idv_method: connectid | onfido
idv_provider_ref: string?
created_at: timestamp
}
ChildSafetyCredential {
id: uuid
user_id: uuid
credential_type: blue_card_qld | wwcc_nsw | wwcc_vic | wwcc_sa | wwcc_wa | wwcc_tas | wwcc_act | wwcc_nt
issuing_state: string
credential_number: string
expiry: date
verified_at: timestamp?
}
AuditEvent {
id: uuid
actor_user_id: uuid
action_type: string
target_entity: string
target_id: uuid
metadata: jsonb
created_at: timestamp // immutable, append-only
}
Application module
Organisations module
Manages businesses, charities, clubs, and community groups. Organisations commit to jobs; verified Users within them execute the work.
Responsibilities
| Concern | What it does | Type |
|---|
| Organisation profiles | Stores name, type, ABN, location, DGR status, and public impact profile. | owns |
| Membership | Links Users to Organisations with a role: admin, coordinator, or worker. A User may belong to multiple orgs. | owns |
| Permissions | Determines which Users within an org can accept jobs, post needs, or assign workers. | owns |
| Verification | Validates that a User acting for an org is an active, verified member before any job commitment. | calls users |
Key data model
Organisation {
id: uuid
name: string
type: business | charity | club | government
registration_number: string?
dgr_status: boolean // DGR-endorsed charities only can issue tax-deductible receipts
location: point (lat/lng)
verified: boolean
}
OrganisationMember {
user_id: uuid
org_id: uuid
role: admin | coordinator | worker
active: boolean
}
Application module
Notifications module
Delivers timely communications to users across email, push, and SMS. Triggered by Postgres events via pgmq. Notification fan-out to many Providers (e.g. a new job posted nearby) runs in a Supabase Edge Function rather than a Vercel serverless function due to execution time limits.
Trigger map
| Trigger | Recipients | Channel |
|---|
| Job posted nearby | Verified Providers in geo radius matching capability tags | Push, email |
| Provider shortlisted | Requester | Push, email |
| Requester chose Provider | Provider | Push, email |
| Job assigned | All parties | Push, email |
| Job completed | All parties | Push, email |
| Post-job check-in | Both parties, staggered | Push, SMS |
| Review received | Reviewed user | Push, email |
| Badge earned | Organisation or user | Email |
| IDV status update | User | Email, SMS |
Application module
Reputation module
Tracks the trust and contribution history of every participant. Drives the badge and points system that recognises and rewards Provider activity. Safety reporting is handled separately by the Safety module.
Responsibilities
| Concern | What it does | Type |
|---|
| Reviews | Stores ratings and written feedback between Requesters and Providers after job completion. Reviews are held in a cooling-off period before publishing to discourage retaliatory feedback. | owns |
| Points | Awards contribution points on job completion. Points unlock advertising credits and featured placement. | owns |
| Badges | Tiered recognition earned through sustained contribution. Available for use in external marketing. | owns |
| Impact profile | Aggregates a public record of all contributions made by a User or Organisation. | owns |
| Impact reporting | Generates automated reports for business Providers. Used in CSR documentation and grant applications. Runs async via Edge Function. | emits |
Application module
Safety module
Owns all trust and safety processes. Separated from Reputation to give safety concerns a dedicated, auditable home that is not entangled with recognition logic.
Responsibilities
| Concern | What it does | Type |
|---|
| 24/7 report portal | Any participant can raise a concern at any time. Low-friction path distinct from formal reporting. | owns |
| Behaviour flagging | Flags concerning patterns for internal review before escalation. Reviewers can access the full audit trail. | owns |
| Escalation | Escalates reportable offences to local investigating authorities with full identification and audit records. | emits |
| Post-job check-in | Triggers a two-way check-in after in-home jobs. Low-friction prompt to both parties to confirm the interaction was safe. | calls notifications |
| Mutual exclusions | Records pairs of Users or Orgs who should not be matched. Feeds into matching logic. | owns |
| Audit trail | All safety-related actions are written to the immutable AuditEvent log. Append-only. Used for investigations and compliance. | owns |
| Background checks | For higher-risk interactions, records background check results as a layer above IDV. Insurance and consent waivers for tradesperson interactions are also stored here. | owns |
IDV is not enough on its own. Confirming someone's identity is different from confirming they are safe to interact with vulnerable people. Background checks, insurance verification, and consent waivers are a separate layer for higher-risk job types. This module owns that distinction.
Application module
Geo module
Handles all location-based matching. Finds Providers within a specified radius of a job, and surfaces needs within a Provider's area of interest. Geography is one input into matching — see the Jobs module for the full matching logic.
Responsibilities
| Concern | What it does | Type |
|---|
| Proximity matching | Given a job location, returns verified Providers within their configured radius using PostGIS spatial queries via Supabase. | owns |
| Feed filtering | Filters the open jobs feed to a Provider's configured location and radius preference. | owns |
| Address resolution | Converts addresses to coordinates and vice versa via Google Maps / Mapbox geocoding API. | calls maps |
Implementation note: Radius is a Provider preference, not a job attribute. Jobs store a location point only. PostGIS handles all spatial queries natively within Supabase. A separate Redis-based location cache is not needed at MVP scale.
Application module
Contributions module
Manages contribution-based interactions where goods, funds, or resources are provided. Handles the donations forum and tax documentation generation, bounded by Australian DGR and ATO rules.
Responsibilities
| Concern | What it does | Type |
|---|
| Contribution listings | Outreachers post funding or goods needs. Contributors browse and pledge support. | owns |
| Pledge management | Tracks in-kind and monetary pledges. Records fulfilment status. | owns |
| Tax documentation | Generates tax receipts where the receiving organisation holds DGR endorsement. In-kind business donations follow separate ATO rules and are documented accordingly. The module does not issue generic receipts. | emits |
| Impact attribution | On fulfilment, triggers reputation credit to the contributing organisation via pgmq. | emits |
Infrastructure
Infrastructure and
third-party services
Supabase platform
Primary database
PostgreSQL + PostGIS
Source of truth for all core entities via Supabase. PostGIS handles spatial queries. Row Level Security enforces data access at the database layer, aligned with Auth0 JWT claims.
Authentication integration
Supabase Auth + Auth0
Auth0 handles user authentication and issues JWTs. Supabase RLS policies validate those tokens directly, so access control is enforced at the database layer without a custom middleware layer.
Object storage
Supabase Storage
Job photos, IDV documents, profile images, and generated impact reports. Replaces standalone S3 / R2 at MVP. Access controlled via RLS policies consistent with the rest of the platform.
Async queue
pgmq
Postgres-native message queue via Supabase. Handles async fan-out for notifications, impact report generation, and reputation updates. Triggered by Postgres triggers, keeping async processing inside the existing infrastructure.
Third-party services
Authentication
Auth0
User authentication, session management, and JWT issuance. JWTs are validated by Supabase RLS policies. Chosen for reliability and enterprise SSO support.
Identity verification
ConnectID (primary)
Bank-verified digital identity via Australian Payments Plus. Strong Australian coverage with high assurance levels. Primary IDV path for users whose bank participates in the network.
Identity verification
Onfido (fallback)
Document-based 100-point ID verification for users whose bank is not in the ConnectID network. Strong Australian document support.
Mapping
Google Maps / Mapbox
Geocoding and map display. Google Maps has better Australian address coverage. Mapbox offers more customisation and predictable pricing.
Communications
Twilio / SendGrid
SMS via Twilio for time-sensitive alerts and post-job check-ins. Transactional email via SendGrid for notifications, IDV updates, and impact reports.
Error monitoring
Sentry
Real-time error tracking and alerting across the Next.js frontend and Edge Functions.
Product analytics
PostHog
Product analytics and feature flags. Enables data-driven decisions on matching quality, funnel performance, and feature rollout. TBD: validate PostHog's data residency options against Australian Privacy Principles.
Payments (future)
Stripe
Not required at MVP but likely needed for monetary contributions and platform fees. Natural choice given its Australian support and ecosystem.
Compliance
Australian
compliance.
HelpNet operates in a regulated environment. The following compliance areas are bounded into the platform design, not treated as afterthoughts.
Working With Children requirements
Blue Card is Queensland-specific. The platform must support the equivalent credential for each Australian state and territory. The ChildSafetyCredential model captures credential type, issuing state, number, and expiry, replacing any single blue_card field. Credential verification is managed per-state as requirements differ.
NDIS worker screening
Interactions involving NDIS participants require an NDIS Worker Screening clearance separate from standard IDV. The Users module records this separately. Jobs involving vulnerable adults surface the screening requirement at the point of Provider acceptance.
100-point ID as AML/KYC
The 100-point ID requirement is an Australian AML/KYC concept layered on top of the IDV provider's output. ConnectID provides bank-verified identity at a high assurance level. For Onfido-verified users, the platform maps the document combination to a 100-point score. The Users module tracks the source and method, not just the pass/fail outcome.
Australian Privacy Principles — APP 8
APP 8 governs cross-border disclosure of personal information. Both ConnectID and Onfido involve data handling outside the platform. The platform must ensure that:
Disclosure basis
Users are informed at the point of IDV which provider handles their data and where it is processed.
Data minimisation
Only the verification result and a provider reference are stored on the HelpNet platform. Raw identity documents are not retained.
Third-party obligations
ConnectID and Onfido contracts must include privacy protections substantially similar to the APPs, as required under APP 8.1.
DGR rules and tax documentation
Only organisations with Deductible Gift Recipient endorsement from the ATO can issue tax-deductible receipts. In-kind business donations — goods or services rather than money — are subject to separate ATO rules and do not automatically qualify for a deduction. The Contributions module is bounded by these rules:
DGR receipts
Tax-deductible receipts are issued only where the receiving organisation is DGR-endorsed. The Organisation record carries a dgr_status flag verified against the ABN Lookup register.
In-kind documentation
In-kind contributions generate a record of what was donated, to whom, and when. Tax advice on deductibility is not provided by the platform — users are directed to their accountant or the ATO.
Monetary contributions
Monetary donations to DGR organisations generate a compliant receipt. The receipt includes the organisation's ABN, DGR status, and the donation amount and date as required by the ATO.