Concept answer + first build pass
The portal should turn sales discovery, workflow maps, product builds, reports, and support into one durable workspace. Prospects get a useful reason to log in early. Clients get a living operating system. H&A gets a reusable intelligence layer across verticals.
Portal loop
Prospect → Client → Support → Intelligence
Profile
Who they are, how they talk, what they sell, and what matters now.
Process
The workflow map, source files, decisions, and visible build progress.
Results
Reports that prove the loop is running and improving.
Reuse
Anonymized learnings become H&A playbooks across similar clients.
Answered from H&A context
These are the working answers to the questions from the call, grounded in how H&A actually sells, builds, stages, supports, and learns from client work.
A limited but valuable workspace: their company profile, discovery recap, score/baseline, recommended first workflow, source upload checklist, and a preview of what H&A would operationalize. No internal pricing logic, strategy notes, or cross-client intelligence.
Start with six: Profile, Process Map, Build Room, Reports, Support + Contract, and Resource Library. That is enough to cover sales discovery, active delivery, and ongoing value without pretending this is full ERP.
Client-visible is approved operating work: workflow maps, sources, status, reports, action asks, and support artifacts. Internal-only is pricing, margin, model/tool cost, raw prompts, QA failures, sales strategy, private Ryan/Chad notes, and credentials.
Through an anonymized pattern library: vertical tags, workflow shapes, schema fields, checklists, scoring rules, report templates, and reusable playbooks. Client-specific data never becomes reusable content until stripped to a general pattern and approved.
Both, but with a clear split. oixai.io stays the public marketing and preview surface. The portal becomes the deeper product surface behind login. Public pages create trust; the client area creates retention.
Role-scoped access, audit logs, source separation, no secrets in the UI, no sensitive data in public previews, and AWS/Bedrock/Postgres/S3 as the production direction when regulated or sensitive data enters the system.
Minimum lovable portal
This first pass should prove the operating model and language. Live auth, database, and AI layers come after the schema is right.
Company facts, contacts, goals, vocabulary, constraints, data sources, and current status.
The workflow H&A is improving: people, steps, systems, files, decisions, and handoffs.
What is being built, what changed, what is blocked, what needs approval, and where to test.
The visible result of the process: throughput, response time, lead movement, bid readiness, follow-up completion, or other client-specific outcomes.
Support scope, active requests, renewal value, changelog, and what ongoing support covers.
Source files, call notes, SOWs, approved docs, client-safe explainers, and implementation references.
Data discipline
The point is not to build ATR, ONE30, Dromos, or SafeTeam again by hand. The point is to create a client profile model that can express each one.
Process documentation, approved source files, build status, reports, decisions needed, support status, meeting notes approved for sharing.
Pricing/margin, private sales strategy, raw prompts, tool/API keys, QA failures, model costs, vendor experiments, Ryan/Chad internal debates.
Industry learnings, workflow patterns, data schemas, checklists, automation recipes, and playbooks stripped of client identifiers.
Secrets, PHI/PII beyond approved scope, cross-client data, unpublished financial assumptions, internal fee logic, private credentials.
Production direction
First client-profile proof
These are intentionally not live data. They show how the same portal model can express different H&A work without changing the code structure for every client.
Estimator OS profile
Loop: Bid intake → missing-data check → estimator review → submission readiness → reporting.
Proof: Shows how a vertical-specific workflow becomes a reusable operating profile without hard-coding flooring forever.
Donor + staff workflow profile
Loop: Donor intake → family/kid matching → staff workflow entry → updates → reporting.
Proof: Shows how the portal can keep donor-facing views clean while giving staff a distinct Staff Area for operational workflow.
Website + operations profile
Loop: Brand assets → staged site changes → feedback ledger → approval → production promotion.
Proof: Shows client feedback, staging, and change logs as part of the portal, not buried in email threads.
Next build step
Next pass: prototype login picker, per-client workspace tabs, editable profile fields, local seed data, and an internal-only toggle so Chad/Ryan can test what the client sees versus what H&A sees.