Building Value Tracker: A Solo AWS Architecture for Enterprise Client Intelligence
- ampersonett
- Feb 1
- 4 min read
When leadership asks "how do we prove our value to clients?"—that's a data problem. And data problems are my favorite kind to solve.
The Challenge
My consulting firm needed a way to demonstrate tangible value to enterprise clients. The question from leadership was simple but pointed: Why should clients continue paying for our services? The answer wasn't going to come from anecdotes or quarterly slide decks. It needed to come from data—comprehensive, trackable metrics that could show engagement value at every level of a client relationship.
The requirements were ambitious:
Track metrics across complex client hierarchies (enterprise → business unit → team)
Support any metric type, frequency, or measurement approach—completely generic
Integrate data from client-provided sources
Provide different views for different audiences: Service Delivery Managers monitoring individual clients, executives reviewing portfolio rollups, and sales teams demonstrating capabilities to prospects
Enterprise-grade security throughout
There was no existing platform to buy. We needed to build it.
The Solution
I designed and built Value Tracker from scratch—a complete AWS data platform that I own end-to-end. No team. No contractors. Just me, translating business requirements into production infrastructure.

Architecture Overview
The platform follows a security-first design pattern:
Front Door Security
AWS WAF provides threat protection at the edge
Cognito handles authentication and authorization
API Gateway controls all access to backend services
Serverless Processing
Lambda functions handle API operations (GET/PUT endpoints)
No servers to manage, scales automatically with demand
Data Layer
RDS PostgreSQL for relational data and complex hierarchies
S3 for bulk data storage and data lake patterns
Integration & Reporting
Excel-based data ingestion for client metrics
EC2 SSL Gateway provides secure connectivity to BI tools
Tableau delivers interactive reporting with advanced drill-down functionality
Observability
CloudWatch for monitoring and alerting
CloudTrail for audit logging and compliance
The Hardest Part: API Security
The most challenging aspect wasn't the data modeling or the ETL pipelines—it was securing the APIs. When you're building a platform that will hold client engagement data, security isn't optional. I spent significant time ensuring that every endpoint was properly authenticated, that tokens were handled correctly, and that the attack surface was minimized.
This meant implementing proper Cognito user pools, configuring API Gateway authorization, setting up WAF rules to block common attack patterns, and testing extensively to verify that unauthenticated requests couldn't reach the data layer. It's the kind of work that's invisible when done right—but catastrophic when done wrong.
The Reality of Building in a Changing Environment
The build took approximately six months—but that timeline tells only part of the story. Requirements evolved throughout the project as stakeholders refined their understanding of what "demonstrating value" actually meant. New metric types emerged. Reporting needs shifted. The hierarchy model needed adjustment.
This is normal in enterprise environments, and it's why I designed the platform to be generic from the start. The data model doesn't care if you're tracking budget performance, innovation metrics, or something we haven't thought of yet. That flexibility wasn't accidental—it was architectural.
Who Uses It and How
Service Delivery Managers use Value Tracker to monitor their individual client engagements. They can see metrics trending over time, identify areas needing attention, and document the value being delivered.
Executives get rollup views across the entire client portfolio. Instead of aggregating spreadsheets from multiple SDMs, they can see enterprise-wide performance in a single dashboard.
Sales will use the platform to demonstrate capabilities to prospects. Rather than promising "we'll show you value," they can show exactly how that value gets tracked and reported.
How I Built It: AI as a Development Partner
I want to be transparent about something: I used AI as a development partner throughout this build.
I write code, but it's not my primary focus day-to-day. What I do have is 24 years of IT experience spanning infrastructure, security, databases, APIs, and data architecture—plus the ability to read and understand code across languages and platforms. That combination allowed me to design the system, make architectural decisions, and guide implementation effectively.
Here's how it worked in practice: I would define what needed to happen ("I need a Lambda function that validates the incoming payload, checks for required fields, and writes to the PostgreSQL database with proper error handling"). The AI would generate the code. I would review it, understand what it was doing, identify issues, and iterate. When something didn't work, I had enough technical depth to diagnose whether it was a code problem, a configuration problem, or an architectural problem—and direct the fix accordingly.
This isn't "AI built it for me." The architectural decisions—why Cognito instead of a custom auth solution, how to structure the API endpoints, what the data model should look like, how to secure the attack surface—those were mine. The implementation was collaborative.
I'm sharing this because I think it represents how technical leadership is evolving. The value I bring is understanding systems deeply enough to design solutions, evaluate implementations, and deliver working platforms. AI accelerates that. Fighting it or hiding it seems counterproductive.
The result speaks for itself: a production platform that solves a real business problem, built in six months, by one person.
What I Learned
Building a complete platform solo—even with AI assistance—reinforces something I've always believed: the best data leaders stay technical. It's easy to drift into pure strategy and advisory work—and that work matters—but there's no substitute for understanding the actual constraints and possibilities of the systems you're designing.
This project also reminded me that security architecture deserves as much attention as data architecture. In an era of increasing breaches and compliance requirements, the ability to design secure systems isn't a nice-to-have—it's a core competency.
Current State and What's Next
Value Tracker is live and functional. I'm currently refining the Tableau reporting layer, working on advanced drill-down functionality that lets users navigate seamlessly from enterprise summaries to individual engagement details. The platform will continue evolving as the business identifies new metrics and use cases.
The architecture is designed to grow. Adding new metric types requires no infrastructure changes. New integrations can plug into the existing API layer. And because it's built on serverless patterns, it scales without manual intervention.
This project represents my approach to data architecture: understand the business problem deeply, design for flexibility, build with security as a first principle, and stay hands-on through implementation. The best architectures aren't just technically sound—they solve real business problems.
Comments