Building Value Tracker: A Solo AWS Architecture for Enterprise Client Intelligence

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 Data Model: Designing for Flexibility from the Start

The architecture diagram shows how data moves. The data model shows what it's actually tracking — and the design decisions here were just as intentional.

The starting point was the hierarchy.

Client → Account → Statement of Work → Workstream.

Enterprise consulting engagements don't exist at a single level. You have clients, and within clients you have accounts. Within accounts you have Statements of Work (SOWs). Within SOWs you have workstreams. Value gets delivered — and needs to be demonstrated — at all of those levels, and that's how it was modeled. The org_hierarchy table ties everything together without forcing every entity into a rigid structure. A metric tracked at the workstream level rolls up to the SOW, to the account, to the client. That's what makes the executive portfolio view possible. The heart of the platform is a three-table pattern: master_metric, entity_metric_assignment, and entity_metric_actuals.

master_metric is the library of what can be tracked. entity_metric_assignment is where a metric gets connected to a specific engagement with its own target and configuration. entity_metric_actuals is where results live — actuals, targets, savings, breach indicators, review dates.

I designed it this way deliberately. Leadership didn't fully know at the start which metrics they'd need to track. Requirements were going to evolve. If I'd hardcoded specific metric types into the schema, every new requirement would have meant a schema change. Instead, adding a new metric is a data operation, not a development one. That flexibility wasn't an accident — it was the whole point.

The rest of the model supports operational reality: invoicing tied to hierarchy nodes, vendor relationships, contacts, and qualitative engagement results alongside the numbers. User and security tables were intentionally kept separate from the core data model so access control can evolve without touching business logic.

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.