ClientPulse

Juggling dozens of clients? ClientPulse gives you a morning briefing, preps every call, and warns you when a client's gone quiet, right through Alexa+.

Comment

Inspiration

Freelancers rarely lose clients because they lack a CRM. They lose them because important signals get scattered across tools: a note in the CRM, an overdue invoice in a billing app, a promise made on a call two weeks ago that nobody wrote down. As a freelancer myself, I wanted an assistant that could pull all of that together and just tell me, in plain language, who needs my attention today and why.

Alexa+ MCP felt like the right fit for this. Voice is the fastest way to get a briefing before you're already juggling five other things, and MCP gave me a real, open standard to build against instead of a closed integration.

What it does

ClientPulse is a voice first client ops assistant for freelancers and small agencies, built as a real MCP server for Alexa+.

  • Gives a morning briefing of which clients need attention today
  • Preps you for any client call with full context and an AI generated recommendation
  • Tracks overdue invoices
  • Flags clients who have gone quiet before the relationship goes cold
  • Remembers commitments and notes across sessions, so a promise made today shows up automatically the next time you prep for that client

How I built it

The server is a Python FastMCP implementation of the MCP spec (2025 11 25), running over Streamable HTTP, with five tools exposed to Alexa+.

The architecture deliberately separates two paths. In the background, client and invoice data feed a deterministic, rules based scoring engine, and an AWS Strands agent calls Amazon Bedrock (Nova Micro) to turn those scores into a short, human readable explanation and a recommended next action. That result gets cached in DynamoDB. On the live voice request path, Alexa+ only ever reads from DynamoDB, so responses stay fast instead of waiting on a live LLM call.

Amazon Cognito handles OAuth 2.1 account linking for the MCP server, and the whole thing is packaged as a container for AWS Lambda using the Lambda Web Adapter, so it can run as a small, cheap, mostly serverless service.

I also built a small MCP App style visual card so a client briefing shows up as something you can glance at, not just hear.

Challenges I ran into

The biggest challenge had nothing to do with the code. My AWS account, created fresh for this hackathon, turned out to be placed in a sandboxed environment with organization level policies that silently block most compute and database services outside of a couple of specific regions, with no clear warning in the console. On top of that, Bedrock and Lambda both returned account level access errors with almost no descriptive message, which turned out to be a known issue for new accounts that only AWS Support can resolve.

Rather than let that block progress, I designed the whole pipeline so the AI reasoning layer is swappable: a mock model stands in for Bedrock during local development, and the real Strands plus Bedrock integration is a single environment variable away once account access is confirmed. That decision meant the entire product, all five tools, the scoring engine, the visual card, and the persistent memory, could be built and fully tested before AWS support even responded.

Accomplishments that I'm proud of

  • Built and verified a real, spec compliant MCP server end to end with the official MCP Inspector, all five tools discoverable and callable, before touching Alexa+ itself
  • Designed an architecture where the AI layer is fully swappable, so the product could be built and tested completely offline while waiting on AWS account access
  • Got persistent memory actually working: a commitment recorded through one tool call shows up automatically in a later call prep, proving the assistant carries context across sessions instead of just answering one off questions
  • Kept the AI honest by never letting it compute a priority score itself, every score comes from deterministic rules, and the model only explains and recommends
  • Diagnosed and worked around a genuinely obscure new account AWS restriction (region locked service control policies, undocumented Bedrock and Lambda access blocks) by reading raw policy JSON and cross referencing community reports, rather than getting stuck
  • Designed the whole system to run within AWS free tier limits, with explicit call caps and no always on infrastructure

What I learned

Separating deterministic logic from AI reasoning turned out to matter more than I expected. Having Python decide what counts as "stale" or "overdue," and letting the model only explain and prioritize, kept the system fast, cheap, and easy to trust, and it also made it possible to build and test the whole thing offline.

I also learned a lot more than I wanted to about AWS account provisioning edge cases, and that a support ticket is sometimes the correct engineering response to a blocked API call.

What's next for ClientPulse

The natural next steps are a real GHL integration alongside the demo data, a proper invoice provider adapter (Stripe or QuickBooks), and expanding the background worker into a fully scheduled EventBridge job now that the underlying pipeline is already built and tested.

Built With

Share this project:

Updates

Submission history