page:blueprints:home services:inventory manager:next js

Home services: inventory manager using Next.js

Summary: A inventory manager blueprint for home services built with Next.js on Ample. Domain schema: services (sku, name, category, price_from, duration_estimate): service catalog as SKUs; parts_stock (sku, delta, reason, moved_at): parts and consumables movements; jobs (job_no, service_area, status, scheduled_for): jobs as orders with status transitions; job_lines (job_no, sku, qty): services and parts on a job; events (seq, record_type, record_id, kind, at): application-owned history written in the same transaction. Public information: service catalog and pricing from, service areas and hours, licensing and insurance summary. Kept out of scope until handling is reviewed: customer addresses and access notes, payment details. Customer addresses and access instructions are personal data; keep them out until handling is reviewed. Technical basis verified on Next.js: an optimistic version check and an event row written in the same transaction, a stale update rejected, and a history query over the application-owned events (history=2 conflict=rejected).

Representative Queries:

Resource Requirements:

Infrastructure Requirements:

  1. Compute: Apps run in isolated x86_64 Firecracker microVMs that auto-pause when idle and wake on request; sizes are the priced VM sizes.
  2. Postgres: Managed PostgreSQL 16 runs in its own microVM and is auto-provisioned when an app needs a database and no DATABASE_URL is supplied.
  3. S3-compatible object storage: Buckets are S3-compatible with issued credentials; PutObject and GetObject are verified by canary. Other S3 operations are not verified.

Framework: Next.js
Workload: Inventory manager
Industry: Home services
Release Status: published
Support Status: verified
Execution Status: ready
Docs Only: false

Prerequisites:

Workflow Steps:

  1. Model the home services domain: Create the tables services, parts_stock, jobs, job_lines, events. Service catalog as SKUs lives in services; keep the sensitive classes (customer addresses and access notes, payment details) out of this schema.
  2. Workflow step 1: Model SKUs and stock movements; derive stock from movements.
  3. Workflow step 2: Apply movements transactionally with an optimistic version check on the SKU.
  4. Workflow step 3: Record an event per movement for history.
  5. Workflow step 4: Deploy and verify history and rejected stale updates.
  6. Deploy: Run the synchronous deploy once and read the result. Re-running with no change is a no-op.
  7. Verify: Run the pattern self-test(s) from the example (/p/transactional-workflows) and your own acceptance checks for the home services workflow.

Examples:

Success Checks:

Limitations:

Cost Estimate: