Case Study: Replatforming a Social Media Marketing and SEO Training Company on AWS

Not every worthwhile project is a distributed system. This case study covers a deliberately small architecture done carefully: replatforming a social media marketing and SEO training company from WordPress onto AWS, with an AI content engine built in. It's a useful reference for any founder-led business whose website is the business — where SEO, page speed, and the ability to publish quickly matter more than horizontal scale.

The problem

The company ran on WordPress: dozens of plugins, slow pages, a theme nobody wanted to touch, and a publishing workflow that quietly discouraged publishing. For a business that teaches marketing and SEO, the site itself needs to be evidence of competence — fast, structurally sound, and updated often. The goals were concrete: modern site, real SEO fundamentals, payments, and a content pipeline where publishing a post requires neither a developer nor a deploy.

The architecture: one Go service, deliberately boring

We built the platform as a single Go monolith serving both a React single-page app and a set of server-rendered pages, packaged in one Docker image and run on Amazon ECS Fargate behind an Application Load Balancer. No Kubernetes, no microservices, no fleet of Lambdas — one service, one image, one deploy. For a small business, every additional moving part is a tax paid monthly in attention; the architecture should be as small as the problem allows, and no smaller.

The blog: server-rendered for SEO, database-backed for publishing speed

The most interesting decision is the blog. Single-page apps are a poor home for content that needs to rank, so the blog is server-rendered HTML emitted directly by the Go service — canonical URLs, Open Graph tags, and JSON-LD structured data on every post, with a sitemap and robots endpoint generated from live data. Posts live in DynamoDB (a single-table design with a status index for listing published posts), which means publishing a post is a database write, not a deployment. Draft and published states are enforced server-side: an unpublished draft returns a 404 to the public, always.

The legacy WordPress content — some seventy posts — was archived to Amazon S3 rather than migrated wholesale, keeping the new platform clean while preserving anything worth resurrecting.

The AI content engine

The platform includes an admin-facing AI engine built on Anthropic's Claude models via Amazon Bedrock. Two capabilities matter most:

• AI-drafted articles: an admin supplies a topic and target keyword; the system prompts the model for a structured SEO article with title, excerpt, meta description, and slug, then saves it as a draft. A human reviews and publishes as a separate, deliberate step. The AI accelerates the pipeline; it does not run it unattended.
• SEO asset generation: locked, task-specific prompts generate meta tags, JSON-LD schema, keyword research, content calendars, and outreach copy — the repetitive artifacts of SEO work, produced consistently instead of hand-rolled.

Alongside the site, a small scheduled AWS Lambda generates and publishes daily social content from a brand-voice prompt and a rotating topic pool — so the company's marketing presence keeps moving even during busy weeks. API keys for that pipeline live in AWS Secrets Manager and are fetched at runtime, never stored in code or environment files.

Payments and deployment discipline

Course and subscription payments run through Stripe — checkout, webhooks, and billing portal. Deployment is GitHub Actions with OpenID Connect federation into AWS: a push to main builds the image, pushes to Amazon ECR, and rolls the ECS service, with no long-lived AWS credentials stored in GitHub at all. Keyless CI/CD costs an afternoon to set up and permanently removes a whole class of credential-leak incidents; we consider it table stakes on every engagement.

The service is also fully instrumented with OpenTelemetry — traces, logs, and metrics — with personally identifiable information redacted at a single chokepoint in the logging pipeline rather than scattered across call sites. One enforcement point beats a hundred conventions.

Results

• Publishing requires no deploy — content goes live the moment it's published, from a phone if necessary.
• SEO fundamentals are structural, not bolted on: server-rendered pages, structured data, live sitemap — the site now practices what the company teaches.
• Predictable, low AWS spend — one Fargate service and a DynamoDB table, not a plugin ecosystem demanding weekly attention.
• An AI-assisted content pipeline with a human gate — drafts on demand, daily social posts on schedule, and a review step before anything public.

What this project generalizes to

The pattern here fits a large class of businesses: keep the architecture as small as the problem allows, render for the search engine rather than the framework, make publishing cheap, and put AI inside the workflow with a human deciding what ships. Cloud Development Group handles this shape of engagement end to end — architecture, build, AWS implementation, and the content and payments plumbing around it. If your website is your business and it's running on momentum rather than design, that's a conversation worth having.