Forem: Terry Leonard Hunt Jr

How to Fire Bad Clients (Without Setting Your Career on Fire)

Terry Leonard Hunt Jr — Wed, 10 Dec 2025 18:42:00 +0000

Why You Shouldn't Feel Guilty

Let's face it. Firing a client feels awkward. But if your client is ghosting invoices, ignoring your expertise, or blocking access to essential tools, it's time for a digital breakup. And guess what? That's totally okay.

Contracts are your superhero cape.
A solid agreement gives you an escape hatch and protects you when things go sideways. If you do not have one, stop reading and go write one.

Top Red Flags That Say "Run"

1. They Think You're a Keyboard, Not a Consultant

You offer expert advice. They ignore it. Then blame you when the site crashes. You are not here to rubber stamp bad ideas.

2. They Deny Access to Critical Tools

No admin rights, no server access, no FTP. Congratulations, you are now a magician working blindfolded. Hard pass.

3. They Keep Promising to Pay "Next Week"

Client: "Can I pay you next Friday?"
Reality: You will never see a dime.
Pro tip: Add late fees. Call it your emotional damage tax.

4. They Are Financially Reckless

If they owe thousands to Amazon, UPS, their cousin Larry, and that one Shopify plugin they forgot to cancel, you will be the last person they pay.

5. No Downpayment, No Deal

Never start a project without a deposit. It is not rude. It is smart business. If they refuse to invest upfront, they will not respect the work.

6. They Want the Final Product Before Paying

Do not upload anything to their live server until you have been paid in full. Use a dev server you control, or you risk getting ghosted with no money and no leverage.

7. They Micromanage Every Pixel

If you get 14 Slack messages about button spacing or are asked to "make the site feel more vibey," you are being creatively smothered. You are not their emotional support developer.

8. They Treat You Like a Butler

"Can you update my email signature?"
"Can you Photoshop my dog into the homepage banner?"
If your job description keeps expanding but your pay does not, it is time to dip.

How to Fire a Client Without Burning Bridges

1. Reference the Contract

Do not just say "I am out."
Say, "As stated in Section 8B of our agreement, I am terminating our engagement effective immediately." It sounds polished and professional.

2. Send a Calm, Direct Email

Example:

Hi [Client],

Due to [non-payment / access issues / general chaos], I'm formally ending our working relationship effective [date]. I will deliver all agreed-upon materials completed up to this point.

Best of luck moving forward.

3. Only Deliver What Was Paid For

If they paid for 40 percent of the work, send 40 percent. Not 100 percent. You are a professional, not a donation service.

4. Do Not Vent Publicly

Keep the rage tweets in your drafts folder. Screenshotting conversations may feel satisfying, but it can harm your reputation or lead to legal issues. Vent privately.

What to Do After You Fire a Client

1. Pour Yourself a Coffee (or Something Stronger)

You just dodged a stress tornado. Take a moment to breathe and remember you are not a punching bag with a GitHub account.

2. Review and Refine Your Process

Update your contract. Add stricter payment terms. Enforce that staging-only deployment rule you promised yourself last time. Every bad client teaches you something.

3. Refill Your Pipeline

Use your regained time to find clients who appreciate your work. Update your portfolio, reach out to past clients, or post a sharp case study on LinkedIn.

4. Celebrate Like a Freelancer Who Chooses Peace

Treat yourself to tacos or bubble tea. You did not just fire a bad client. You made space for better projects, higher pay, and a more peaceful inbox.

Final Thoughts

Saying no to a bad client is how you say yes to better ones. Do not be afraid to walk away from disrespect, scope creep, or unpaid labor. You are running a business, not playing freelance roulette.

Firing a client does not make you rude. It makes you a boss.

Secure Strapi Deployment on Amazon AWS

Terry Leonard Hunt Jr — Mon, 08 Dec 2025 14:27:39 +0000

☑️ Prerequisites

You have created a Strapi project to deploy on AWS
You have read the configuration documentation
You understand the basics of AWS IAM and core security best practices

☁️ Strapi Cloud

You can also use Strapi Cloud to deploy and host your project quickly.

Security First IAM Setup

1. Create IAM User with Minimal Permissions

Security Note: The official Strapi guide suggests broad permissions. The following approach applies hardened, minimal, service specific permissions.

Create Administrator User (One time setup)

Login as root
Create an Administrator role following the AWS IAM Admin User Guide https://docs.aws.amazon.com/IAM/latest/UserGuide/getting-started_create-admin-group.html

Create Strapi Developer User with Hardened Permissions

Instead of using *FullAccess policies, create custom policies with only the required capabilities.

EC2 Minimal Policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:DescribeInstances",
        "ec2:StartInstances",
        "ec2:StopInstances",
        "ec2:RebootInstances"
      ],
      "Resource": "*"
    }
  ]
}

RDS Minimal Policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "rds:DescribeDBInstances",
        "rds:DescribeDBClusters"
      ],
      "Resource": "*"
    }
  ]
}

S3 Secure Policy (replace with your bucket name):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "StrapiS3Access",
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:GetObject",
        "s3:ListBucket",
        "s3:DeleteObject",
        "s3:PutObjectAcl"
      ],
      "Resource": [
        "arn:aws:s3:::s3-bucket-name",
        "arn:aws:s3:::s3-bucket-name/*"
      ]
    }
  ]
}

Secrets Manager Policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "secretsmanager:GetSecretValue"
      ],
      "Resource": "arn:aws:secretsmanager:your-region:your-account-id:secret:your-secret-name*"
    }
  ]
}

SES Policy (if using emails):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ses:SendEmail",
        "ses:SendRawEmail"
      ],
      "Resource": "*"
    }
  ]
}

AWS VPC Setup

Follow Strapi's original VPC guide but ensure you:

Select the correct AWS region
Use two Availability Zones for redundancy
Configure two public subnets and two private subnets
Enable DNS hostnames and DNS resolution

EC2 Instance with IAM Role (Recommended)

1. Create IAM Role for EC2

Instead of access keys, assign an IAM role to your instance.

Go to IAM → Roles → Create Role
Select EC2
Attach the minimal policies created earlier
Name the role StrapiEC2Role

2. Launch EC2 Instance

Choose Ubuntu Server 22.04 LTS
Use t2.small or higher
Attach the role StrapiEC2Role
Configure security groups with minimal ports:
- SSH 22 restricted to your IP
- HTTP 80
- HTTPS 443
- Custom TCP 1337 only for testing

Security Warning: Remove port 1337 after configuring NGINX.

Secure RDS Database Setup

1. Create PostgreSQL Database

Security best practices:

Use the latest PostgreSQL engine
Select Production templates
Connect RDS to your VPC
Use private subnets
Enable encryption at rest
Enable automated backups
Enable Performance Insights

2. Database Security Best Practices

Use strong passwords longer than 20 characters
Encrypt data in transit
Restrict RDS access to only your EC2 security group
Apply routine updates

Secure S3 Configuration

Critical S3 Security Update

Avoid the public bucket policy in the original guide. It exposes all actions publicly.

1. Create Private S3 Bucket

Enable “Block all public access”
Enable versioning
Enable encryption

2. Secure Access Options

Option A: Private with Signed URLs (Recommended)
Uses temporary signed URLs for access.

Option B: Public Read Only (if required)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "PublicReadGetObject",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::your-bucket-name/*"
    }
  ]
}

This allows reading but not modifying files.

Secure Environment Variable Management

1. AWS Secrets Manager Setup

Store sensitive variables in Secrets Manager.

Create a secret:

aws secretsmanager create-secret \
  --name "strapi/production/env" \
  --description "Strapi production environment variables" \
  --secret-string file://secret.json \
  --region us-east-1

Example secret.json:

{
  "APP_KEYS": "your-app-keys",
  "API_TOKEN_SALT": "your-api-token-salt",
  "ADMIN_JWT_SECRET": "your-admin-jwt-secret",
  "JWT_SECRET": "your-jwt-secret",
  "DATABASE_HOST": "your-rds-endpoint.rds.amazonaws.com",
  "DATABASE_PORT": "5432",
  "DATABASE_NAME": "strapi",
  "DATABASE_USERNAME": "postgres",
  "DATABASE_PASSWORD": "your-secure-password",
  "AWS_REGION": "us-east-1",
  "AWS_BUCKET_NAME": "your-bucket-name"
}

2. Environment Fetch Scripts

Goal: never commit .env files to Git.

Option A: Bash Script

#!/bin/bash
# fetch-env.sh

SECRET_NAME="strapi/production/env"
REGION="us-east-1"
OUTPUT_FILE=".env"

echo "Fetching secrets..."

if ! command -v aws >/dev/null; then
  echo "AWS CLI missing"
  exit 1
fi

if ! command -v jq >/dev/null; then
  echo "jq missing"
  exit 1
fi

SECRET_JSON=$(aws secretsmanager get-secret-value \
  --secret-id "$SECRET_NAME" \
  --region "$REGION" \
  --query SecretString \
  --output text 2>/dev/null)

echo "$SECRET_JSON" | jq -r 'to_entries|map("\(.key)=\(.value)")|.[]' > "$OUTPUT_FILE"

Make executable:

chmod +x fetch-env.sh
./fetch-env.sh

Option B: Node.js Script

const fs = require('fs');
const { SecretsManagerClient, GetSecretValueCommand } = require('@aws-sdk/client-secrets-manager');

const client = new SecretsManagerClient({
  region: process.env.AWS_REGION || 'us-east-1'
});

async function fetchSecret(secretName, outputPath = '.env') {
  try {
    const command = new GetSecretValueCommand({ SecretId: secretName });
    const response = await client.send(command);
    const secret = JSON.parse(response.SecretString);

    const envData = Object.entries(secret)
      .map(([key, val]) => `${key}=${val}`)
      .join('\n');

    fs.writeFileSync(outputPath, envData);
  } catch (err) {
    console.error('Error fetching secret:', err.message);
    process.exit(1);
  }
}

const secretName = process.argv[2] || 'strapi/production/env';
fetchSecret(secretName);

Install dependencies:

npm install @aws-sdk/client-secrets-manager
node fetch-secrets.js

3. Secure PM2 Configuration

module.exports = {
  apps: [
    {
      name: 'strapi-secure',
      cwd: '/home/ubuntu/your-strapi-project',
      script: 'npm',
      args: 'start',
      env_file: '/home/ubuntu/your-strapi-project/.env'
    }
  ]
};

Node.js and Application Setup

1. Install Dependencies

sudo apt-get update
sudo apt-get install -y ca-certificates curl gnupg
sudo mkdir -p /etc/apt/keyrings
curl -fsSL https://deb.nodesource.com/gpgkey/nodesource-repo.gpg.key | sudo gpg --dearmor -o /etc/apt/keyrings/nodesource.gpg
NODE_MAJOR=20
echo "deb [signed-by=/etc/apt/keyrings/nodesource.gpg] https://deb.nodesource.com/node_$NODE_MAJOR.x nodistro main" | sudo tee /etc/apt/sources.list.d/nodesource.list
sudo apt-get update
sudo apt-get install -y nodejs

npm install -g @aws-sdk/client-secrets-manager

mkdir ~/.npm-global
npm config set prefix '~/.npm-global'
echo 'export PATH=~/.npm-global/bin:$PATH' >> ~/.profile
source ~/.profile

2. Deploy Strapi Securely

git clone https://github.com/your-org/your-strapi-repo.git
cd your-strapi-repo

npm install
node fetch-secrets.js
NODE_ENV=production npm run build

npm install pm2@latest -g
pm2 start ecosystem.config.js
pm2 save
pm2 startup

Production Security Checklist

Before Going Live

Remove port 1337 access
Configure NGINX reverse proxy with TLS
Enable CloudWatch logging
Enable automated RDS and S3 backups
Enable AWS WAF
Enable VPC Flow Logs
Configure AWS Config
Configure log aggregation and automated patches
Enable CloudTrail auditing

Ongoing Security

Update EC2 packages regularly
Rotate database passwords every quarter
Monitor CloudTrail logs
Review IAM permissions often
Update Strapi and dependencies
Test backups and recovery procedures

Complete Git Workflow

Commit to Git

fetch-env.sh
fetch-secrets.js
.env.example
.gitignore
deploy.sh
package.json
/src/
/config/
ecosystem.config.js

Never Commit to Git

.env
.env.local
.aws/
secret.json

Recommended .gitignore

.env
.env.*
!.env.example
secret.json
.aws/

Deployment Automation

1. deploy.sh

#!/bin/bash
set -e

SECRET_NAME="strapi/production/env"
REGION="us-east-1"
APP_DIR="/home/ubuntu/your-strapi-project"
PM2_CONFIG="/home/ubuntu/ecosystem.config.js"

cd "$APP_DIR"

git pull origin main
npm ci --production

if [ -f "fetch-env.sh" ]; then
  ./fetch-env.sh
else
  node fetch-secrets.js "$SECRET_NAME"
fi

NODE_ENV=production npm run build

pm2 restart "$PM2_CONFIG" || pm2 start "$PM2_CONFIG"
pm2 save

2. EC2 Deployment

git clone https://github.com/your-org/your-strapi-repo.git
cd your-strapi-repo

chmod +x fetch-env.sh deploy.sh
npm install
./deploy.sh

Subsequent Deployments

cd /home/ubuntu/your-strapi-project
./deploy.sh

3. Webhook Integration

const secret = 'your_webhook_secret';
const repo = '/home/ubuntu/your-strapi-project/';
const http = require('http');
const crypto = require('crypto');
const exec = require('child_process').exec;

http.createServer(function(req, res) {
  req.on('data', function(chunk) {
    let sig = 'sha1=' + crypto
      .createHmac('sha1', secret)
      .update(chunk.toString())
      .digest('hex');

    if (req.headers['x-hub-signature'] == sig) {
      exec(`cd ${repo} && ./deploy.sh`);
    }
  });
  res.end();
}).listen(8080);

Team Development Workflow

Setup for New Members

Initial Setup

git clone https://github.com/your-org/your-strapi-repo.git
cd your-strapi-repo
npm install
aws configure

Generate Environment File

./fetch-env.sh
node fetch-secrets.js strapi/development/env
node fetch-secrets.js strapi/staging/env

Start Development

npm run develop

Developer README Section

## Environment Setup

This project uses AWS Secrets Manager.

### Quick Start
1. Clone the repository
2. Run npm install
3. Run ./fetch-env.sh
4. Run npm run develop

Cost Optimization

AWS Secrets Manager Pricing

0.40 dollars per secret per month
0.05 dollars per 10,000 API calls
First 30 days free

Example cost:

Storage 0.40 dollars
API calls 0.005 dollars
Total about 0.41 dollars per month

Cost Saving Tips

Use EC2 IAM roles
Tag resources properly
Use RDS reserved instances
Enable S3 lifecycle policies
Monitor costs using Cost Explorer

Troubleshooting

1. IAM Permission Errors

Ensure IAM role is attached to EC2
Ensure policies contain required actions
Check resource ARNs

2. Secrets Manager Issues

Check secret name and region
Verify IAM permissions
Check AWS SDK credentials

3. S3 Upload Issues

Check bucket policy
Check CORS
Check IAM permissions

If you want, I can also format this for GitHub README, generate a table of contents, or optimize the Markdown for SEO on dev.to.

Deploy Your Own Strapi CMS to Railway (No Templates Needed)

Terry Leonard Hunt Jr — Fri, 05 Dec 2025 13:35:00 +0000

🚀 How to Set Up Strapi Locally and Deploy to Railway (The Easy Way)

Want to build and deploy your own Strapi CMS without touching Docker or overcomplicating things? Here is how you can go from local development to a live app on Railway with no one-click templates needed.

🆚 Quick Note: Strapi Cloud vs Railway

Strapi offers their own free tier cloud hosting:
👉 https://strapi.io/pricing-cloud

But many developers prefer Railway for full control over:

your Strapi app
your data
your file system
your deployments
your database choices

If that sounds like your style, try Railway here:
👉 https://railway.com?referralCode=ps81C1

1. 🧑‍💻 Set Up Strapi on Your Local Machine

Step 1: Install Strapi CLI

npm install -g create-strapi-app

Step 2: Create Your Project

npx create-strapi-app@latest my-strapi-project --quickstart

This spins up a new Strapi app and launches it at:
http://localhost:1337

💡 Tip: When prompted to create an admin user in the browser, go ahead and do that now.

Step 3: Test and Tweak

Add your content types, explore the admin panel, and make sure everything works as expected.

When finished, stop the server:

ctrl + c

2. 🧳 Prepare Your Project for Railway

Step 1: Add Environment Configs

Create a .env file in your project root:

DATABASE_CLIENT=sqlite
NODE_ENV=production
PORT=1337
APP_KEYS=someLongAppKey1,someLongAppKey2
API_TOKEN_SALT=randomStringHere
ADMIN_JWT_SECRET=randomSecretHere
JWT_SECRET=anotherSecretHere

🔐 Use https://randomkeygen.com to generate secure values.

Step 2: Update `package.json` Scripts

Ensure your scripts section includes:

"scripts": {
  "develop": "strapi develop",
  "start": "strapi start",
  "build": "strapi build",
  "strapi": "strapi"
}

Step 3: Push to GitHub

git init
git add .
git commit -m "Initial commit"
git branch -M main
git remote add origin https://github.com/your-username/your-repo.git
git push -u origin main

3. 🚢 Deploy to Railway

Step 1: Connect Your GitHub Repo

Go to Railway: https://railway.com?referralCode=ps81C1
Create a new project
Select Deploy from GitHub Repo
Choose your Strapi repository

Step 2: Set Environment Variables

Go to Railway’s Variables tab and add the same values you put in your .env file.

⚠️ Your app will not deploy correctly without these secrets.

Step 3: Trigger the Deployment

Railway detects it is a Node.js project and automatically runs:

npm run build
npm start

Once deployed, you will get a live URL in the Deployments tab 🎉

4. ✅ Final Touches

📦 Prefer PostgreSQL over SQLite? Add Railway’s PostgreSQL plugin and update your .env.
☁️ Want persistent media uploads? Use a Strapi upload provider such as S3 or Cloudinary: https://docs-v4.strapi.io/dev-docs/plugins/upload/
🔐 If exposing APIs, configure CORS plus roles and permissions.

🎯 That’s It

You have now built and deployed a Strapi CMS, fully customized and not locked into any presets.

Try Railway:
👉 https://railway.com?referralCode=ps81C1

Curious about Strapi Cloud? Explore it here:
👉 https://strapi.io/pricing-cloud

Why WordPress Isn't What It Used To Be (And It Sucks Now)

Terry Leonard Hunt Jr — Thu, 04 Dec 2025 20:04:18 +0000

A Nostalgic Beginning

Let's rewind to 2003. WordPress had just been born, a promising open-source CMS that felt like the future of the web. It was lean, clean, and anyone could fire up a blog in minutes. I remember trying it out and thinking, 'This is going to change everything.' And for a while, it did. WordPress became the go-to platform for bloggers, small businesses, and even enterprise websites.

Then came WooCommerce, and it was a big deal. Suddenly, you could run a full-blown online store without spending thousands on custom development. Life was simple. You had your theme, maybe a plugin or two, and your website was good to go. But fast forward to 2025, and WordPress has morphed into a bloated, plugin-infested monster that's more of a maintenance nightmare than a CMS.

The Plugin Overdose Epidemic

Here's the thing with WordPress plugins—they're like Pringles. Once you pop, you can't stop. Need a contact form? Plugin. SEO optimization? Plugin. Want breadcrumbs? Yup, another plugin. Before you know it, your WordPress site is carrying the weight of 30+ plugins, each adding its own load of scripts, CSS, and backend bloat.

But wait, it gets worse. These plugins often don't play nice with each other. Install Plugin A, and suddenly Plugin B decides to throw a tantrum, breaking your site in ways that would make even the most seasoned developer question life choices. Plugin conflicts are the norm, not the exception.

And let's not forget updates. Every other day, you're greeted with a cheerful notification that half your plugins need updating. Better pray none of those updates introduce new bugs, break compatibility, or worse—open up new security vulnerabilities.

Elementor: The Necessary Evil We All Love to Hate

Now, let's talk about the elephant—or should I say, Elementor—in the room. On paper, Elementor sounds fantastic: a drag-and-drop page builder that lets you design beautiful pages without touching code. In practice, it's a performance black hole.

You get your fancy sliders, animations, and pixel-perfect layouts, but you also get bloated HTML, inlined CSS spaghetti, and JavaScript files that seem to multiply like rabbits. By the time an Elementor-heavy page finishes rendering, you could've hand-coded it in pure HTML and CSS and still had time to grab a coffee.

Don't get me wrong, drag-and-drop builders have their place, but Elementor has become a crutch that's slowing down thousands of websites globally. Google PageSpeed Insights weeps every time an Elementor page is loaded.

Security? What Security?

One of the biggest WordPress downfalls is security—or the lack thereof. The sheer popularity of WordPress makes it a prime target for hackers, bots, and anyone looking to exploit vulnerable websites. And let's face it, the WordPress ecosystem is a ticking time bomb when it comes to security.

The 'one-click WordPress install' via cPanel is a convenience that hides the ugly truth. Most people setting up WordPress don't:

Change default admin URLs

Implement Web Application Firewalls (WAF)
Disable XML-RPC
Regularly audit plugins and themes for vulnerabilities
They just install WordPress, slap on a theme, add a few plugins, and call it a day. This negligence creates a paradise for attackers. Outdated plugins, poorly-coded themes, and weak server configurations are all open doors waiting to be exploited.

The Worst Offense: Customer Passwords

Now, let's address the unforgivable sin: customer passwords.

Believe it or not, there are still WordPress setups storing plain text passwords in databases. Even when passwords are hashed, improper configurations, lazy developers, or shady plugins can compromise user credentials. A leaked password file from a WooCommerce store is a disaster waiting to happen.

The problem is compounded by the fact that many WordPress users aren't developers. They rely on 'set-it-and-forget-it' solutions that work until they don't. And when they don't, it's often too late. No backups. No security audits. Just a panicked site owner googling 'how to recover a hacked WordPress site.'

Performance Bottlenecks Everywhere

Do you enjoy fast-loading websites? WordPress will cure you of that.

The average WordPress site today is an intricate maze of theme options, plugin settings, shortcodes, and custom widgets. Each of these adds processing overhead. Database queries pile up, rendering times increase, and before you know it, your site takes 5 seconds to load. That's an eternity in the digital world where every extra second of load time costs you conversions.

And don't think throwing caching plugins and CDN layers on top will magically fix everything. Those are band-aids, not solutions. At the core, WordPress is still trying to juggle a million moving parts that weren't meant to scale together.

Headless CMS: A Breath of Fresh Air

If you're tired of playing plugin roulette and dealing with bloated page builders, it might be time to look at a headless CMS. Platforms like Strapi, Contentful, or Sanity let you manage your content through a clean, API-first approach. No more plugin conflicts. No more page builder bloat.

With a headless CMS, you get the freedom to build your frontend using modern frameworks like Next.js or Nuxt, giving you total control over performance and security. Sure, the learning curve is steeper, but the long-term gains in speed, flexibility, and security are worth it.

The Bottom Line

WordPress had a good run. It was the king of CMS for years, but in 2025, it feels like a relic from a different era. The constant plugin bloat, security nightmares, performance issues, and reliance on builders like Elementor make it an increasingly bad choice for serious projects.

If you're setting up a hobby blog or a simple portfolio, WordPress can still be an option. But if you're building a scalable business, eCommerce site, or a content-driven platform, it's time to move on. Modern alternatives offer cleaner architectures, better security, and superior performance.

So unless you enjoy spending your weekends debugging plugin conflicts, waiting for Elementor pages to load, and fighting off bot attacks, maybe it's time to break up with WordPress.

It's not you, WordPress. It's… well, actually, it is you.