Dev

app/insights/[slug]/page.tsx

@@ -27,6 +27,7 @@ export async function generateMetadata({ params }: PageProps): Promise<Metadata>
   return {
     title: insight.title,
     description: insight.description,
+    keywords: insight.tags,
     alternates: { canonical: `/insights/${slug}` },
     openGraph: {
       title: insight.title,

app/work/[slug]/page.tsx

@@ -34,6 +34,7 @@ export async function generateMetadata({ params }: PageProps): Promise<Metadata>
   return {
     title: caseStudy.title,
     description: caseStudy.impact,
+    keywords: [...(caseStudy.keywords ?? []), ...caseStudy.techs],
     alternates: { canonical: `/work/${slug}` },
     openGraph: {
       title: caseStudy.title,

content/work/automated-reporting.md

@@ -2,7 +2,8 @@
 title: "Automated Financial Reporting Suite"
 date: "2025-03-01"
 techs: ["aws", "python", "redshift", "serverless", "glue"]
-impact: "Reduced month-close IFRS 17 reporting from a manual month-long process to an auditable run that completes in under 15 minutes."
+keywords: ["automated reporting", "financial reporting", "IFRS 17 reporting", "reporting pipeline", "month-end close automation"]
+impact: "Built an automated reporting pipeline that reduced month-close IFRS 17 reporting from a manual month-long process to an auditable run under 15 minutes."
 priority: 4
 category: reporting
 role: "Led planning, architecture, delivery, and handoff"
@@ -43,7 +44,7 @@ The validation rules had to work for governance and finance, not just the techni
 
 ## The solution
 
-I led a team that designed and delivered a Glue-based reporting pipeline. It validates and normalizes every source into Parquet in S3. The workflow cleans up intermediate files, applies the required transformations, and produces the month-close output finance needs.
+I led a team that designed and delivered an automated, Glue-based reporting pipeline. It validates and normalizes every source into Parquet in S3. The workflow cleans up intermediate files, applies the required transformations, and produces the month-close output finance needs.
 
 Validation rules live in CSV files. The files list human-readable rule names that map directly to the functions running against each column. Governance and finance could review the rules in a format they understood, while the technical implementation stayed controlled and traceable.
 

content/work/billing-site.md

@@ -2,6 +2,7 @@
 title: "Billing & Payment Processing System"
 date: "2024-08-01"
 techs: ["aws", "typescript", "python", "serverless"]
+keywords: ["billing system", "payment processing", "self-service billing", "insurance billing"]
 impact: "Delivered a self-service billing update flow for a 50k-member insurance program in three weeks, moving routine card changes out of the call center."
 priority: 7
 category: payments

content/work/data-warehouse.md

@@ -2,7 +2,8 @@
 title: "Data Warehousing & Infrastructure Build"
 date: "2024-06-01"
 techs: ["aws", "python", "redshift", "serverless", "splunk"]
-impact: "Gave a major insurer control over its data landscape across 150+ daily extracts and 5 external companies."
+keywords: ["data warehouse", "enterprise data warehouse", "data platform", "ETL pipeline", "data governance"]
+impact: "Built an AWS data warehouse that gave a major insurer control over its data landscape across 150+ daily extracts and 5 external companies."
 priority: 1
 category: data
 role: "Spearheaded architecture and multi-year delivery"
@@ -23,7 +24,7 @@ context:
 
 A major insurer depended on more than 150 daily data extracts across five external companies. The data arrived in different formats, mainly CSV, with some JSONL, TXT, and Excel files.
 
-The company had no central warehouse and no governed data model. Data lived in disconnected extracts, vendor handoffs, and local reporting processes. It could take months before data became usable for broad analysis.
+The company had no central data warehouse and no governed data model. Data lived in disconnected extracts, vendor handoffs, and local reporting processes. It could take months before data became usable for broad analysis.
 
 That meant the organization did not really control its own data. Teams could not rely on a shared view of customers, partners, products, and operations. Many decisions happened without trusted data because the data foundation did not exist.
 
@@ -80,6 +81,6 @@ The company gained control over its own data instead of depending on disconnecte
 
 ## What this proves
 
-This project shows that I can lead enterprise-scale data-platform work across architecture, governance, delivery, and operations over a long horizon.
+This project shows that I can lead enterprise-scale data warehouse and data-platform work across architecture, governance, delivery, and operations over a long horizon.
 
 The work required more than building ETL. It required shaping a multi-year platform plan, coordinating data governance, designing quality controls, and delivering usable pieces over time without waiting for a single waterfall launch.

content/work/integration-platform.md

@@ -2,7 +2,8 @@
 title: "Unified Cloud Architecture"
 date: "2025-12-01"
 techs: ["azure", "typescript", "iac", "containers"]
-impact: "Turned an expensive SaaS purchase into board approval for an eight-person in-house cloud platform build."
+keywords: ["integration platform", "cloud integration platform", "cloud architecture", "infrastructure as code", "build vs buy"]
+impact: "Turned an expensive SaaS purchase into board approval for an eight-person in-house cloud integration platform build."
 priority: 3
 category: infrastructure
 role: "Built the target architecture and board case"
@@ -23,7 +24,7 @@ context:
 
 The business was ready to buy a SaaS product to patch a gap in the integration layer. The purchase would have added another vendor, another contract, and another disconnected system.
 
-The annual cost sat in the six-to-seven-figure range. The larger issue was architectural. The company did not need another isolated product. It needed a repeatable way to build and operate cloud-native services.
+The annual cost sat in the six-to-seven-figure range. The larger issue was architectural. The company did not need another isolated product. It needed its own integration platform: a repeatable way to build and operate cloud-native services.
 
 ## The stakes
 
@@ -43,7 +44,7 @@ The design had to include security, logging, monitoring, auditing, compliance, a
 
 ## The solution
 
-I proposed one cloud architecture instead of a bolt-on SaaS purchase.
+I proposed a shared cloud integration platform instead of a bolt-on SaaS purchase.
 
 The model used a shared communication layer, cloud-native compute for services and applications, and infrastructure as code for repeatable deployment. The services shared the same operating layers: security, logging, monitoring, auditing, compliance, and enterprise standards.
 

content/work/payment-rebuild.md

@@ -2,7 +2,8 @@
 title: "Enterprise Payment Integration"
 date: "2025-01-01"
 techs: ["aws", "python", "serverless", "legacy"]
-impact: "Stabilized a high-risk claims payment workflow that had been failing monthly and costing millions in outage impact."
+keywords: ["payment rebuild", "payment integration", "payment processing", "claims payment workflow", "legacy system modernization"]
+impact: "Rebuilt a high-risk claims payment workflow that had been failing monthly and costing millions in outage impact."
 priority: 5
 category: payments
 role: "Led architecture, controls, and delivery"
@@ -82,6 +83,6 @@ Every payment can be traced from source file to normalized output to bank receip
 
 ## What this proves
 
-This project shows that I can stabilize a high-risk financial workflow without hiding complexity behind manual support.
+This project shows that I can lead a high-risk payment rebuild without hiding complexity behind manual support.
 
 The work required architecture, controls, payment traceability, retry design, and business signoff. It turned a fragile monthly failure point into an auditable payment process.

content/work/sdlc-revamp.md

@@ -2,7 +2,8 @@
 title: "SDLC & Deployment Automation"
 date: "2025-09-01"
 techs: ["azure", "azure-pipelines", "iac", "powershell"]
-impact: "Cut deployment time from a week to four hours, bug to production."
+keywords: ["SDLC", "deployment automation", "release management", "CI/CD pipeline", "DevOps"]
+impact: "Modernized the SDLC to cut deployment time from a week to four hours, bug to production."
 priority: 2
 category: infrastructure
 role: "Led release-process modernization"
@@ -43,7 +44,7 @@ Azure Pipelines fit company policy, so the solution had to work inside that tool
 
 ## The solution
 
-I led the release-process modernization around Azure Pipelines and a structured branching model.
+I led the SDLC and release-process modernization around Azure Pipelines and a structured branching model.
 
 The team released from a release branch. The pipeline built the artifact once, tagged it with a build ID, and promoted that same artifact through the environments. The tag linked the deployed build to the release ticket and the user stories included in the release.
 

content/work/student-pipeline.md

@@ -2,7 +2,8 @@
 title: "Enrollment Processing System"
 date: "2023-12-01"
 techs: ["aws", "typescript", "python", "serverless", "splunk"]
-impact: "Removed a week-long manual enrollment delay for 1M+ students."
+keywords: ["student pipeline", "enrollment processing", "student data pipeline", "SFTP integration", "reconciliation workflow"]
+impact: "Rebuilt the student enrollment pipeline to remove a week-long manual delay for 1M+ students."
 priority: 6
 category: infrastructure
 role: "Led architecture and delivery"
@@ -78,6 +79,6 @@ The business gained a traceable path from source file to student state to TPA de
 
 ## What this proves
 
-This project shows that I can turn brittle reconciliation work into a controlled integration process for 1M+ people.
+This project shows that I can turn brittle reconciliation work into a controlled student enrollment pipeline for 1M+ people.
 
 The work required judgment around state, exceptions, business signoff, and operational support. The result changed how enrollment work ran every cycle.

content/work/tableau.md

@@ -2,6 +2,7 @@
 title: "Tableau Integration"
 date: "2025-01-01"
 techs: ["tableau", "aws", "redshift", "python", "ec2"]
+keywords: ["Tableau integration", "business intelligence", "BI platform", "data visualization"]
 impact: "Created a governed BI platform so business teams could access warehouse data directly."
 priority: 8
 category: reporting

lib/content.ts

@@ -95,6 +95,7 @@ export function getCaseStudies(): CaseStudy[] {
       date: requireString(entry, "date"),
       impact: requireString(entry, "impact"),
       techs: (entry.data.techs as string[]) ?? [],
+      keywords: (entry.data.keywords as string[]) ?? [],
       category: (entry.data.category as string) ?? "systems",
       priority: (entry.data.priority as number) ?? 99,
       role: entry.data.role as string | undefined,

lib/seo.ts

@@ -19,14 +19,17 @@ export function pageMetadata({
   title,
   description,
   path,
+  keywords,
 }: {
   title: string;
   description: string;
   path: string;
+  keywords?: string[];
 }): Metadata {
   return {
     title,
     description,
+    keywords,
     alternates: { canonical: path },
     openGraph: {
       type: "website",
@@ -134,6 +137,7 @@ export function articleSchema(insight: InsightMeta) {
       url: site.url,
     },
     mainEntityOfPage: `${site.url}/insights/${insight.slug}`,
+    keywords: insight.tags.join(", "),
   };
 }
 
@@ -162,7 +166,7 @@ export function caseStudySchema(caseStudy: CaseStudy) {
       url: site.url,
     },
     mainEntityOfPage: `${site.url}/work/${caseStudy.slug}`,
-    keywords: caseStudy.techs.join(", "),
+    keywords: [...(caseStudy.keywords ?? []), ...caseStudy.techs].join(", "),
   };
 }
 

lib/types.ts

@@ -15,6 +15,8 @@ export interface CaseStudy {
   date: string;
   impact: string;
   techs: string[];
+  /** Search-intent phrases for this case study, e.g. "data warehouse". Feeds meta keywords and JSON-LD, distinct from techs. */
+  keywords?: string[];
   category: string;
   /** Lower number = higher prominence. 1 is the flagship. */
   priority: number;