WeCare — what we are building, and what it takes

1. The short version

WeCare is a managed marketplace, not an open one. The admin owns the business, sets the rates, and decides which partner attends which job. That single decision shapes everything below — it is simpler to build than an open marketplace, it is far easier to keep compliant, and it matches how the business actually operates.

The three things that matter most

1. Compliance is the product, not a feature. Seven of the eleven services are legally gated in Australia, and the gates differ by state. The credential engine — what each partner must hold, for which service, in which state, and when it expires — is the core of the system. Build it first.
2. Privacy law applies from day one. Because WeCare delivers elderly care and nursing, it is a health service provider under the Privacy Act and the small-business exemption does not apply, whatever the turnover. This is not a "later" item. See §4.
3. Whether partners are contractors or employees is a business decision with a six-figure tail. It changes superannuation, leave, payroll tax and workers' compensation, and it must be settled with an Australian employment lawyer before launch, not after. See §14.

2. How we proceed

Build the POC first, in one week. Show it to your friend working, not as slides. Everything else is then a decision made against something real.

3. Scope — roles & services

The three registrations

The eleven services

"Regulated" below means a partner cannot legally perform that service in Australia without a specific credential, and WeCare must therefore refuse to allocate it.

4. Australian compliance

This section is the reason the project is more than a booking app. Everything below was checked against current Australian sources in September 2026; sources are listed at the end of the section. Treat it as a well-researched starting point for your lawyer, not as legal advice.

4.1 What every partner provides, regardless of service

4.2 What changes by service

4.3 If WeCare serves NDIS participants

An NDIS Worker Screening Check is mandatory for risk-assessed roles — which includes anyone delivering personal care, transport or daily living support. It costs roughly $85–$130, takes two to six weeks, and is valid for five years. Unlike a WWCC it is portable: a clearance issued in one state works in an NDIS role anywhere in Australia.

4.4 Privacy — the part that is easy to get wrong

What follows from that:

• Health information is sensitive information and attracts a higher standard than ordinary personal data. A client's care needs, mobility and medications all qualify.
• The Australian Privacy Principles apply in full — collection notices, purpose limitation, access and correction rights, and a published privacy policy.
• The Notifiable Data Breach scheme applies. An eligible breach must be assessed and, if serious, reported to the OAIC and to affected individuals.
• A statutory tort for serious invasions of privacy commenced on 10 June 2025, and it applies regardless of whether an entity is covered by the Privacy Act. Individuals can sue directly.
• The small-business exemption is being removed generally, with final phase-in scheduled for December 2026 — so even the non-care services would be captured soon.

Design consequences, which we build in rather than bolt on:

• Identity and credential documents encrypted at rest, never in a public bucket, served only through an authenticated, audited endpoint.
• Location history retained only for the life of the job plus a short dispute window, then deleted — not accumulated indefinitely.
• A partner's location is captured only while they are en route to an accepted job, never continuously. This is both a privacy position and a worker-surveillance one.
• Explicit, separately-recorded consent for photographs, location sharing and health information.
• Every read of a client's sensitive record written to an append-only audit log.
• A documented retention and deletion schedule, because "we kept everything forever" is itself a breach risk.

4.5 Sources

NDIS worker screening — NDIS Quality and Safeguards Commission · 2026 guide. Working With Children Checks — Queensland Government on interstate checks · state-by-state comparison. Aged Care Act 2024 — Aged Care Quality and Safety Commission · MinterEllison technical update. Nursing registration — AHPRA. Privacy — OAIC Guide to health privacy · OAIC on the small business exemption · Norton Rose Fulbright on the reforms. Gig-work regulation — Fair Work Ombudsman on employee-like workers · Fair Work Commission minimum standards order. Trade licensing and insurance — Trade Risk. Driver accreditation — Safe Transport Victoria · Service NSW.

5. Technology

The stack below is chosen for one overriding reason: it is the same stack already running five production applications on your VPS. That means no new deployment pattern, no new database engine, no new auth model, and a developer who already knows the operational shape of the box.

6. Databases & data model

One PostgreSQL database named wecare, with its own role, on the existing cluster. Roughly twenty tables. Nothing here justifies a second datastore, a document database or a cache layer — and each one we avoid is one fewer thing to secure, back up and keep consistent.

6.1 The tables that matter

6.2 The credential engine, concretely

This is the piece worth getting right, so here it is in full. Requirements are data, not code — adding a service or a state is an insert, not a deploy.

-- What the law requires: service × state → credential
service_credential_rules
  service_id        -> services.id        -- 'childrens_care'
  state             text                  -- 'NSW' | 'VIC' | 'QLD' | ...
  credential_type   -> credential_types   -- 'wwcc'
  is_mandatory      boolean
  max_age_months    integer               -- e.g. 36 for an aged-care police check
  notes             text

-- What a partner actually holds
partner_credentials
  partner_id        -> partner_profiles.id
  credential_type   -> credential_types
  identifier        text                  -- licence / clearance number
  issuing_state     text
  issued_on         date
  expires_on        date
  document_key      text                  -- encrypted object key, never a public URL
  verified_by       -> users.id           -- which admin sighted it
  verified_at       timestamptz
  status            enum('pending','verified','rejected','expired','suspended')

Allocation then reduces to a single question the database can answer:

-- Can this partner legally take this job, in this state, today?
SELECT NOT EXISTS (
  SELECT 1
  FROM   service_credential_rules r
  LEFT   JOIN partner_credentials c
         ON  c.credential_type = r.credential_type
         AND c.partner_id      = $partner_id
         AND c.status          = 'verified'
         AND c.expires_on      > current_date
  WHERE  r.service_id   = $service_id
    AND  r.state        = $job_state
    AND  r.is_mandatory
    AND  c.id IS NULL           -- a mandatory credential is missing or expired
) AS is_eligible;

6.3 Two deliberate choices

• job_events is append-only. Every transition — created, allocated, accepted, en route, arrived, completed, closed — is a row, never an update. When a client disputes a charge or a regulator asks what happened, the answer is a query, not a reconstruction.
• Rates are versioned, never edited. Changing a rate inserts a new rate_card with a new effective date. A job permanently records the rate card it was priced under, so last month's invoice never silently changes when the admin updates this month's pricing.

7. The job lifecycle

Every request gets a single human-readable reference used everywhere — in the app, in emails and on the phone. One identifier, not three.

WC-2026-014377

How the completion code actually works

• Generated only when the partner marks WORK_DONE — it cannot exist earlier, so it cannot leak earlier.
• Six digits, random, shown only in the client's own session.
• Stored hashed. A database read does not reveal live codes.
• Five attempts, then it locks and an admin must intervene — this stops a partner guessing their way to a close.
• Expires after 24 hours; an unclosed job escalates to the admin rather than sitting silently.

8. Maps, tracking & ETA

Two engineering decisions that control the cost

1. Do not call the Routes API on every location ping. The naive build recalculates the ETA on each update and the bill scales with the number of pings. Instead: recompute a real route every 60–90 seconds, and between recomputes update the displayed distance from straight-line movement. The client cannot tell the difference, and the call volume drops by more than an order of magnitude.
2. Always complete an Autocomplete session. Google bills autocomplete by session, and a session that ends in a Place Details call is currently free — while an abandoned session is charged. Wiring the flow so every address selection finishes properly is worth real money at volume.

9. Rates, hours & payments

How the admin controls pricing

A base rate per service, then modifiers that stack in a defined order:

Public holidays are state-specific in Australia, so the holiday calendar is keyed by state — a Melbourne Cup surcharge should not fire in Perth.

How hours are measured

The billing clock runs from geofenced ON_SITE to WORK_DONE, rounded to a configurable increment (15 minutes by default). Travel time is tracked separately and is not billed to the client unless the admin enables it for a service. The admin can adjust any timesheet, and every adjustment is logged with who made it and why.

What the admin sees

• Hours by partner, by service, by day, week or month
• Jobs completed per partner and the revenue against each
• Amount payable per partner for the period, net of any platform commission
• Average rating and any job that fell below a threshold

10. Alerts & the daily report

The end-of-day report

Sent to the admin by email at a configurable time — proposed 7:00 pm local time, so the trading day is genuinely finished. It is a real email with the numbers in the body, not a link to a dashboard, because it needs to be readable on a phone without signing in.

• Per partner — jobs completed, hours worked, revenue generated, amount payable
• Totals — jobs, hours, revenue, total payable
• Exceptions — jobs not closed, codes that locked, ratings of 3 stars or below, partners who did not arrive
• Tomorrow — jobs booked, and any that are still unallocated
• Compliance — credentials expiring within 30 days

11. One app, every device

You asked for the app to know whether it is on a computer or a phone and size itself accordingly. Here is how we do that, and one place where I would push back slightly.

It is installable from Chrome on both Android and iOS — the partner gets a home-screen icon and a full-screen app without an app store. Offline handling is limited but deliberate: a partner in a basement with no signal can still see today's jobs and addresses from cache, and any action they take is queued and sent when signal returns.

12. Timeline & effort

Built with Claude, full time. The estimate is in hours, because that is the unit that matters when one person can sit down and close the whole thing in a week.

The POC week, day by day

What the POC deliberately will not have

Saying this up front is what keeps the week to a week. None of it is hard; all of it is the second block of ~60 hours.

• Automated credential verification. The admin sights the document and ticks it. There is no AHPRA API to call anyway.
• Card payments. The POC calculates what is owed; money moves outside it.
• Encryption at rest for documents, and full audit logging. Required before a single real client, not before a demo.
• SMS and push. Email and in-app only.
• Load and penetration testing.

13. What it costs to run

13.1 Bluehost VPS — real prices

Self-managed VPS, taken from Bluehost's Australian pricing page in September 2026. Prices are AUD per month on a 24-month term, which is what the advertised rate requires.

NVMe 4 at A$13.24/month is the right size. For comparison, the VPS already running eleven production applications is an 8 vCPU / 31 GB box sitting at about 3% disk use. WeCare alone — Next.js plus Postgres — will not trouble 2 vCPU and 4 GB at POC or early-production volume.

13.2 If Sydney is not available — confirmed Australian alternatives

All of these have had a Sydney region for years, and all are self-managed in the same way, so nothing about the build changes.

Entry-level plans at all four start around A$6–9/month. Bluehost's NVMe 4 is genuinely cheaper than the US$24 tier — if Sydney is available. If it is not, the latency is worth more than the saving.

13.3 Everything else

13.4 Realistic monthly running cost

Build cost is your time — roughly one week for the POC and two more to pilot-ready. The costs your friend carries directly, and which dwarf the hosting, are legal advice, insurance premiums, any NDIS or Aged Care registration, and each partner's own screening checks.

14. Risks

15. Decisions owed before code starts

These are your friend's calls, not ours. Each one changes what gets built.

16. Who owns what

Your friend owns the business, the VPS, the domain and the data. We build the proof of concept. That is the right structure — it puts the obligations in §4 where they belong, with the person operating the business, rather than with the person who wrote the code. Three things make it actually hold, and none of them are expensive.

1 · Everything in his name from day one — not "transferred later"

2 · Never let real client data into the POC

3 · One page in writing — not a contract, just a record

You are not incorporating anything or hiring a lawyer. You just want it on record that you delivered a proof of concept, that the compliance research is research and not legal advice, and that operating the business — licences, insurance, screening, privacy obligations — is his. Something like this, by email, acknowledged with a "yes agreed", is enough: