Case Study: Building a Production-Grade Consulting Platform with Payload, Next.js, and AWS
The consulting practice's own site, built as the reference architecture for what the practice sells. Same Next.js + Payload + Postgres + ECS Fargate + Terraform stack as the anchor engagement. STS-only IAM, no long-lived credentials anywhere. Cost-tuned to run for a small fraction of the naive default AWS footprint, with full editorial workflow operated as code.
Key Results
Stack
Next.js + Payload + AWS ECS + AWS Lambda + RDS Postgres
Infrastructure as code
Full AWS footprint Terraform-managed in modules; CI-only apply
Where this engagement starts
The problem
A consulting practice that sells custom AWS commerce platforms cannot credibly sell them off a Webflow site. The site itself has to be the reference architecture: same stack, same security posture, same CI/CD model, same observability story, same operational discipline. The buyer needs to be able to inspect the codebase and find the same engineering choices the consultancy would make on their engagement.
The mandate: build a publicly-facing consulting site that doubles as a production-grade reference architecture, optimized for inbound search, cold outreach conversion, and credibility on AWS Partner Network and Payload CMS partnership applications. Same stack as the anchor engagement. Same security and cost discipline that mature buyers expect.
Engineering memo
Key decisions
What was decided, why, and what was deliberately not done.
Build the consulting site on the same stack the consultancy builds for clients.
Rationale
The site is the proof. Same Next.js 16 + Payload CMS + Postgres + ECS Fargate + Terraform + GitHub Actions stack used at the $5M+ ARR anchor engagement. Same OpenNext + Lambda + CloudFront topology. Same CI/CD posture. A buyer reviewing the site is reviewing a working sample of the architecture they would get.
Alternative considered
A WordPress marketing site would have been faster to ship and would have actively undermined the value proposition of this consultancy. The codebase quality is part of the marketing.
No use of long-lived AWS credentials. STS short-lived only, end to end.
Rationale
Production: ECS task role grants S3 PutObject to the media bucket; AWS SDK resolves credentials via AWS_CONTAINER_CREDENTIALS_RELATIVE_URI. CI/CD: GitHub OIDC trust to AWS; deployments assume an account-level IAM role with no static access keys involved. Local dev cannot write to production S3 because there are no creds to leak. There is no secret in the .env that grants production write access.
Alternative considered
Static IAM access and secret access key credentials provide implementation simplicity at the cost of significant security risks, which is not an acceptable tradeoff for a consultancy that builds secure cloud infrastructure for clients.
Treat infrastructure cost as a load-bearing engineering decision, not an afterthought.
Rationale
Initial infrastructure design was over-provisioned relative to the actual load profile of the site. In response, cost optimization measures were taken (RDS Proxy removed, NAT Gateway removed, RDS instance class downgraded, ECS task CPU and RAM reduced) until the infrastructure bill was reduced from $150 to ~$50 per month with no observable change in user-facing performance. Tradeoffs and rationale documented in the infrastructure modules for intentional future reversal.
Alternative considered
Leaving idle infrastructure on auto-pilot because the AWS bill was 'fine' is exactly the habit that does not fit this consultancy's positioning.
Outcomes
Outcomes (with sources)
Real metrics with attribution. Numbers without sources read as marketing. Every claim here is sourced.
Metric
Self-built reference architecture
Before
Consulting practice without a working sample of the architecture it sells.
After
Same stack as the anchor engagement: Next.js + Payload + ECS + RDS + Lambda + CloudFront + Terraform. Public repo, public commit history, public deploy logs. The codebase is the proposal.
Source: petertconti.com source repository
Metric
Infrastructure cost
Before
Original posture: RDS Proxy, NAT Gateway, larger RDS instance, larger ECS task. AWS bill scaled with the original config.
After
Dropped RDS Proxy. Dropped NAT Gateway. Downgraded RDS instance class. Reduced ECS task size. Net effect: a small fraction of the naive-default infrastructure cost, with no observable change in user-facing performance.
Source: Cost-optimization commit on the infra modules; documented tradeoffs.
Metric
Long-lived AWS credentials
Before
Static IAM user access keys injected into containers and CI as env vars.
After
Zero long-lived credentials anywhere. ECS task role for runtime, GitHub OIDC for CI/CD. Both STS-issued and short-lived.
Source: Commit ce9708e + infra/main.tf inline policy backend_media_access
Metric
Editorial workflow
Before
Click-through admin UI editing, no review trail, no cross-environment editorial workflow.
After
Content-as-code CLI: pull, diff, apply with paranoid defaults, array operations, schema-aware scaffolds, cross-target ID reconciliation across media (by filename), collections (by slug), and icons / forms (by title).
Source: backend/scripts/content/ + bootstrap-media-mirror.ts
The site is the proof
A consulting practice that builds enterprise-grade AWS platforms cannot credibly signal competence using a Wordpress site. The site is the architecture: same Next.js 16 + Payload CMS 3 + Postgres + ECS Fargate + Terraform + GitHub OIDC stack used at the $5M+/yr anchor engagement. Same OpenNext + Lambda + CloudFront topology. Same security posture. Same CI/CD.
What's actually under the hood
Frontend — Next.js 16 with App Router and React 19. Server components by default, client islands only where motion or interactivity demands them. Static prerendering with revalidate; ISR-style on-demand invalidation driven by Payload content hooks.
Backend — Payload CMS hosted as a Next.js 15 app inside an ECS Fargate task. Custom collections, globals, blocks, and access control wired through TypeScript-generated types that ship across the wire to the frontend. Postgres on RDS via @payloadcms/db-postgres.
Infrastructure — Terraform modules cover the full footprint: VPC + subnets, ACM, Route 53, RDS, S3 + CloudFront for media on its own subdomain, OpenNext-built Lambda for the frontend, the ECS service for the backend, the IAM and OIDC trust for CI. State lives in a separate AWS account; terraform apply runs only from CI.
STS-only IAM and the cost discipline
There are no long-lived AWS credentials anywhere in this system. CI deploys via GitHub OIDC into an account-level IAM role. Production writes to S3 happen because the ECS task role grants PutObject; the SDK resolves credentials from AWS_CONTAINER_CREDENTIALS_RELATIVE_URI. Local development cannot reach production S3 because there is no credential to leak. No .env key opens production. The secret simply does not exist.
Cost discipline came from the same posture: the initial infrastructure was over-provisioned for the actual load requirements. Cost-optimization measures were undertaken, including removing the unnecessary RDS proxy and NAT gateways, reducing RDS instance class sizing, and reducing ECS task resources. The net effect was a reduction in monthly costs from approximately $150 to ~$50 per month, a reduction of nearly 66%. Tradeoffs documented in the infra modules for later future review and potential reversal.
Peter T Conti Consulting Platform - AWS S3 Media Handling Demonstration
Cache freshness as a product feature
Static is the right default: all critical routes prerender at build time. The interesting work is not the prerender, it is the invalidation. Payload afterChange hooks fire a tag-based on-demand revalidation against a secret-protected route on the frontend. CloudFront sees a cache-busting header and serves the next request from origin. An editor publishing a service page in the admin UI sees the change live instantly without redeploying.
A single CloudFront Function on the frontend distribution handles both the apex-redirect and the OpenNext RSC cache-key computation in one viewer-request handler, as CloudFront only allows one viewer-request function per behavior, and overriding the OpenNext default would silently break client-side navigation.
Peter T Conti Consulting Platform CICD Pipeline Diagram
What this is, and what it isn't
This is a reference architecture appropriate for $5M–$50M businesses with custom commerce, regulated data, or modernization work that justifies senior end-to-end ownership. It is not appropriate for a five-page brochure that needs to ship next week, a Shopify theme, or any engagement where the right answer is a horizontal SaaS plus an agency.
Plain English: the site you are reading was designed, built, and is operated by one engineer using the same stack and posture built for clients. There is no team. There is no agency layer. The technical decisions on this page are the ones you would inherit if you hired the practice.
If your architecture decision aligns with anything on this page
Same stack as the anchor engagement, same posture, same person doing the work end to end. Thirty minutes is enough to know whether the practice is a fit.