Apparel Company Looking for Web based Production Software Creation

Operations System — Build Brief (Self-Hosted)
1) Objective
Build a self-hosted business operations web app to manage Rapid Hockey’s internal workflow for:
orders (including team/program orders and online “store/popup” style orders)
customers/organizations/contacts
products/SKUs
payments/invoices
production/fulfillment statuses
internal notes, files, and task-like follow-ups
The system must replace an Airtable-style internal database with a custom, relational database-backed application that runs on our current web host.
2) Hosting and Cost Constraints
The application must be self-hosted on our existing hosting environment.
Avoid solutions that require multiple monthly SaaS subscriptions to operate the core system.
Acceptable: domain email/SMTP, payment processor fees, shipping label fees (usage-based), etc.
Source code and database must be owned and transferable to another host.
3) Users and Permissions
Implement role-based access:
Roles
Admin: full access to all records, settings, user management
Staff: access to day-to-day operational modules (orders, payments, production, fulfillment), cannot edit system settings
Read-Only (optional): view access for certain stakeholders
Core requirements
Secure login
Password reset
Audit log (record create/update/delete + user + timestamp)
4) Core Data Model (Relational)
Build a relational schema with these core entities (tables). Exact naming can vary.
Organizations
org_name
org_type (club, school, adult league team, etc.)
billing address / shipping address fields
primary contact reference
notes
Contacts
first_name, last_name

email, phone
role/title
linked to Organization
notes
Orders
order_id (human-readable ID with prefix + sequence)
order_type (custom/team order, online store/popup, etc.)
organization/contact linkage
order_status (see Workflow section)
order dates: created, due date, shipped date, closed date
shipping method
totals: subtotal, tax, shipping, discounts, total
internal notes
attachments
Order Line Items
linked to Order
linked to Product/SKU
description override (optional)
qty
unit price
line total
size/color/variant fields (as needed)
Products / SKUs
SKU / model number
product type (ice jersey, socks, pant shell, bag, etc.)
attributes (variant fields as needed)
active/inactive
base price (optional)
Payments
payment_id (human-readable ID with prefix + sequence)
linked to Order
amount
payment method (card, check, ACH, etc.)
payment date
status (pending/paid/refunded/etc.)
external transaction reference (if using a processor)
notes
Invoices (Optional but recommended if you separate from Payments)
invoice_id
linked to Order
issued date, due date
status (draft/sent/paid/partial/void)
totals
Production / Fulfillment Records
linked to Order
production_status + fulfillment_status
key milestones (art approved, sent to factory, in production, received, packed, shipped, delivered)
carrier/tracking
shipment packages (optional)
Internal Notes / Activity Feed
linked to Orders/Orgs/Contacts
note body
author + timestamp
----------
Files / Attachments
store uploaded files (art proofs, packing slips, etc.)
linked to relevant record(s)
permissions: internal only
5) ID / Numbering Requirements
Create human-readable IDs similar to Airtable-style record IDs.
Examples (format can be finalized by developer, but must be configurable):
Orders: ORD-YYYY-##### or ORD-#####
Payments: PMT-ORD-#####-## (payment sequence per order)
Invoices: INV-#####
Rules:
IDs must be unique.
IDs must be generated server-side (not client-side).
Payment sequence increments per Order (01, 02, 03…).
6) Workflows and Statuses
Implement statuses as configurable enums (admin editable list), but seed with defaults:
Order Status (example default set)
New
Awaiting Artwork
Artwork in Progress
Awaiting Approval
Approved / Ready for Production
In Production
Received / In House
Packed
Shipped
Closed
On Hold / Cancelled
Payment Status
Pending
Paid
Partial
Refunded
Void
Fulfillment
Not Started
Packing
Shipped
Delivered
Requirements:
Status changes should be logged in the activity feed/audit log.
Allow filtering and saved views by status.
7) Core UI Requirements (Admin App)
Build a web-based admin interface with:
Global
Search bar across Orders, Orgs, Contacts
Filters + sorting on list pages
Pagination
Export CSV for list views
“Saved views” (optional)
Orders Module
Order list with filters (status, due date, org, type)
Order detail page includes:
header fields (org/contact, dates, status, totals)
line items table
payments summary + add payment
production/fulfillment section
internal notes + attachments
Ability to duplicate an order (optional)
Organizations/Contacts
CRM-style pages showing linked orders and notes
Products
SKU list + basic product management (create/edit/disable)
8) Reporting (Minimum Set)
Provide a reporting section with:
Orders by status (counts)
Orders due within X days
Sales totals by month (based on paid orders or payments—define logic)
Outstanding balances per order
(Exact reports can be expanded later; prioritize correct data model first.)
9) Integrations (Optional/Phase 2 if needed)
These should not be required for v1 unless specified:
Payment processor integration (e.g., Stripe) via API/webhooks
Shipping label purchase + tracking sync (UPS/FedEx/Shippo/etc.)

Email notifications (SMTP): invoice sent, shipment confirmation, internal alerts
If integrations are added, they must be modular and not lock the system into a paid platform for core operations.
10) Non-Functional Requirements
Responsive UI (desktop-first, works on mobile)
Security best practices (OWASP basics)
Daily automated backups (DB + uploaded files)
Basic performance targets: list views should load quickly with thousands of orders
Staging environment recommended (separate from production)
11) Deliverables
Developer must deliver:
Source code repository (with clear license/ownership to Rapid Hockey)
Database schema + migrations
Deployment instructions for our hosting environment
Admin user creation process
Backup/restore procedure
Minimal documentation:
how to add/edit statuses
how IDs are generated
how roles/permissions work
12) Acceptance Criteria (Definition of Done for v1)
System is accepted when:
Users can log in with roles
Orders can be created/edited with line items
Orders link correctly to Organizations and Contacts
Payments can be recorded against orders with correct sequencing
Status workflows work and are filterable
Search + CSV export works
Audit/activity logging exists
App is deployed on our host with backup process documented