How I Built an AI-Native Client Portal That Runs My Entire Consulting Practice

Tuesday afternoon. A client emails about a deliverable timeline. I open my Claude project, type "update the brand guide deliverable to delivered and post an update that it's ready for review." Done. Portal updated, client notified, activity feed populated.

Wednesday morning. A prospect needs a custom proposal. I describe the engagement in plain English: scope, phases, pricing tiers, deliverables. The system generates the proposal structure, inserts it into Supabase, and renders it at their portal URL. Twenty minutes from conversation to client-ready.

Thursday evening. A project hits a blocker. I log it from my phone. By morning, the client's portal shows the updated timeline, the decision item is queued for their input, and my briefing tells me what's waiting.

This isn't productivity theater. It's what consulting operations look like when you stop managing engagements across six disconnected tools and build everything around how you actually work.

Most consultants I know live in tool-switching hell. Slack for messages, email for follow-ups, Google Drive for files, Stripe for payments, Asana for status, Toggl for time, a separate system for proposals. Context dies in the transitions. Work gets recreated instead of reused. Clients feel the friction even if they can't name it.

I built the opposite: a client portal that covers every stage of the Bowtie engagement lifecycle, from proposal through case study, where the entire operations layer runs through chat with AI agents that understand my business.

The part that makes people do a double-take: there is no admin dashboard I log into to update a deliverable status. No separate time tracking app open in another tab. No project management tool where I drag cards between columns. The chat IS the operations layer. Everything that isn't fully automated is chat-based, and every session loads with the full context of every active engagement. I don't get up to speed. The system is already there.

Here's how I built it and what I've learned running real client engagements through it.

How AI Changes Client Acquisition for Consultants

Prospect Research Without the Manual Work

The portal starts where real business starts: in the CRM. Every company, contact, and deal lives in HubSpot, and every portal client record links back through hubspot_deal_id and hubspot_company_id. No dual data entry. No sync gaps.

Where AI changes this: my agents research prospects before I write a single proposal line. I type "research Acme Corp for the enterprise RevOps engagement" and get back company size, tech stack, recent funding, leadership changes, competitive landscape, and pain points visible in their job postings. All stored in vector memory and available when I'm crafting their proposal days later.

By the time I'm scoping work, I'm not starting cold. I'm building on enriched context that makes every recommendation specific to their situation.

Building Interactive Consulting Proposals from Chat

Traditional proposals are dead documents. PDF attachments that clients download, maybe read, hopefully sign. Mine render in-browser as interactive experiences backed by JSONB in Supabase.

Each proposal has flexible content sections, multiple pricing tiers with a recommended badge, per-phase cost breakdowns with side-by-side comparison, collapsible engagement terms the client must acknowledge before accepting, and validity dates that create real urgency.

I don't build these manually. I describe the engagement in chat ("3-month HubSpot optimization for mid-market SaaS, includes pipeline audit, lead scoring rebuild, and sales process documentation") and the system generates the entire proposal structure. Pricing matrix, timeline, deliverables, terms. It's not template-filling. It's dynamic generation based on stored frameworks, pricing patterns, and client-specific context from the research phase.

Digital Proposal Acceptance and Automated Milestone Payments

Digital acceptance captures name, email, explicit agreement to terms, and timestamps everything for an audit trail. On acceptance, Stripe payment links auto-generate for each milestone. Non-blocking, so the portal works even without Stripe configured.

For milestone-based engagements, each phase gets its own Stripe checkout with status tracking. Payment CTA banners surface contextually ("Ready to get started?" for the first milestone, "Next payment due" for subsequent ones). When a client completes payment and Stripe redirects them back, the portal detects the ?payment=success parameter and shows a confirmation toast.

Stripe webhooks flow through Express into Supabase. Payment status propagates everywhere without me touching anything. I get notified when payments clear, clients see updated status immediately, and budget tracking adjusts in real-time.

What Consulting Onboarding Looks Like Without Email Tag

Most consulting onboarding is email tag. "Please send us your login info, your analytics access, and your brand guidelines." Clients lose emails, forget steps, share credentials in plain text over Slack.

My onboarding lives in the portal as a structured checklist with four step types:

→ Action items: connect your HubSpot portal, schedule the kickoff call → Information requests: text input for things like annual revenue, current team structure, goals for the engagement → Credential collection: encrypted forms with custom fields per step, server-side encryption, admin-only decrypt endpoint → File uploads: drag-and-drop to Supabase Storage with signed URLs, organized by step

Progress tracking shows required versus optional items. Every step has an "I need help" button that captures a note and flags it for my attention. I see those flags in my morning briefing, not buried in an inbox.

The AI-native flow: I configure onboarding steps from chat. "Add a credential step for their HubSpot admin login, an upload step for brand assets, and an info step asking about their current sales process." System creates the steps, sets up encryption, generates help text. Client sees it immediately. When they request help, I get context: not just "I need help" but which step, what type, and any note they left.

Delivering Client Value Without Switching Tools

Project Management Through Conversation

This is the stage where disconnected tools hurt the most. Traditional project management forces you to manually update status in one tool, upload deliverables in another, send update emails separately, and hope you remembered to log your time. I do all of that from conversation:

"Mark the pipeline audit deliverable as complete, attach the report URL, and post a project update that the audit is ready for review."

"Log today's strategy call. We decided to prioritize lead scoring over deal stages, create a decision item for the client to confirm, and set the next action item as data audit by Friday."

One message. Multiple systems updated. Client sees it in their portal. The data structure, notifications, audit trails, and status propagation happen automatically. I handle the thinking and the relationship.

Projects organize into phases (upcoming → active → complete), each with deliverables that track status progression (pending → in_progress → delivered → approved), file attachments, delivery dates, and due dates. The client's dashboard shows overall progress computed from deliverable completion, active phase count, and per-phase breakdowns.

The activity feed supports typed project updates (milestones, deliveries, status changes, notes) with pinnable entries and markdown content. This is my main async communication channel with clients.

Decisions surface when blockers appear. When I identify something that needs client input ("we need to choose between Zenoti or Mindbody for the booking integration") I create a decision item from chat. It shows up in the client's portal with options, context, and a response workflow (approve, approve with comments, request revision). Blocking items get flagged so nothing stalls silently.

Client messaging is categorized (question, feedback, scope change, general) with subject lines and status tracking. When a client sends a message, I get an email and Slack notification immediately. I reply from the admin portal, and the response shows up inline in their message history.

How Meeting Notes Write Themselves

This is one of my favorite features because it eliminates the work I used to dread most: writing meeting notes.

Here's the pipeline: a Gmail trigger detects Fireflies meeting recap emails → the system fetches the full transcript via the Fireflies API → Claude extracts meeting type, decisions made, action items, and key topics → it creates a portal meeting entry with the summary, generates trackable action items with assignees, logs WCP tasks for follow-up, and posts a Slack digest. All within about 3 minutes of meeting end.

Client calls become searchable knowledge in the portal instead of forgotten conversations. Action items get tracked with completion toggles. Both the admin and client can see progress. I don't write meeting notes manually anymore. They populate from the conversation that actually happened.

Shared Resources and Knowledge Sharing

Shared documents live categorized as document, design, deliverable, or reference, all accessible from the client's Resources tab. Shared credentials (for logins we both need access to) stay encrypted but accessible. Per-client FAQ content builds over time from repeated questions, stored as JSONB on the client record.

Running User Acceptance Testing from Chat

UAT in most consultancies is "does it look right to you?" followed by crossed fingers. Mine runs as a formal lifecycle: draft → internal review → published → completed. Clients only see published rounds.

Each UAT item has dual-track status. I review internally (pending/pass/fail/blocked/skipped) and the client reviews separately (approved/issue). Verification checklists give step-by-step checks per item, with independent progress for admin and client. Clients can attach screenshots to items. Full status history creates an audit trail: who changed what, when, with notes and retest round numbers.

From chat: "Create a UAT round for the lead scoring rebuild with items for each rule we configured." The system generates the round, and I toggle my internal testing status from chat as I work through items.

Tracking Consulting Impact with Built-In Metrics

Measuring consulting impact usually means screenshotting dashboards and hoping clients remember baseline numbers. My portal tracks metrics with baseline values, scheduled check-ins, and auto-computed deltas.

I define metrics when scoping the engagement: "track documentation time per session with a baseline of 45 minutes, check in every 2 weeks." The system creates the metric, sets the baseline, and generates the check-in schedule. When clients record values, I see the trend without pulling a separate report. Categories cover whatever matters for the engagement: revenue metrics, conversion rates, cycle times, efficiency gains.

Turning Completed Projects into Case Studies Automatically

When a project wraps successfully, case study generation pulls from engagement data already in the portal: deliverables completed, metrics achieved, meeting history, project timeline. The client reviews and approves directly in their portal with logo permission choices (full branding or anonymized), space for a testimonial, and a star rating.

Published case studies feed directly to geekeri.com/case-studies, with service offering suggestions alongside them for natural expansion conversations.

The Consultant's Operations Dashboard

Managing Multiple Client Projects in One Portal

Parent/child client hierarchy handles enterprise clients with multiple workstreams. The parent view shows a project selector; child projects load independently at bookmarkable URLs.

How a Weighted Health Score Keeps Every Client on Track

When no client is selected, the admin dashboard shows health scores across all active projects. The formula is weighted: time budget health (25%), payment status (20%), open messages (20%), deliverable progress (20%), and onboarding completion (15%).

The weights reflect what actually matters in consulting relationships. Time budget gets the highest weight because scope creep kills margins silently. Open messages and payments share second place because responsiveness and cash flow are equally critical to relationship health. Deliverable progress measures execution. Onboarding completion indicates engagement momentum.

Alerts surface automatically when thresholds are crossed: messages unanswered too long, budget approaching the cap, onboarding steps requesting help, unresolved UAT issues.

Time Tracking Without Leaving Chat

Toggl integration provides 7 direct MCP tools I call from chat: start timer, stop timer, log manual entry, check current status, get entries by date range, list projects, create projects. No app switching for time tracking.

Budget bars in the admin view go violet → amber at 75% → red over budget. Per-deliverable, per-phase, and project-total rollups. Clients see status pills (in progress, complete) but not hours. The budget visibility is consultant-side only.

Seeing What Your Clients See Before Publishing

Admin preview mode (?preview=all) lets me see exactly what the client sees before I publish onboarding steps, UAT rounds, or project updates. I can also preview specific views with ?preview=kickoff,uat,metrics.

The admin portal runs in dark theme while the client portal is light. Instant visual context switching. When I'm in the dark UI, I'm in operations mode. When I'm previewing the light UI, I'm seeing the client experience. Simple, but it prevents mistakes.

Row-Level Security and Encrypted Credential Storage

Supabase Auth handles email/password with verification, password reset, and session refresh on tab focus. Row-Level Security gates every table at the database level. portal_my_client_ids() scopes queries so clients see only their own data, and portal_is_admin() gives me access to everything. Credential storage uses server-side encryption with an admin-only decrypt endpoint. No credentials are ever stored in plain text.

What Changes When You Stop Context-Switching

Three things changed when I stopped managing engagements across separate tools.

Context stopped dying between sessions. Every Claude project session loads with full client context from Supabase, WCP, HubSpot, and Obsidian. I don't spend the first 10 minutes of every work session figuring out where I left off. The system knows what's active, what's waiting, and what needs attention.

Morning briefings replaced inbox scanning. Scheduled briefings pull open messages, help requests, approaching deadlines, time budget status, and payment state across all clients every morning. I start the day knowing exactly what needs my attention, prioritized and contextualized. On Mondays, I get week-over-week goal comparisons. On Fridays, metric deltas and a wins/improvements retro.

Proposals went from half-day projects to single-session outputs. Not because I'm cutting corners. The research, pricing, and structure are more thorough than what I used to produce manually. But I'm not recreating work. Frameworks carry forward. Client context is pre-loaded. The conversation becomes the deliverable.

There are rough edges. Some features I haven't built yet: deliverable approval workflows, invoice PDF generation, client-side file uploads from the admin dashboard. The notification system could be smarter about batching. Multi-timezone support for international clients needs work. It's a real system built for a real practice, which means it's perpetually 80% done and getting better each week.

The Tech Stack Behind an AI-Native Client Portal

For the technically curious: React + Vite + Tailwind frontend. Express 5 backend. Supabase for data, auth, storage, and RLS. Stripe for payments with webhook processing on Express (not Supabase Edge Functions; cold starts and silent failures taught me that lesson).

20+ Supabase tables backing the portal. 7 direct Toggl MCP tools. Automated Fireflies transcript processing. Scheduled briefings via macOS launchd. Everything config-driven: agents, skills, and tools defined in JSON files. The whole system runs locally on my machine.

I built this because I kept losing context between tools and recreating work I'd already done. The portal is the fix. Not a product I'm selling. The infrastructure that makes my consulting practice run the way I think it should.

If you're running client-based work and spending more time on operations overhead than on actual client value, the gap between "tools that manage work" and "tools that do work alongside you" is worth closing. That's what AI-native operations means to me: not AI as a feature, but AI as the way the work happens.

Frequently Asked Questions

What happens to client data if something goes wrong with the system?

Everything's in Supabase with daily automated backups and point-in-time recovery. Clients can export their full project history anytime. If they want to leave, their data goes with them.

How do you handle clients who prefer traditional communication?

The portal doesn't replace email and phone calls. It catches everything in one place. Email notifications flow from portal activity. Meeting notes from traditional calls get logged automatically via the transcript pipeline. The difference is that nothing stays scattered across inboxes and file shares.

Isn't this overkill for smaller engagements?

The system scales down naturally. Single-phase projects use fewer features. Simple engagements skip UAT workflows. But even small projects benefit from structured onboarding, centralized communication, and automated updates. The overhead was in building it once. Using it repeatedly costs almost nothing.

How much does it cost to run?

Core infrastructure runs about $200/month: Supabase Pro, Stripe processing, file storage, API usage. Development investment was substantial, hundreds of hours over several months. But it's reusable infrastructure that improves with each engagement, not custom work per client.

What if clients don't want to use a portal?

Nobody's forced into it. Clients can get project updates via email and share files however they prefer. But portal users get faster responses and better visibility into what's happening. Most start using it on their own once they see how organized everything is compared to the usual email-and-Drive approach.

How do you make sure AI-generated content stays accurate?

Every AI output goes through validation. Proposals and client communications get human review before sending. Financial calculations use deterministic rules, not generation. The AI handles structure, routing, and formatting. I handle strategy, accuracy, and the relationship. Audit trails on everything.