Build a Customer Portal for a Service Business with AI — Auth, Requests, and Status

What the Portal Needs to Do

The core loop for a service business: customer signs up and logs in; submits a service request (type, description, photos, preferred date); sees the status of each request (received, scheduled, in progress, completed); views their history and invoices; and gets confirmations. Each of these is a standard pattern — the build is in wiring them together correctly, not inventing anything novel.

The Architecture, Plainly

Frontend: the generated React app with a login screen, a request form, a request list, and a detail view. Backend: an API layer with endpoints for auth, requests, and status updates. Database: one customers table, one requests table, one status-history table — relational by default (PostgreSQL), because 'which requests belong to which customer' is exactly what relational databases do. Hosting: your own cloud account, so customer data lives in infrastructure you control — which is also the compliance answer if the data includes addresses, phone numbers, or access instructions to homes.

Authentication: the Part to Get Right

The Data Model

Keep it boring and correct: customers (id, name, email, phone, address), requests (id, customer_id, service_type, description, photos, preferred_date, status, created_at), status_history (id, request_id, status, note, changed_at, changed_by). The AI generates this from a description like 'customers submit service requests and track their status; staff update status with notes.' Boring schemas are maintainable schemas.

What the AI Builds in One Session

A working portal — auth flow, request submission with photo upload, status timeline, customer history, and a minimal staff view for updating statuses — is a one-session build on Multos. The honest scope note: payment collection inside the portal, SMS notifications, and staff scheduling optimization are follow-up prompts, not first-session features. Build the core loop first, put it in front of five customers, then extend.

Verify Before Launch — the Checklist

One: the access-control test above. Two: photo uploads land in your storage with correct permissions. Three: email confirmations actually send (configure your provider; test from a real inbox). Four: the portal works on a phone — your customers will use it from a job site. Five: backups exist and you have restored from one. Six: the whole thing runs on your cloud account, so the data-residency answer to 'where is my customers' information?' is one you control.

What This Costs

Build: included in your token plan — the free tier can build it, Lite ($20/month) runs it comfortably. Running: your cloud account at cost — a small portal with modest traffic runs single-digit dollars per month on managed services. Compare that to the $15,000–$50,000 a custom portal quote typically starts at, and the maintenance retainer that follows it.