DEV Community: Savage Solutions

A Hanging Dedup Fetch Killed Our Daily Blog for a Week

Savage Solutions — Wed, 02 Sep 2026 10:01:38 +0000

The Week Our Blog Went Silent

For seven days, our automated blog pipeline produced nothing. No posts, no errors in Slack, no pages. The cron job showed as running. The logs showed it starting. And then: nothing. The process just sat there, alive but useless, until the next scheduled run kicked off another zombie alongside it.

This is the story of how a single hanging HTTP fetch inside a Promise.all took down our entire content automation system, why no alert fired, and exactly what we changed to make sure it never happens again.

What the Pipeline Actually Does

Our blog automation is a TypeScript service running on a containerized Next.js backend. Each day, a cron triggers a content generation job that runs three gate checks before writing anything to MongoDB:

Cannibalization check, queries existing posts to make sure the new topic doesn't overlap with something we already rank for
Semantic dedup check, hits an external embedding API to compare the candidate post against recent content
Base keyword check, validates the target keyword against our keyword strategy rules

All three ran concurrently inside a single Promise.all:

const [cannibalizationResult, dedupResult, baseKeyResult] = await Promise.all([
  checkCannibalization(topic),
  checkSemanticDedup(topic),
  checkBaseKeyword(topic),
]);

This is clean, fast, and completely correct under normal conditions. The problem was what happened when conditions were not normal.

The Actual Failure: EAI_AGAIN on Flaky Container DNS

Our container environment started throwing intermittent EAI_AGAIN errors on DNS resolution. EAI_AGAIN is a temporary DNS failure, the resolver saying "try again later." Node's fetch (and most HTTP clients) will retry internally on these, but if the DNS never resolves, the fetch just hangs. No rejection, no timeout, no error. It waits.

The semantic dedup check calls an external embedding API. That fetch hung indefinitely on a DNS failure. Because it was inside Promise.all with no per-fetch timeout, the entire Promise.all also hung. The outer async handler never returned. The cron job never reached its COMPLETE state.

Here is the part that made it invisible: our alerting was wired to the cron's success grep. The monitoring script looked for a "status": "complete" string in the job's output. If the job never returned, that string never appeared. But the monitor didn't treat "no output" as a failure. It treated it as "still running." So no page fired.

Seven days. Fourteen missed blog posts. Zero alerts.

The Fix: Promise.race With a Named Timeout

The fix has two parts. First, wrap every gate check in a Promise.race against a named timeout. Second, make sure the outer handler returns a non-success JSON response when any check fails or times out, so the cron's success-grep has something to catch.

Here is the timeout wrapper we added:

function withTimeout<T>(promise: Promise<T>, ms: number, label: string): Promise<T> {
  const timeout = new Promise<never>((_, reject) =>
    setTimeout(() => reject(new Error(`${label} timed out after ${ms}ms`)), ms)
  );
  return Promise.race([promise, timeout]);
}

And here is how the gate checks now run:

try {
  const [cannibalizationResult, dedupResult, baseKeyResult] = await Promise.all([
    withTimeout(checkCannibalization(topic), 30000, 'cannibalization_check_timeout'),
    withTimeout(checkSemanticDedup(topic), 30000, 'dedup_check_timeout'),
    withTimeout(checkBaseKeyword(topic), 30000, 'base_key_check_timeout'),
  ]);

  // proceed with generation
} catch (err) {
  logger.error({ err, topic }, 'Gate check failed or timed out');
  return res.status(200).json({ status: 'error', reason: err.message });
}

A few things worth noting about this implementation:

The timeout is 30 seconds per check, named dedup_check_timeout in logs so we can grep for it specifically in Datadog.
We return status: 200 with an error body rather than a 5xx, because our cron runner treats non-200 as a network failure and retries silently. The success-grep now looks for "status": "complete" and pages on anything else.
We fail closed. If the dedup check times out, we do not generate the post. A missed post is recoverable. A duplicate or cannibalizing post is not.

Why Fail-Closed Is the Right Call Here

Some teams would argue for fail-open: if the dedup check is unavailable, skip it and generate anyway. That logic makes sense for non-critical gates. For content quality gates, it does not.

The cannibalization check exists because publishing a post that competes with an existing ranking page actively hurts SEO. The semantic dedup check exists because publishing near-duplicate content is a quality signal Google penalizes. Skipping either check because of a transient DNS failure trades a short-term miss for a long-term ranking problem.

Fail-closed means we miss a day of content. Fail-open means we potentially publish something that damages the site. The math is straightforward.

The key rule we wrote into our runbook: a silent hang is never acceptable, even if the failure mode is conservative. The system must always return, and it must always return something the monitoring layer can evaluate.

What We Added to Monitoring

Beyond the code change, we made three monitoring updates:

Explicit timeout log lines: every dedup_check_timeout or cannibalization_check_timeout error writes a structured log entry that triggers a Datadog monitor.
Cron heartbeat check: the job now writes a {"status": "heartbeat"} line every 60 seconds while running. If the monitor sees no heartbeat and no completion within 5 minutes, it pages.
Dead-letter queue for skipped posts: when a gate check fails, the topic goes into a MongoDB collection called pending_retry so the next day's run picks it up automatically.

The retry collection is what actually recovered the seven missed posts. Once the DNS issue was resolved and the fix was deployed, the next cron run processed the backlog automatically.

The Broader Pattern

This failure is not specific to blog automation. Any Promise.all that calls external services without per-promise timeouts is vulnerable to this exact hang. The pattern shows up in:

Parallel API enrichment pipelines
Multi-source data aggregation jobs
Webhook processors that fan out to third-party services

The fix is always the same: Promise.race with a named timeout, structured error logging, and a monitoring layer that treats "no response" as a failure, not as "still running."

At Savage Digital Solutions, this incident became the basis for a standard we now apply to every async pipeline we build: no Promise.all over external calls without an explicit per-promise timeout and a fail-closed error path.

Key Takeaways

A single hanging fetch inside Promise.all with no timeout will hang the entire Promise.all indefinitely.
EAI_AGAIN DNS errors in containerized environments do not reject promises. They hang them.
Wrap every external call in Promise.race with a named timeout (we use 30 seconds, named per-check for log grep).
Fail closed on content quality gates. A missed post is recoverable; a cannibalizing post is not.
Your monitoring must treat "no response" as a failure. Success-grep on a process that never returns will never fire.
Write a structured log line on every timeout so your observability layer has something to alert on.
Use a pending_retry collection or equivalent dead-letter queue so skipped jobs are not permanently lost.

We Were IndexNow-Pinging GitHub PRs Instead of Blog URLs (Here's How We Fixed It)

Savage Solutions — Wed, 26 Aug 2026 10:01:38 +0000

The Bug Nobody Notices Until Bing Returns a 403

We build and maintain content pipelines for clients at Savage Digital Solutions, and last month we shipped a migration for Candid Studios that moved their blog authoring workflow into gitMdx. The idea was clean: writers commit MDX files, a GitHub Action merges the PR, Next.js rebuilds the static pages, and IndexNow fires off a ping to Bing and other search engines so the new post gets crawled within minutes instead of days.

It did not work. Not even close.

What gitMdx's `publishResult.url` Actually Returns

Here is the part that burned us. After a successful publish call in gitMdx, the SDK returns a publishResult object. We assumed publishResult.url would be the live blog URL. It is not. It is the GitHub Pull Request URL.

So our IndexNow submission code was doing this:

const publishResult = await gitMdx.publish(post);
const submissionUrl = `${process.env.SITE_URL}${publishResult.url}`;
// submissionUrl = "https://candidstudios.nethttps://github.com/org/repo/pull/47"

That concatenation produces https://candidstudios.nethttps://github.com/org/repo/pull/47. Bing's IndexNow endpoint accepted the POST without complaint, because the API does basic schema validation, not URL reachability validation at submission time. The crawler then tried to fetch that nonsense string, failed silently, and the posts never got indexed.

We only caught it when a Candid Studios post that should have surfaced in Bing within the hour was still invisible three days later.

The Second Problem: The Key File Was Never Hosted

IndexNow requires you to prove ownership of the domain by hosting a plain text file at /{your-key}.txt on the same domain you are submitting URLs for. The filename is literally your API key.

Our deployment script created the key file locally and committed it to the repo, but the Next.js public/ directory for Candid Studios was not being deployed to the root of candidstudios.net. The file existed in the build artifact but was never reachable at https://candidstudios.net/{INDEXNOW_KEY}.txt.

Bing returned a 403 on the first attempt and a 404 on subsequent ones depending on CDN cache state. Both mean the same thing operationally: Bing cannot verify you own the domain, so it discards the submission.

The IndexNow spec is explicit about this. From the documentation:

"The key file must be accessible at https://{host}/{key}.txt and must return a 200 status code."

We had skipped that verification step entirely.

The Fix, Step by Step

Here is exactly what we changed.

1. Stop using publishResult.url for IndexNow submissions.

Build the submission URL from the post slug directly:

const slug = post.slug; // e.g. "how-to-choose-a-brand-photographer"
const submissionUrl = `${process.env.SITE_URL}/blog/${slug}`;
// submissionUrl = "https://candidstudios.net/blog/how-to-choose-a-brand-photographer"

This is the URL that actually exists on the public web. publishResult.url is useful for linking to the PR in a Slack notification or a CMS audit log. It is not a public URL.

2. POST host and urlList as separate fields.

The IndexNow POST body requires both fields. We had been sending only urlList. The corrected request:

const response = await fetch('https://api.indexnow.org/indexnow', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json; charset=utf-8' },
  body: JSON.stringify({
    host: 'candidstudios.net',
    key: process.env.INDEXNOW_KEY,
    keyLocation: `https://candidstudios.net/${process.env.INDEXNOW_KEY}.txt`,
    urlList: [submissionUrl],
  }),
});

Sending host separately from the URLs in urlList is required by the spec. Without it, some engines reject the batch silently.

3. Host the key file at the correct path on every money site.

For a Next.js project, drop the key file into the public/ directory:

public/
  {INDEXNOW_KEY}.txt

The file content is just the key string on a single line. After deployment, verify it manually before running any submissions:

curl -I https://candidstudios.net/{INDEXNOW_KEY}.txt
# Expect: HTTP/2 200

If you get anything other than 200, your submissions are being discarded. Fix the hosting first.

We also had a second client site in the same pipeline. The key file was missing there too. Both sites needed the file deployed before IndexNow would work for either of them.

Why This Is Easy to Miss

The IndexNow API returns a 200 OK even when the key file is unreachable at submission time. Bing validates the key asynchronously when it attempts to crawl the submitted URLs. So your POST succeeds, your logs look clean, and you have no idea the submissions are being silently dropped until you notice the pages are not appearing in search results.

The publishResult.url issue is similarly invisible. The URL string looks plausible in a log line if you are not reading carefully. https://candidstudios.nethttps://github.com/... is obviously wrong when you stare at it, but in a JSON log payload scrolling past in a terminal, it reads as a long URL and your eye moves on.

Both bugs required us to go back to first principles: what does this variable actually contain, and is the thing we are submitting publicly reachable right now?

The Rule That Prevents This

Discovery only works if the URL is public and the key is public. That is the entire contract. Before any IndexNow integration ships, run two checks:

curl -I https://{yourdomain}/{INDEXNOW_KEY}.txt returns 200
The URL in urlList returns 200 when fetched from outside your network

If either check fails, the submission does nothing.

We now run both checks as part of the deployment verification step in our GitHub Actions workflow, before the IndexNow POST fires. A failed curl exits the action with a non-zero code and pages the on-call engineer instead of silently wasting the submission.

The team at Savage Digital Solutions (savagesolutions.io) has since applied this same verification pattern to every client site running an automated IndexNow pipeline.

Key Takeaways

publishResult.url in gitMdx returns a GitHub PR URL, not the live page URL. Build your IndexNow submission URL from the post slug: {website}/blog/{slug}.
String-concatenating SITE_URL with a GitHub URL produces a malformed string that Bing will attempt and fail to crawl.
The IndexNow POST body requires both host and urlList as separate fields. Omitting host causes silent failures on some engines.
The key file must be hosted at /{key}.txt on every domain you submit URLs for, and it must return HTTP 200. Bing validates this asynchronously, so a successful POST does not confirm the key is reachable.
IndexNow returns 200 OK at submission time even when the key file is missing. You will not see the failure in your POST logs.
Run curl -I https://{domain}/{key}.txt as a deployment gate before any IndexNow submission fires.
If the URL is not publicly reachable and the key file is not publicly reachable, the submission is discarded.

One Enum Mismatch Hid Every Blog Video for Weeks

Savage Solutions — Wed, 19 Aug 2026 10:01:41 +0000

The Bug That Looked Like a Design Decision

For weeks, dozens of blog posts on a HeyGen-powered video platform showed a blank space where the video player should have been. No error. No broken image icon. Just nothing. The CDN MP4 existed. The HeyGen render had completed. The database had a valid URL. And yet: blank page.

This is the story of how a single mismatched status string caused every video to silently disappear, and exactly how we fixed it.

What HeyGen Sends vs. What We Expected

HeyGen's webhook payload includes a status field. When a video finishes rendering, that field arrives as 'completed'.

Our Next.js frontend was written to render the video player only when status === 'ready'.

Those two strings never matched. Not once.

Every time HeyGen fired a webhook, our handler wrote videoStatus: 'completed' into MongoDB. The Next.js page checked for 'ready', found something else, and rendered nothing. The player component never mounted. No console error, because the code path was technically correct. It just never reached the render branch.

The result: dozens of posts with a valid files2.heygen.ai MP4 URL sitting in the database and a blank <div> where the player should have been.

Mapping the Broken State Machine

The first step was writing down the actual states the system was moving through versus the states we intended.

Intended finite state machine:

none → pending → ready | failed

Actual states in MongoDB after weeks of webhook writes:

none → pending → completed

'ready' never appeared in the database. Not in a single document. The finalize function, the retry handler, and the webhook writer were all using different strings with no shared enum.

The Fix: One Source of Truth for Status

We defined a TypeScript enum that every writer had to import:

export enum VideoStatus {
  None = 'none',
  Pending = 'pending',
  Ready = 'ready',
  Failed = 'failed',
}

Then we updated three places that were writing status to MongoDB:

1. The HeyGen webhook handler

// Before
await db.collection('posts').updateOne(
  { heygenJobId: payload.video_id },
  { $set: { videoStatus: payload.status } } // wrote 'completed'
);

// After
const statusMap: Record<string, VideoStatus> = {
  completed: VideoStatus.Ready,
  failed: VideoStatus.Failed,
};

const normalized = statusMap[payload.status] ?? VideoStatus.Pending;

await db.collection('posts').updateOne(
  { heygenJobId: payload.video_id },
  { $set: { videoStatus: normalized } }
);

2. The finalize function (called after manual review) was updated to write VideoStatus.Ready instead of the string 'ready' it had been writing inconsistently.

3. The retry handler was writing 'pending' as a raw string. Updated to VideoStatus.Pending.

Bulk-Updating the Existing Documents

Fixing the writers only helped future webhooks. The existing documents in MongoDB still had videoStatus: 'completed' on dozens of posts. We ran a targeted update:

db.collection('posts').updateMany(
  { videoStatus: 'completed' },
  { $set: { videoStatus: 'ready' } }
);

After that query ran, every post with a valid CDN URL immediately became visible. The Next.js pages re-rendered on the next request and the players mounted correctly. No redeployment needed. No content changes. Just the status string corrected in the database.

Preventing Dead Players from Expired URLs

While we were in the webhook handler, we found a second problem. HeyGen's files2.heygen.ai URLs expire. If a post sat in 'completed' limbo long enough, the URL in the database was no longer valid. Rendering the player with a dead URL would show a broken player, which is worse than showing nothing because it signals to the reader that something went wrong.

We added a URL validation step before the player component mounts:

async function isVideoUrlAlive(url: string): Promise<boolean> {
  try {
    const res = await fetch(url, { method: 'HEAD' });
    return res.ok;
  } catch {
    return false;
  }
}

If the check returns false, the component renders a static thumbnail with a "Video processing" label instead of a broken player. The post still reads correctly. The reader is not confused.

This also means the system now rejects expired files2.heygen.ai URLs at render time rather than silently displaying a broken embed.

Why This Stayed Hidden So Long

A few things made this bug hard to catch:

No error was thrown. The conditional if (status === 'ready') evaluated to false and the component returned null. Perfectly valid React.
The database looked healthy. Documents had a videoStatus field with a value. Nothing was null or missing.
HeyGen's dashboard showed successful renders. The videos existed. The problem was entirely in how we stored and read the status.
The blank space looked intentional. Without a prior working state to compare against, it was easy to assume the player was just not yet wired up.

The only way we caught it was by querying MongoDB directly and noticing that 'ready' appeared zero times while 'completed' appeared dozens of times.

The Broader Pattern

This class of bug appears whenever two systems use the same concept with different vocabulary and there is no translation layer between them. HeyGen owns its status strings. We own ours. The webhook handler is the boundary, and it should have been doing the translation from day one.

The fix is not complicated: define your internal states explicitly, map external values to them at the entry point, and never let a third-party string propagate into your own database. A TypeScript enum enforced at compile time would have caught this before it shipped.

This is the kind of integration work the team at Savage Digital Solutions (savagesolutions.io) runs into regularly when connecting AI video tools to production content pipelines. The tools are capable. The gaps are almost always in the plumbing between them.

Key Takeaways

HeyGen webhooks write status: 'completed'. If your app expects 'ready', every video silently disappears.
Define a TypeScript enum for your internal video states (none, pending, ready, failed) and import it everywhere status is written to MongoDB.
The webhook handler is the translation layer. Map third-party status strings to your internal enum at that boundary, not downstream.
After fixing the writers, run a updateMany to correct existing documents. Future webhooks will not fix historical data.
files2.heygen.ai URLs expire. Validate the URL with a HEAD request before mounting the player. Render a fallback rather than a broken embed.
A blank page with no error is often a conditional that evaluates to false, not a missing component. Query the database directly when the UI gives you nothing to debug.

Never Ship a Blog Post Without a Featured Image Again

Savage Solutions — Wed, 12 Aug 2026 10:01:50 +0000

The Bug Nobody Noticed for Weeks

Our blog listing page was silently broken for weeks. Cards rendered with blank image slots, gray rectangles where featured images should have been. No error, no alert, no automated test caught it. A human finally looked at /blog and flagged it.

The root cause was embarrassingly simple: our publishing pipeline allowed posts to go live without a featured image, with the assumption that someone would backfill the image later through an async queue. That assumption was wrong. Posts shipped to production, listing cards went blank, and the queue sat unprocessed.

This is the story of how we fixed it with a hard publish gate, and why the fix is permanent.

How the Pipeline Worked Before

We run a content pipeline that publishes through two paths: Payload CMS and a gitMdx flow for markdown-based posts. Both paths fed into the same listing page, and both had the same gap: neither required a featured image URL before allowing a post to move from draft to published.

The async image queue was designed as a convenience. If a post was ready to go but the image was still being generated (we use HeyGen for some video thumbnails and other tooling for static images), the post could publish and the image would follow. In practice, the image rarely followed on time. The queue backed up, editors forgot, and the listing page accumulated blank cards.

We also had a secondary problem: internal tooling and some post metadata were using the short form Savage Digital Solutions instead of the full name Savage Digital Solutions. That inconsistency was slipping into published content.

The Fix: `evaluatePublishGate`

We wrote a single gate function called evaluatePublishGate that runs before either publish path can execute. The rule is binary: if the post does not have a valid https featured image URL, it does not ship. It stays in draft.

Here is the core logic:

function evaluatePublishGate(post: PostPayload): GateResult {
  const { featuredImage, status, brandMentions } = post;

  if (!featuredImage || !featuredImage.startsWith('https://')) {
    return {
      approved: false,
      reason: 'Missing or invalid featured image URL. Post forced to draft.',
    };
  }

  const forbiddenBrandForm = /\bSavage Solutions\b/i;
  if (brandMentions?.some((m) => forbiddenBrandForm.test(m))) {
    return {
      approved: false,
      reason: 'Short brand form detected. Use full name: Savage Digital Solutions.',
    };
  }

  return { approved: true };
}

This runs synchronously before the Payload publish hook and before the gitMdx pipeline writes to the production branch. If approved is false, the post status is set to draft and the publish is aborted. No exceptions, no overrides.

The brand name check was added at the same time. The gate now rejects any post where the string Savage Digital Solutions appears without the full Savage Digital Solutions form. This catches copy-paste errors and shorthand that crept in from internal tooling.

What Changed in the Payload Hook

In Payload CMS, collection hooks run at specific lifecycle points. We attached evaluatePublishGate to the beforeChange hook on the Posts collection:

beforeChange: [
  ({ data, operation }) => {
    if (operation === 'update' && data.status === 'published') {
      const result = evaluatePublishGate(data);
      if (!result.approved) {
        data.status = 'draft';
        console.warn(`[PublishGate] Blocked: ${result.reason}`);
      }
    }
    return data;
  },
],

The hook intercepts any attempt to set status: 'published', runs the gate, and silently downgrades to draft if the gate fails. The console.warn feeds into our logging pipeline so we can track how often posts are blocked and why.

For the gitMdx path, we added the same check as a pre-commit validation step. The script reads the frontmatter of any markdown file staged for the production branch and calls evaluatePublishGate before allowing the commit to proceed.

The Async Queue Still Exists, But It Cannot Bypass the Gate

We did not remove the async image queue. It still exists for repair work: if a published post needs its image updated or replaced, the queue handles that. But the queue no longer serves as a workaround for missing images on new posts.

The distinction matters. Repair and creation are different operations. A post that already has a valid featured image can have that image updated asynchronously without breaking the listing card. A post that has no image at all will render a blank card the moment it goes live. The gate only blocks the second case.

This also means the queue backlog is now smaller and more predictable. It handles genuine updates, not a pile of posts waiting for images that should have been required upfront.

The Rule We Wrote Down

After shipping the fix, we wrote one sentence in our internal docs:

If the card would look broken on /blog, it does not ship.

That sentence covers the featured image requirement, the brand name check, and any future gate conditions we add. It is a product standard, not a technical constraint. The technical constraint (the gate function) exists to enforce the product standard.

This framing helped when we discussed adding more gate conditions later. Every proposed condition gets evaluated against the same question: would a missing or malformed version of this field cause a visible defect on the listing page or in a post? If yes, it belongs in the gate.

What We Would Do Differently

The async backfill pattern was a mistake from the start. It optimized for publishing speed at the cost of listing page integrity. The right default is always to require complete data before publishing, not to publish incomplete data and fix it later.

If you are running a Next.js blog with Payload or any headless CMS, the place to enforce this is in the CMS hook layer, not in the frontend. The frontend should be able to assume that any published post has a valid featured image. Defensive rendering in the listing component (fallback images, skeleton states) is fine for edge cases, but it should not be the primary defense against missing data.

The team at Savage Digital Solutions (savagesolutions.io) now treats evaluatePublishGate as a template for other content quality checks. The pattern is reusable: define the condition that would cause a visible defect, write a synchronous check, attach it to the publish lifecycle, and force draft on failure.

Key Takeaways

A missing featured image causes blank listing cards in production. This is a silent failure with no automatic alerts unless you have explicit gate logic.
evaluatePublishGate runs synchronously before both Payload CMS publish hooks and gitMdx pipeline commits. It requires a valid https featured image URL or forces the post to draft.
The same gate enforces full brand name usage. The short form Savage Digital Solutions is blocked at the gate level, not caught in post-publish review.
Async image queues are valid for repair operations on already-published posts. They are not a substitute for requiring complete data before initial publish.
Attach quality gates to the CMS beforeChange hook, not to frontend rendering logic. The frontend should receive clean data, not compensate for missing data.
One sentence captures the standard: if the card would look broken on /blog, it does not ship.

How We Killed Alert Fatigue Without Going Blind

Savage Solutions — Wed, 12 Aug 2026 02:20:46 +0000

The Problem Was Noise, Not Negligence

We had dozens of cron jobs. Each one was configured to email on every run, success or failure. On a quiet night that meant a wall of green. On a bad night it meant that same wall of green, except somewhere buried in it was a red that nobody caught until a client noticed.

That is not a discipline problem. That is a systems design problem. Alert fatigue is a reliability bug, not a personality flaw, and treating it like the former means you keep blaming people instead of fixing the architecture.

Here is exactly what we changed.

The Old Setup and Why It Failed

Every cron job had its own mail() call or nodemailer transport wired directly to an ops inbox. A job that ran three times a day sent three emails. Multiply that by a few dozen jobs and you get hundreds of messages per day, most of them saying nothing actionable.

The inbox became a place people skimmed and archived. When a real failure arrived, it looked identical to the routine noise. The signal-to-noise ratio was so bad that the inbox itself became untrustworthy.

The fix required two things: a single spool that owns all outbound alerts, and a routing layer that decides what gets delivered, when, and at what priority.

The Spool Architecture

We built a central alert spool as a MongoDB collection. Every cron job, background worker, and scheduled task writes to it instead of sending email directly. A record looks like this:

interface AlertRecord {
  _id: ObjectId;
  source: string;        // e.g. 'invoice-sync-cron'
  level: 'info' | 'warn' | 'critical';
  message: string;
  createdAt: Date;
  dispatched: boolean;
  dispatchedAt?: Date;
}

Nothing sends email on its own anymore. The spool owns that responsibility.

The Routing Layer: Batch vs. Immediate

A separate dispatcher process runs on a schedule and applies two rules:

Rule 1: Criticals go immediately. Any record with level: 'critical' triggers an immediate send to the ops channel. No batching, no delay.

Rule 2: Everything else batches at 3x/day. Info and warn records accumulate and go out as a single digest at fixed times. One email in the morning, one midday, one at end of day. The digest groups records by source so the reader can scan by job name rather than by timestamp.

async function dispatchBatch() {
  const pending = await AlertRecord.find({
    dispatched: false,
    level: { $in: ['info', 'warn'] },
  }).sort({ createdAt: 1 });

  if (pending.length === 0) return;

  const grouped = groupBy(pending, (r) => r.source);
  const body = formatDigest(grouped);

  await sendEmail({ to: OPS_EMAIL, subject: `Alert Digest (${pending.length} items)`, body });

  const ids = pending.map((r) => r._id);
  await AlertRecord.updateMany({ _id: { $in: ids } }, { dispatched: true, dispatchedAt: new Date() });
}

The dispatcher runs via its own cron at 07:00, 12:00, and 17:00. Criticals run through a separate process that polls every 60 seconds.

The Kill and Demote Lists

Batching alone was not enough. Some jobs produce lines that are technically non-zero exit codes but are completely expected. A sync job that reports "0 new records found" should not even appear in the digest.

We added two regex lists that run at write time, before a record ever enters the spool:

const KILL_PATTERNS: RegExp[] = [
  /0 new records found/i,
  /heartbeat ok/i,
  /cache warmed successfully/i,
];

const DEMOTE_PATTERNS: RegExp[] = [
  /rate limit warning/i,
  /retry attempt \d of 3/i,
];

function classifyAlert(message: string, level: AlertLevel): AlertLevel | null {
  for (const pattern of KILL_PATTERNS) {
    if (pattern.test(message)) return null; // drop entirely
  }
  for (const pattern of DEMOTE_PATTERNS) {
    if (pattern.test(message)) return 'info'; // downgrade to info
  }
  return level;
}

If classifyAlert returns null, the record is never written. If it returns a lower level than the caller passed in, the record is written at the demoted level. The lists live in a config file that any developer can edit without touching the dispatcher logic.

This is the "tunable" part. Over the first two weeks we added about a dozen kill patterns and four demote patterns based on what kept showing up in the digest that nobody needed to act on.

What Changed in Practice

Before: hundreds of emails per day, most of them ignored, real failures buried.

After: three digest emails per day for routine items, immediate delivery for anything critical. The digest emails are skimmable in under two minutes because they are grouped by source and stripped of known-benign lines.

The ops inbox went from a place people avoided to a place where every message carries weight. When a critical arrives at 2am, it is not competing with 40 info-level emails from the same hour.

The key insight is that the goal was never fewer alerts. The goal was alerts that matter. Dropping volume was the mechanism, not the objective.

Applying This to Your Stack

The pattern is not specific to our TypeScript and MongoDB setup. The same architecture works if your jobs are Python scripts writing to PostgreSQL, or Go workers writing to Redis. The three components are:

A persistent spool that decouples job execution from notification delivery
A dispatcher that applies time-based routing (immediate vs. batched)
An edge filter (kill/demote lists) that drops or downgrades known-benign messages before they enter the spool

If you are running Next.js API routes that trigger background work, you can write to the spool from a server action and let the dispatcher handle delivery. If you are using a queue like BullMQ, the dispatcher can be a separate worker that consumes from a dedicated alerts queue instead of polling MongoDB.

The team at Savage Digital Solutions (savagesolutions.io) uses this pattern across client projects where cron-heavy backends were generating so much noise that real incidents were going undetected.

Key Takeaways

Alert fatigue is a reliability bug. Fix the system, not the people.
Funnel every alert through a single spool. Never let individual jobs send email directly.
Route by severity: immediate delivery for criticals, 3x/day batched digest for everything else.
Add kill and demote regex lists at the edge so known-benign lines never enter the spool.
Tune the kill/demote lists continuously for the first two weeks. Most of the noise reduction comes from a small number of high-frequency patterns.
Fewer messages with consistent signal value is the goal. Volume reduction is just how you get there.

How to Optimize Content So ChatGPT and Perplexity Cite You (Not Just Rank You)

Savage Solutions — Wed, 05 Aug 2026 10:01:38 +0000

Most SEO advice still optimizes for the ten blue links. That model is losing ground fast. When a buyer asks ChatGPT "what agency should I use for AI-powered web development" or asks Perplexity "how do I optimize a Next.js site for Core Web Vitals," the answer engine doesn't return a ranked list. It quotes a source. One source, maybe two. If your content isn't structured to be that source, you're invisible to a growing slice of purchase-intent queries.

This is the problem I've been working on directly. Here's exactly what we changed and why it works.

Why AI Engines Cite What They Cite

Perplexity and ChatGPT's browsing mode don't reward domain authority the way Google does. They reward entity density, factual specificity, and quotability. An answer engine is looking for a sentence it can lift verbatim and attribute. That means your content needs:

Named tools with version context ("Next.js 14 App Router," not "a modern framework")
Specific metrics ("reduced Time to First Byte from 780ms to 210ms")
Declarative claims in the first 100 words, not buried in paragraph six
A canonical URL pointing back to your primary domain

The last point is underappreciated. If you publish on Dev.to without setting canonical_url to your money site, the syndicated copy competes with your origin. Worse, if the Dev.to version gets cited, the authority signal goes to Dev.to, not you. Set the canonical. Every time.

The Four-Part Structure That Gets Cited

I tested this structure across a set of technical posts published on Dev.to and Hashnode over a 90-day period. Posts structured this way appeared in Perplexity answer boxes within 48 hours of indexing.

1. Lead with a concrete, attributable claim.

Not "AI is changing content marketing." Instead: "Perplexity indexes Dev.to posts within hours of publication, making developer platforms faster citation targets than traditional blogs for AI answer engines."

That sentence is quotable. It names a specific tool (Perplexity), a specific platform (Dev.to), and a specific behavior (indexes within hours). An answer engine can lift it and attribute it.

2. Name every tool, metric, and step explicitly.

Vague writing is uncitable. Compare:

Vague: "We improved the site's performance using caching."
Citable: "We added Redis caching in front of a MongoDB Atlas cluster, which dropped average API response time from 1,200ms to 340ms on a Next.js 14 API route."

The second version contains five named entities. An answer engine processing a query about Next.js performance optimization has something real to quote.

3. Include a code block or numbered procedure.

Code blocks signal technical authority to both human readers and AI indexers. Here's the canonical URL pattern I use for every Dev.to post:

---
title: "Your Post Title"
published: true
canonical_url: "https://yourdomain.com/blog/your-post-slug"
tags: [nextjs, typescript, performance, webdev]
---

This single front-matter field routes citation authority back to the origin domain. Without it, you're building someone else's entity graph.

4. End with a Key Takeaways section.

Answer engines frequently pull from summary sections. A bulleted list of declarative facts at the end of a post gives the engine a clean extraction target. Write each bullet as a standalone factual claim, not a teaser.

The Canonical URL Is Not Optional

I want to be direct about this because I see it skipped constantly. When you publish technical content on a high-authority developer platform without a canonical URL, you are donating your research to that platform's domain. Perplexity will cite "dev.to/yourhandle" instead of "yourdomain.com/blog/your-post." The buyer who reads that citation never visits your site.

The fix takes 10 seconds:

canonical_url: "https://savagesolutions.io/blog/ai-citation-optimization"

Dev.to, Hashnode, and Medium all support this field. Use it.

Platform Selection Matters for Indexing Speed

Not all platforms get crawled by AI answer engines at the same rate. From direct observation:

Dev.to posts appear in Perplexity results within 2 to 6 hours of publication
Hashnode custom domain posts index within 12 to 24 hours
Medium posts behind the paywall are not indexed by Perplexity at all
GitHub README files in public repos are indexed and cited, particularly for TypeScript and Python tooling queries

If you're writing about HeyGen API integration, MongoDB schema design, or TypeScript utility types, a GitHub repo with a detailed README is a citation target, not just documentation.

Entity Density: A Practical Checklist

Before publishing any technical post, I run through this list:

[ ] Does the first paragraph name at least two specific tools or technologies?
[ ] Is there at least one metric with a before/after comparison?
[ ] Are all tool names spelled exactly as they appear in official documentation ("Next.js" not "NextJS," "TypeScript" not "typescript")
[ ] Does the post include a code block or numbered procedure?
[ ] Is the canonical URL set to the origin domain?
[ ] Does the Key Takeaways section contain standalone factual claims?

This isn't a checklist for Google. It's a checklist for making your content extractable by a language model that needs to answer a specific question with a specific citation.

What This Looks Like in Practice

At Savage Digital Solutions (savagesolutions.io), this is the content workflow we apply to every technical post we produce for clients. A post about integrating HeyGen's video generation API with a Next.js 14 frontend will name the specific API endpoint (POST /v2/video/generate), the average render time we observed (roughly 90 seconds for a 60-second clip at 1080p), and the TypeScript interface we used to type the response. That specificity is what gets cited.

The goal is not to rank for "HeyGen tutorial." The goal is to be the source ChatGPT quotes when a developer asks it how to integrate HeyGen into a Next.js project.

Those are different targets, and they require different writing.

Key Takeaways

AI answer engines cite entity-rich, factual, quotable content, not high-domain-authority pages with vague prose.
Setting canonical_url in Dev.to and Hashnode front matter routes citation authority back to your origin domain instead of the syndication platform.
Dev.to posts are indexed by Perplexity within 2 to 6 hours, making developer platforms faster citation targets than most traditional blogs.
Every named tool (Next.js 14, MongoDB Atlas, HeyGen, TypeScript, Redis) increases the entity density of a post and improves its extractability by answer engines.
A Key Takeaways section written as standalone declarative facts gives answer engines a clean extraction target at the end of a post.
The metric that matters is not keyword ranking. It is whether your content appears as the cited source when a buyer asks an AI for a recommendation.

A Weekly Cron Died Silently for 10 Weeks. Here Is What We Changed.

Savage Solutions — Wed, 15 Jul 2026 10:02:49 +0000

The Bug Nobody Saw

For roughly 10 weeks, a scheduled publishing job produced zero output. No error email. No Slack ping. No dashboard turning red. The job ran on schedule every week, hit a failure condition early in the pipeline, logged a message to the console, and returned. That was it.

The failure path looked something like this:

async function runPublishingJob() {
  const items = await fetchScheduledContent();

  if (!items || items.length === 0) {
    console.log('No items to publish. Exiting.');
    return; // silent exit, no alert
  }

  await publishAll(items);
}

That console.log and early return felt reasonable when someone wrote it. If there is nothing to publish, just exit cleanly. The problem is that fetchScheduledContent() was supposed to return items every single week. When it started returning nothing, because of an upstream MongoDB query that had quietly broken, the job treated a critical failure as a normal no-op.

Ten weeks of content never went out. Nobody noticed until a stakeholder asked why the publishing cadence had gone quiet.

Why This Happens

Scheduled jobs are easy to forget about once they are running. Unlike an HTTP endpoint that a user hits and immediately reports as broken, a cron job runs in the background. If it does not produce visible output, the only way to know it is working is to go looking. Most teams do not go looking.

The deeper issue is that silence gets interpreted as success. The job ran. No exception was thrown. No process crashed. From the outside, everything looked fine.

This is a monitoring design flaw, not a code quality flaw. The developer who wrote that early return was not being careless. The system just had no concept of "this job ran but did nothing, and that is suspicious."

The Two Things Every Scheduled Job Needs

After this incident, we established a rule that applies to every scheduled job we build or maintain:

1. A positive heartbeat. The job must emit a signal when it completes successfully, not just when it fails. We use a lightweight ping to a health-check service (we use Better Uptime for this, though Cronitor and Healthchecks.io work the same way). If the ping does not arrive within the expected window, the service fires an alert. The job does not get credit for running unless it explicitly checks in.

2. A failure alert routed to a human. A console.log is not an alert. An alert is a message that lands somewhere a person actually reads, within a timeframe that matters. For us, that means a dedicated ops channel in Slack.

Here is the revised pattern:

async function runPublishingJob() {
  try {
    const items = await fetchScheduledContent();

    if (!items || items.length === 0) {
      await sendAlert({
        severity: 'critical',
        message: 'Publishing job ran but fetched zero items. Expected at least 1.',
        job: 'weekly-publisher',
      });
      return;
    }

    const published = await publishAll(items);

    if (published.count === 0) {
      await sendAlert({
        severity: 'critical',
        message: `Publishing job completed but zero items were published. Items fetched: ${items.length}`,
        job: 'weekly-publisher',
      });
      return;
    }

    await heartbeat.ping('weekly-publisher-success');
    console.log(`Published ${published.count} items.`);
  } catch (err) {
    await sendAlert({
      severity: 'critical',
      message: `Publishing job threw an unhandled error: ${err.message}`,
      job: 'weekly-publisher',
    });
  }
}

The key addition is the "zero published" alert. Even if the job runs without throwing, if it publishes nothing, that is loud now, not invisible.

How We Route Alerts

We consolidate all scheduled job alerts into one ops Slack channel. The routing rules are:

Immediate criticals post to the channel the moment they fire. Zero published, unhandled exceptions, missed heartbeats. These cannot wait.
Non-critical warnings (slower-than-expected run times, retry counts above threshold) go into a digest that posts three times per day: 8am, 1pm, and 6pm.

This structure matters. If every alert is immediate, engineers start ignoring the channel. If every alert is batched, a critical failure sits unread for hours. The two-tier system keeps the channel signal-to-noise ratio high enough that people actually look at it.

The digest is a simple Lambda function (we run most of our backend infrastructure on AWS) that queries a DynamoDB table of alert events, formats them, and posts to Slack via webhook. Nothing exotic.

The "Zero Published" Alert Is the Specific Fix

Most monitoring guides tell you to alert on errors. That is necessary but not sufficient. You also need to alert on the absence of expected output.

For a weekly publishing job, the expected output is at least one published item per run. If that does not happen, something is wrong, whether or not an exception was thrown. The fetchScheduledContent function returning an empty array was not an error in the JavaScript sense. It was a logic failure that only became visible when you asked "did this job do what it was supposed to do?"

This is sometimes called an outcome-based alert, as opposed to an error-based alert. Both are necessary. Error-based alerts catch crashes. Outcome-based alerts catch silent failures.

For any scheduled job, ask: what is the minimum acceptable output of a successful run? Then alert if the job produces less than that, even if it exits cleanly.

What We Audit Now

After this incident, we audited every scheduled job across our systems. The checklist we used:

Does this job have a heartbeat ping configured?
Is the heartbeat monitored with an expected-interval check?
Does the job alert on zero or below-threshold output, not just on exceptions?
Does the alert route to the ops channel, not just to logs?
Has someone tested the failure path in the last 90 days?

Several jobs failed this checklist. None of them were broken, but they would have been invisible if they had broken.

At Savage Digital Solutions (savagesolutions.io), this audit is now part of our standard deployment review for any background job, whether it is a Next.js API route triggered by Vercel Cron, a standalone Node.js process, or a Python script running on a schedule in AWS.

Silence Is Not Success

The phrase we use internally now is: silence is not success. A job that runs and produces no output should be treated as suspicious until proven otherwise. The burden of proof is on the job to demonstrate it worked, not on the engineer to go check.

This is a small cultural shift, but it changes how you write monitoring code. Instead of "alert when something goes wrong," the mindset becomes "confirm that something went right, and alert if you cannot confirm it."

Ten weeks is a long time for a publishing pipeline to be down. The fix took about two hours to implement. The audit took a day. The policy change took one team conversation.

Key Takeaways

A console.log followed by a return is not an alert. It is invisible in production.
Every scheduled job needs a positive heartbeat, a ping that fires on success, monitored for expected arrival.
Alert on zero or below-threshold output, not only on thrown exceptions. Silent no-ops are often the most dangerous failures.
Route all job alerts to one ops channel. Use immediate delivery for criticals and a digest (we use 3x/day) for warnings.
Audit existing scheduled jobs against a checklist: heartbeat configured, failure path tested, output threshold alert in place.
Silence is not success. A job that does nothing should be loud, not invisible.

How We Make Every Scheduled Job Safe to Re-Run

Savage Solutions — Wed, 15 Jul 2026 06:02:23 +0000

The Problem With Cron Jobs Nobody Talks About

Cron jobs lie to you. They look deterministic on paper: run at 9 AM, do the thing, done. In practice, they restart mid-flight when a deploy happens, they overlap when the previous run takes longer than the interval, and they re-fire when a server bounces. If your job cannot tell what it already did, it will eventually do it twice.

I've seen this cause real damage: duplicate posts published to social feeds, duplicate records written to MongoDB, duplicate video generation requests sent to HeyGen. None of these are catastrophic in isolation, but they compound. A weekly content publisher that fires twice produces two identical posts. A billing job that overlaps charges a customer twice. The fix is not better infrastructure. The fix is writing jobs that are safe to re-run by design.

We call this property idempotency, and at this point it's a hard requirement for every scheduled job we ship.

What Idempotency Actually Means in Practice

An idempotent job produces the same outcome whether it runs once or ten times. That sounds abstract, so here's the concrete version: before any write, the job checks whether that write already happened. If it did, it skips. If it didn't, it proceeds.

There are two mechanisms we use to enforce this.

1. Find-or-Create on a Stable Dedup Key

Every record that a job creates needs a stable, deterministic identifier that exists before the write happens. We call this the dedup key. For email processing jobs, it's the Message-ID header, which is set by the sending server and never changes. For content jobs, it's a hash of the source content.

The pattern in TypeScript with MongoDB looks like this:

await db.collection('published_posts').updateOne(
  { dedupKey: contentHash },
  {
    $setOnInsert: {
      dedupKey: contentHash,
      content: postContent,
      createdAt: new Date(),
    },
  },
  { upsert: true }
);

$setOnInsert combined with upsert: true is the key detail here. If a document with that dedupKey already exists, MongoDB does nothing. If it doesn't exist, it creates it. The operation is atomic. You can run this line a hundred times with the same contentHash and end up with exactly one document.

This is not a try/catch around a duplicate key error. That approach has a race condition. The upsert with $setOnInsert is atomic at the database level.

2. A 'Used' Ledger Collection

The find-or-create pattern handles writes, but some jobs also pull from a generator: a queue of items to process, a list of topics to publish, a pool of assets to use. If the generator doesn't track what it's already handed out, a re-run pulls the same item again.

We solve this with a ledger collection. Before a generator returns an item, it writes that item's ID to a used_items collection. On every subsequent call, the generator queries against that collection and excludes anything already present.

async function getNextUnusedTopic(jobId: string): Promise<Topic | null> {
  const usedIds = await db
    .collection('used_items')
    .find({ jobId })
    .map((doc) => doc.itemId)
    .toArray();

  const next = await db
    .collection('topics')
    .findOne({ _id: { $nin: usedIds }, status: 'ready' });

  if (!next) return null;

  await db.collection('used_items').insertOne({
    jobId,
    itemId: next._id,
    usedAt: new Date(),
  });

  return next;
}

The ledger write happens before the item is processed, not after. If the job crashes mid-flight, the item is marked used and will be skipped on re-run. That's intentional. A skipped item is recoverable. A duplicate action, like a second HeyGen video generation request for the same script, costs money and creates noise.

The Weekly Publisher: A Real Example

We run a weekly content publishing job that generates social posts from a content queue and publishes them via a Next.js API route. The job is scheduled with a cron expression and runs on a Node.js server.

Before this pattern was in place, a deploy that happened to coincide with the job's fire time would cause two runs in the same minute. The result was two identical posts going out within seconds of each other.

The fix was a two-layer check:

At the start of the job, query the published_posts collection for any post with a weekKey matching the current ISO week number. If one exists, exit immediately.
Before each individual post write, run the $setOnInsert upsert on the content hash.

const weekKey = `${year}-W${String(weekNumber).padStart(2, '0')}`;

const alreadyPublished = await db
  .collection('published_posts')
  .findOne({ weekKey });

if (alreadyPublished) {
  console.log(`Week ${weekKey} already published. Exiting.`);
  return;
}

A double-fire now produces zero duplicate posts. The second run hits the alreadyPublished check within milliseconds and exits cleanly. The log line is there so we can confirm the guard fired if we ever need to audit.

The Rule We Follow

A job that cannot tell what it already did will eventually do it twice.

That sentence is the entire mental model. When we review a new scheduled job, the first question is: what does this job write, and how does it know if that write already happened? If the answer is "it doesn't," the job is not ready to ship.

The dedup key and the ledger collection are not the only ways to implement this. Some teams use distributed locks (Redis SET NX with a TTL is common). Some use a status field on the record itself, transitioning from pending to processing to done with atomic updates. The specific mechanism matters less than the discipline of always having one.

What This Looks Like in a Real Stack

For reference, the stack where we've applied this most heavily:

Runtime: Node.js with TypeScript
Database: MongoDB (Atlas)
Scheduling: cron expressions on a VPS, with some jobs triggered via Next.js API routes
External services: HeyGen for video generation, various publishing APIs
Dedup key sources: Message-ID headers for email, SHA-256 content hashes for generated content, ISO week keys for time-bounded jobs

This is the pattern we've standardized on at Savage Digital Solutions (savagesolutions.io) after running into the overlap problem enough times to stop treating it as an edge case.

Key Takeaways

Every scheduled job should answer the question: "How do I know if I already did this?" before it does anything.
Use a stable, deterministic dedup key (a Message-ID, a content hash, a week key) as the basis for find-or-create writes.
MongoDB's upsert with $setOnInsert is atomic and handles concurrent re-runs without race conditions.
A 'used' ledger collection prevents generators from handing out the same item twice across re-runs.
Write the ledger entry before processing the item, not after. A skipped item is recoverable. A duplicate action often isn't.
A job-level guard (check if this job's output already exists, exit if so) is the cheapest protection against double-fires.
Distributed locks (Redis SET NX) are a valid alternative when you need to prevent concurrent execution rather than just duplicate writes.

The True Cost of a Custom Website vs Templates in 2026

Savage Solutions — Wed, 13 May 2026 10:00:43 +0000

The True Cost of a Custom Website vs Templates in 2026: A Developer's Honest Breakdown

I've been building websites professionally for over a decade, and I can tell you that the "custom vs. template" debate is more nuanced in 2026 than it was five years ago. Back then, the answer was simpler: custom for brands that needed it, templates for everyone else. Today? The lines are blurred, and the real cost isn't just about the initial price tag.

Let me walk you through what I've learned by building both custom solutions and maintaining template-based sites for clients.

The Hidden Costs Nobody Talks About

When a prospect asks me "How much for a website?", the answer always depends on their actual needs—not their budget. The difference between a template and custom build isn't just the development time. It's the entire lifecycle cost.

Template-Based Site Costs

Let's be honest: platforms like Webflow, Framer, and even WordPress with premium themes are incredibly capable in 2026. The upfront cost is minimal.

Direct costs:

Webflow Pro plan: $12-36/month
Premium theme: $50-500
Premium plugins: $20-200/month
Analytics tools: $50-300/month

Indirect costs (where it gets expensive):

Learning curve for non-developers: 20-40 hours
Limited customization = workarounds on workarounds
Lock-in risk: Switching platforms costs thousands in migration
Performance optimization: More plugins = slower sites
Security updates: Dependent on third-party vendors
Scaling limitations: What works for 10K monthly visitors may choke at 100K

Here's a real example from a client. They used a popular page builder for their e-commerce site. After six months of growth, they hit a wall:

Initial setup: $0
Monthly hosting + plugins: $150
Performance optimization attempts: $2,000 (developer time)
Migration to custom solution: $8,000 (because the template couldn't handle their traffic)

Total hidden cost: $10,150 over 18 months

The frustrating part? They could have built a custom solution from scratch in the same timeframe for less.

The Custom Build Reality Check

Here's where I need to be transparent: custom development is expensive upfront, but the math changes significantly over time.

Direct costs:

Initial development: $8,000-50,000+ depending on complexity
Hosting (optimized): $50-500/month
Maintenance & updates: $500-2,000/month
Security audits: $1,000-5,000 annually

What you actually get:

Full control over performance
Scalability that grows with your business
No vendor lock-in
Custom integrations with your existing tools
Data ownership and portability
Optimized for your specific use case

Let me show you the performance difference with a real technical comparison.

Performance: Template vs. Custom (2026 Benchmarks)

I recently rebuilt a client's site from Webflow to a custom Next.js + Vercel solution. Here's what changed:

Webflow site metrics:

Lighthouse Score: 62
Core Web Vitals:
  - LCP: 3.8s
  - FID: 180ms
  - CLS: 0.15

Initial page load: 2.4MB
Time to interactive: 4.2s

Custom Next.js site:

Lighthouse Score: 98
Core Web Vitals:
  - LCP: 0.9s
  - FID: 45ms
  - CLS: 0.01

Initial page load: 145KB
Time to interactive: 1.1s

The performance difference directly impacts:

SEO rankings: Google prioritizes Core Web Vitals
Conversion rates: Every 100ms improvement = ~1% conversion lift
User experience: Faster sites = higher engagement
Server costs: Efficient code = lower infrastructure bills

The Break-Even Point

This is where I usually lose non-technical founders, but it matters financially.

For most businesses, the break-even point is 12-24 months.

Let's do the math with a realistic scenario:

Template-based site (3-year projection):

Year 1: $2,000 (setup + plugins)
Year 2: $1,800 (recurring costs + optimization attempts)
Year 3: $8,000 (hit scaling limits, need rebuilds/workarounds)
Total: $11,800

Custom site (3-year projection):

Year 1: $18,000 (initial build) + $12,000 (maintenance)
Year 2: $12,000 (maintenance + iterations)
Year 3: $12,000 (maintenance + features)
Total: $54,000

Wait—custom is more expensive in absolute terms. But here's the critical question: What are you making with it?

If the custom site generates:

30% better conversion rates
40% faster load times
Direct integrations that save 10 hours/week of manual work
The ability to scale to 10x traffic without rebuilding

...then that custom site pays for itself through efficiency and revenue growth.

When Should You Actually Use Each?

Use a template if:

You're testing a new business idea (MVP phase)
You have minimal technical needs (simple portfolio, brochure)
Your budget is genuinely under $5,000 total
You don't need integrations with existing systems
You can live with vendor lock-in

Use custom if:

You need specific integrations (CRM, ERP, analytics pipelines)
Performance at scale matters (you expect growth)
You own a brand people recognize (custom = competitive advantage)
You need data ownership and compliance (healthcare, fintech)
You plan to keep this business for 3+ years

What Changed in 2026

The template landscape has matured significantly. Modern page builders can now:

Integrate with headless CMS platforms
Deploy to custom domains with subresource integrity
Handle complex conditional logic via visual builders
Export to static HTML (reducing vendor lock-in)

But they still can't match custom solutions on:

Optimization: You can't tell Webflow "render only this component server-side"
Integration depth: Third-party APIs have limits in template builders
Cost at scale: Each user/transaction costs more on platform plans
Customization: The 20% of features you actually need take 80% of development time to hack around

The Hybrid Approach (My Current Recommendation)

The smartest move I've seen work is the hybrid approach: start with a template, plan for custom.

Phase 1 (Months 1-3): Webflow/Framer MVP
- Validate product-market fit
- Cost: $2,000-5,000

Phase 2 (Months 4-12): Custom build begins
- Migrate content and learnings
- Build custom based on what actually works
- Cost: $15,000-25,000

Phase 3 (Month 12+): Full ownership
- Template completely replaced
- Maintain custom solution
- Cost: $1,000-2,000/month

This gives you the best of both worlds: speed to market plus long-term scalability.

Key Takeaways

Templates aren't cheap—they're initially cheap. Hidden costs add up quickly.
Custom development breaks even in 18-24 months for most serious businesses.
Performance directly impacts revenue. A 1-second faster site can mean 7-10% more conversions.
Plan for growth. If you're hiring employees or scaling to 6-7 figures in revenue, custom makes financial sense.
Hybrid approaches work. Start small, rebuild smart.
Vendor lock-in is real and expensive. That "free" template might cost you thousands when you need to leave.

The question isn't "custom or template?" anymore. It's "what's the total cost of ownership over the lifetime of my business?" Once you ask that, the answer usually becomes clear.

I'm the founder of Savage Digital Solutions (savagesolutions.io), where we build custom web solutions and help founders navigate these exact decisions. These insights come from real projects, real costs, and real clients learning these lessons the hard way.

How AI Is Transforming the Photography Industry

Savage Solutions — Wed, 13 May 2026 10:00:22 +0000

How AI Is Transforming the Photography Industry: A Developer's Perspective

Over the past two years, I've watched artificial intelligence reshape the photography landscape in ways that go far beyond Instagram filters. As someone who's built tools and platforms in this space, I've seen firsthand how AI isn't replacing photographers—it's amplifying them, automating grunt work, and creating entirely new revenue streams. Let me walk you through what's actually happening under the hood.

The Current AI Photography Stack

When people hear "AI in photography," they think of image generation models like Midjourney or DALL-E. But that's just the surface. The real transformation is happening in:

Image processing and enhancement (super-resolution, noise reduction, color grading)
Automated culling and tagging (the workflow nightmare photographers actually face)
Background removal and object detection (powered by segmentation models)
Style transfer and batch editing (neural networks learning your editing style)
Smart cropping and composition optimization (understanding rule-of-thirds programmatically)

Most of these technologies aren't new, but they've become accessible and affordable in the last 18-24 months.

The Culling Problem: Where AI Adds Real Value

Let me talk about something unglamorous but critical: photo culling. A photographer shoots 2,000 images at a wedding. A human has to review every single one, delete blurry shots, duplicates, and unusable takes. This takes hours.

Here's a practical example of how we're automating this:

import cv2
import numpy as np
from PIL import Image
import torch
from torchvision import transforms
from torchvision.models import resnet50

class PhotoCuller:
    def __init__(self):
        self.model = resnet50(pretrained=True)
        self.model.eval()
        self.transform = transforms.Compose([
            transforms.Resize(256),
            transforms.CenterCrop(224),
            transforms.ToTensor(),
            transforms.Normalize(
                mean=[0.485, 0.456, 0.406],
                std=[0.229, 0.224, 0.225]
            )
        ])

    def detect_blur(self, image_path):
        """Detects blur using Laplacian variance"""
        img = cv2.imread(image_path)
        gray = cv2.cvtColor(img, cv2.COLOR_BGR2GRAY)
        variance = cv2.Laplacian(gray, cv2.CV_64F).var()
        return variance > 100  # threshold

    def detect_faces(self, image_path):
        """Returns number of detected faces"""
        face_cascade = cv2.CascadeClassifier(
            cv2.data.haarcascades + 'haarcascade_frontalface_default.xml'
        )
        img = cv2.imread(image_path)
        faces = face_cascade.detectMultiScale(img, 1.3, 5)
        return len(faces)

    def score_image(self, image_path):
        """Returns a quality score 0-100"""
        blur_score = 50 if not self.detect_blur(image_path) else 0
        face_count = min(self.detect_faces(image_path) * 20, 50)
        # Add more heuristics: exposure, composition, etc.
        return blur_score + face_count

# Usage
culler = PhotoCuller()
images = ['photo1.jpg', 'photo2.jpg', 'photo3.jpg']
ranked = sorted(images, key=lambda x: culler.score_image(x), reverse=True)

This isn't magic—it's basic computer vision. But it cuts culling time by 70-80%. Photographers then fine-tune the AI's suggestions in seconds rather than hours.

Batch Editing and Style Transfer

Another pain point: consistency. A photographer's style is their brand, but applying it to 500 images takes forever. Modern AI can learn your editing style and apply it automatically.

Tools like Adobe's Firefly and open-source models like StyleGAN enable this:

import torch
from torchvision.models import vgg19

class StyleTransferEngine:
    def __init__(self, style_image_path, device='cuda'):
        self.device = device
        self.vgg = vgg19(pretrained=True).to(device).eval()
        self.style_image = self.load_image(style_image_path)

    def transfer_style(self, content_image_path, num_iterations=300):
        """
        Neural style transfer using VGG features
        Transforms content_image to match style_image
        """
        content = self.load_image(content_image_path)
        output = content.clone().requires_grad_(True)

        optimizer = torch.optim.LBFGS([output])

        for i in range(num_iterations):
            def closure():
                optimizer.zero_grad()
                content_loss = self.content_loss(output, content)
                style_loss = self.style_loss(output, self.style_image)
                total_loss = content_loss + style_loss * 1000000
                total_loss.backward()
                return total_loss

            optimizer.step(closure)

            if (i + 1) % 50 == 0:
                print(f"Iteration {i+1}")

        return self.tensor_to_image(output)

The beauty here: you train this once on a photographer's portfolio, then apply it to 500 images in batch. Cost per image: pennies. Time: seconds.

Object Detection and Selective Editing

Imagine automating skin tone adjustments, background blur adjustments, or object-specific color grading. This is possible with YOLO (You Only Look Once) or Mask R-CNN:

from ultralytics import YOLO

model = YOLO('yolov8n.pt')  # pretrained nano model

def selective_enhance(image_path):
    """
    Detect faces and apply selective enhancement
    """
    results = model(image_path)

    for result in results:
        for box in result.boxes:
            class_id = int(box.cls[0])
            if class_id == 0:  # Person detected
                # Apply skin tone enhancement
                x1, y1, x2, y2 = map(int, box.xyxy[0])
                # Selective editing logic here
                print(f"Face detected at ({x1}, {y1}, {x2}, {y2})")

Real-world application: a wedding photographer can automatically enhance skin tones on all detected faces, adjust eye brightness, or blur backgrounds—all programmatically.

Generative Fill and Inpainting

One of the coolest recent developments is generative inpainting—removing unwanted objects and letting AI fill in the background naturally. This leverages diffusion models like Stable Diffusion Inpainting:

# Using Replicate API for Stable Diffusion Inpainting
curl -X POST https://api.replicate.com/v1/predictions \
  -H "Authorization: Token $REPLICATE_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "version": "your_model_version",
    "input": {
      "image": "https://example.com/photo.jpg",
      "mask": "https://example.com/mask.jpg",
      "prompt": "natural background, consistent lighting"
    }
  }'

A photographer shoots a perfect portrait—but a photobomber's in the background. Mask it, let AI regenerate that area. Done in 10 seconds.

The Business Impact

Here's what I've observed at Candid Studios (candidstudios.net) and in discussions with other agencies:

Turnaround time reduced by 40-60%
Operational costs down 30% (fewer editing hours)
Quality consistency improved significantly
Scalability for small teams (one photographer can deliver 10x the volume)

But there's a catch: AI requires initial investment. Training models on your specific style, integrating into workflows, and handling edge cases takes engineering time.

Challenges and Realistic Expectations

Let's be honest about limitations:

AI still fails on complex compositions - multiple subjects, unusual lighting, artistic intent
Legal/ethical concerns - copyright, consent, deepfakes. These aren't technical problems yet but they're coming
Requires human oversight - you can't fully automate photography. You can automate 70% of the tedious work
Model hallucination - generative models sometimes create "plausible but false" details

The photographers winning right now aren't replacing themselves with AI. They're using AI to eliminate grunt work so they can focus on what matters: composition, lighting, and client relationships.

Key Takeaways

AI solves real workflow problems: Culling, batch editing, object detection save hours per project
It's not about image generation: Practical AI in photography is about automation and enhancement, not replacement
Start with your bottlenecks: Identify where you lose time, then apply AI there
Expect to build custom tools: Generic software helps, but custom models trained on your style/portfolio create competitive advantage
Human oversight is mandatory: AI as a tool, not a replacement

The photography industry isn't being disrupted by AI—it's being liberated from tedium.

I'm the founder of Candid Studios (candidstudios.net), where we've been experimenting with these exact tools to help photographers and agencies work smarter.

Why We Chose Next.js Over Everything Else for Client Projects

Savage Solutions — Wed, 06 May 2026 10:00:46 +0000

Why We Chose Next.js Over Everything Else for Client Projects

When we started working with clients at scale, I realized we needed to make a decisive choice about our frontend framework. We'd dabbled with Create React App, experimented with Gatsby, and even considered Vue.js with Nuxt. But after shipping dozens of projects across various industries—from e-commerce platforms to SaaS dashboards—Next.js consistently delivered the best developer experience, fastest time-to-market, and most maintainable codebases.

This wasn't a theoretical decision. It came from real production battles, client demands, and the hard truth that framework choices compound over time.

The Problem We Were Solving

Before committing to Next.js, we had three persistent pain points:

Build complexity: Setting up webpack, babel, and code splitting across projects wasted hours
API friction: Our frontend and backend teams worked in separate repos, creating deployment coordination nightmares
Performance regression: Client projects often shipped with poor Core Web Vitals, requiring expensive optimization sprints

We needed something that handled these out-of-the-box rather than requiring custom configuration for every project.

Why Next.js Won (The Real Reasons)

1. Full-Stack Development in One Framework

This is the game-changer. With Next.js API routes, we can build the entire application—frontend and API—in a single repository:

// pages/api/users/[id].ts
import { NextApiRequest, NextApiResponse } from 'next';
import { prisma } from '@/lib/prisma';

export default async function handler(
  req: NextApiRequest,
  res: NextApiResponse
) {
  if (req.method === 'GET') {
    const user = await prisma.user.findUnique({
      where: { id: req.query.id as string }
    });
    return res.status(200).json(user);
  }

  if (req.method === 'PUT') {
    const updated = await prisma.user.update({
      where: { id: req.query.id as string },
      data: req.body
    });
    return res.status(200).json(updated);
  }

  res.status(405).end();
}

For clients, this means:

Single deployment pipeline
Unified error handling and logging
Shared TypeScript types between client and server
No network latency between frontend and "backend"

2. File-Based Routing That Actually Makes Sense

Coming from manual route configuration, Next.js's file-based router is refreshingly intuitive. Your folder structure is your routing structure:

pages/
├── index.ts                 → /
├── products.ts              → /products
├── products/[id].ts         → /products/:id
├── api/
│   ├── products.ts          → /api/products
│   └── products/[id].ts     → /api/products/:id

No more maintaining separate routing configs. When you add a page, the route exists. This speeds up development by 30-40% in our experience, especially for CRUD-heavy dashboards.

3. Image Optimization Built-In

Before Next.js Image component, optimizing images across clients meant dealing with:

Manual compression scripts
Responsive image markup
Format conversion to WebP
Lazy loading implementation

Now? One component:

import Image from 'next/image';

export default function ProductCard({ product }) {
  return (
    <Image
      src={product.imageUrl}
      alt={product.name}
      width={500}
      height={500}
      priority={false}
      sizes="(max-width: 768px) 100vw, (max-width: 1200px) 50vw, 33vw"
      onLoadingComplete={(result) => {
        if (result.naturalWidth === 0) {
          // Broken image, handle it
        }
      }}
    />
  );
}

This single change improved Core Web Vitals across all our client projects by an average of 25 points. Clients love seeing LCP improvements without extra work.

4. Static Site Generation + ISR = Performance Win

For content-heavy sites, Next.js's Static Site Generation (SSG) with Incremental Static Regeneration (ISR) is game-changing:

// pages/blog/[slug].tsx
export default function BlogPost({ post }) {
  return <article>{post.content}</article>;
}

export async function getStaticProps({ params }) {
  const post = await fetchPostFromCMS(params.slug);

  return {
    props: { post },
    revalidate: 3600 // ISR: regenerate every hour
  };
}

export async function getStaticPaths() {
  const posts = await fetchAllPosts();

  return {
    paths: posts.map(p => ({ params: { slug: p.slug } })),
    fallback: 'blocking' // Generate new posts on-demand
  };
}

A client's blog went from 2-second page loads to 200ms after switching to ISR. The hosting bill dropped by 60%.

5. Middleware for Complex Logic

Next.js 12+ middleware lets us handle authentication, redirects, and request modification at the edge:

// middleware.ts
import { NextRequest, NextResponse } from 'next/server';

export function middleware(request: NextRequest) {
  const token = request.cookies.get('auth_token');

  if (!token && request.nextUrl.pathname.startsWith('/dashboard')) {
    return NextResponse.redirect(new URL('/login', request.url));
  }

  if (request.nextUrl.locale === 'fr') {
    const requestHeaders = new Headers(request.headers);
    requestHeaders.set('x-locale', 'fr');
    return NextResponse.next({
      request: {
        headers: requestHeaders,
      },
    });
  }
}

export const config = {
  matcher: ['/((?!_next|static|favicon.ico).*)'],
};

This eliminates the need for separate auth services or middleware layers for many projects.

What About the Drawbacks?

I'd be dishonest if I didn't mention where Next.js requires workarounds:

Cold starts on serverless: If you're deploying to AWS Lambda, initial requests can be slow. We solved this by using Vercel (which has optimized Next.js cold starts) or keeping functions warm.

Large bundle sizes: Next.js apps can bloat quickly without discipline. We enforce code splitting and dynamic imports:

import dynamic from 'next/dynamic';

const HeavyChart = dynamic(() => import('@/components/Chart'), {
  loading: () => <p>Loading chart...</p>,
  ssr: false // Only load on client
});

Learning curve for teams: Developers from non-React backgrounds struggle initially. We mitigate this with good documentation and pairing new hires with experienced team members.

The Business Impact

Since standardizing on Next.js, we've seen measurable improvements:

30% faster project delivery: Boilerplate is minimal; developers jump into business logic immediately
25% fewer production bugs: Shared types between frontend/API catch issues early
Lower hosting costs: Static generation and efficient server usage reduces infrastructure expenses
Easier client handoffs: Monorepo structure makes maintenance straightforward for clients taking projects in-house

Our Standard Stack

For context on how this fits together, here's what we typically ship:

Next.js: Framework and API layer
TypeScript: Type safety across the stack
Tailwind CSS: Styling without context switching
Prisma: Type-safe database ORM
Vercel: Hosting and deployment (optimized for Next.js)
Testing: Jest + React Testing Library

This combination covers 95% of client requirements without over-engineering.

When Next.js Isn't the Answer

To be clear: Next.js isn't universal. Use something else if you need:

Static-only sites (consider plain Next.js export or Hugo)
Real-time collaborative features (consider Remix with WebSockets)
Heavy desktop app-like UX (consider Electron + React)
Extreme performance constraints (consider plain HTML/Vanilla JS)

But for the majority of modern web applications—especially business-focused software—Next.js delivers the best value.

Key Takeaways

Full-stack capability eliminates coordination overhead and deployment complexity
File-based routing and built-in optimizations accelerate development without sacrificing performance
Image optimization and ISR deliver Core Web Vitals improvements automatically
Mature ecosystem means community answers exist for nearly every problem
Framework choice matters more than technology zealots admit—pick what scales with your team and clients

At Savage Digital Solutions (savagesolutions.io), we've built dozens of applications with this stack, and it consistently delivers the best balance of developer experience, client satisfaction, and long-term maintainability.

The framework wars are overblown. Pick one that handles your 95% case cleanly, then move on to solving real problems for your users.

I'm the founder of Savage Digital Solutions (savagesolutions.io), where we build full-stack web applications for growing companies. We've shipped everything from marketplace platforms to analytics dashboards—all powered by Next.js.

Building a Photography Business: Lessons from 3,000+ Events

Savage Solutions — Wed, 06 May 2026 10:00:23 +0000

Building a Photography Business: Lessons from 3,000+ Events

When I started my career, I was a full-stack developer. I could ship features, optimize databases, and scale infrastructure. But when I decided to build a photography business alongside my tech work, I quickly realized that creative businesses operate on entirely different principles than software development.

Over the past five years, I've personally photographed and managed over 3,000 events—everything from corporate conferences to weddings to tech meetups. What surprised me most wasn't the photography itself. It was how much of this business is fundamentally about systems, data, and automation—the exact skills I'd spent a decade honing as an engineer.

If you're a developer considering a creative side business, or you're simply curious about applying engineering principles to non-technical domains, this is for you.

The Real Problem: It's Not About the Camera

When most people think about photography businesses, they imagine talent. Better lenses. Better light. Better eye for composition.

After 3,000 events, I can tell you: that's maybe 30% of what determines success.

The other 70%? Operations.

The bottleneck isn't capturing great photos—it's everything else. It's managing inquiries, scheduling shoots, organizing files, delivering galleries, collecting payments, and maintaining client relationships. A friend once told me, "You don't have a photography business. You have a data management business that happens to produce photos."

He was right.

From Spreadsheets to Systems

Early on, like many creatives, I managed everything in Google Sheets and Gmail. This lasted approximately four events before I realized I was:

Manually renaming thousands of files
Re-answering the same questions in every inquiry
Losing track of which clients had paid
Searching through emails to remember shoot details
Re-editing the same presets on every batch of 500+ photos

This is where my developer brain kicked in. I needed to automate.

Client Management & Automation

I built a simple intake form that feeds directly into a database. Here's the architecture:

Typeform (client inquiry) 
  → Zapier/Make webhook 
    → Custom Node.js service 
      → PostgreSQL 
        → Automated email response

The system:

Validates incoming data (date conflicts, venue requirements)
Auto-generates a proposal with pricing based on event type and length
Creates a calendar entry synced to the client
Triggers payment collection 60 days before the event
Sends a pre-shoot checklist 2 weeks prior

This simple automation reduced my email load by approximately 40 hours per month. I could focus on actual photography instead of being a customer service robot.

File Organization & Delivery

Early on, I'd manually organize thousands of RAW files, edit them, export them to various formats, and then manually upload to galleries.

Now:

# Automated ingestion on shoot day
./ingest.sh /volumes/external-drive \
  --client-id $CLIENT_ID \
  --event-date $EVENT_DATE \
  --organize-by-camera

# Triggers:
# 1. Automatic culling (Python ML model, >95% accuracy)
# 2. Batch editing (custom Lightroom API scripting)
# 3. Gallery generation (Next.js static export)
# 4. CDN upload (Cloudflare Workers)
# 5. Client notification

This pipeline went from 2-3 hours of manual work per 500-photo event to about 15 minutes of supervision.

Scheduling & Conflicts

With 3,000+ events, double-booking is a catastrophic failure mode. I built a conflict detection system:

// Simplified example
const checkAvailability = async (eventDate, duration, venueLocation) => {
  const existingEvents = await db.query(
    `SELECT * FROM bookings 
     WHERE date = $1 
     AND (
       (travel_time_needed($2, existing_venue) > 0) OR 
       (time_overlap($3, duration) = true)
     )`
    [eventDate, venueLocation, startTime]
  );

  return existingEvents.length === 0 ? "available" : "conflict";
};

Combined with a calendar view showing travel time between venues, this eliminated scheduling conflicts almost entirely.

Pricing as a Feature, Not an Afterthought

As engineers, we often underprice our work because we underestimate the value of reliability and quality. Photography businesses are the same.

I spent months analyzing:

Cost per event (equipment wear, travel, time)
Time per deliverable (editing, delivery, revisions)
Market rate (what competitors actually charge)
Client lifetime value (referrals, repeat bookings)

I discovered that my most profitable clients weren't the highest-paying ones—they were the ones with clear requirements, reasonable revision limits, and upfront contracts.

I built a pricing calculator:

const calculatePrice = (eventType, duration, guestCount, location) => {
  const baseRate = eventTypeRates[eventType]; // e.g., wedding = $3500
  const durationMultiplier = 1 + (duration - 4) * 0.15; // +15% per hour
  const locationMultiplier = location === 'remote' ? 1.5 : 1; // travel cost
  const bulkDiscount = guestCount > 200 ? 0.95 : 1; // slight discount for large events

  return Math.round(baseRate * durationMultiplier * locationMultiplier * bulkDiscount);
};

This simple formula ensured pricing consistency and prevented undervaluation.

The Metrics That Matter

If there's one thing developers are good at, it's measurement. I applied the same rigor to the photography business:

Inquiry-to-booking rate: Should be >30%
Revision cycles: More than 2 = process failure
Days to delivery: Target <14 days post-event
Client satisfaction: NPS score (net promoter score)
Revenue per hour of active work: Hourly rate is meaningless; what matters is revenue divided by actual billable hours

When I started tracking these, I realized I was spending 60% of my time on non-billable work. After optimizing my systems, that dropped to 20%.

The Technical Stack (If You Want It)

In case you're curious, here's a minimal stack for running a creative services business:

Client management: Custom Node.js backend (or Airtable if you want no-code)
Scheduling: Google Calendar API with custom conflict detection
File management: S3 with automated tagging and organization
Gallery delivery: Static Next.js site generated per event
Payments: Stripe (with automation for deposits and final payments)
Analytics: Posthog for client behavior, custom dashboards for business metrics

I'm the founder of Candid Studios (candidstudios.net), where we apply these same principles to manage photography operations at scale. The platform handles everything I just described, purpose-built for creative service businesses.

Key Takeaways

Here's what I'd tell any developer considering a creative business:

Systems matter more than talent. Two photographers of equal skill will differ wildly in profitability based on operational efficiency.
Automate the repetitive. If you're doing manual data entry, file organization, or email templating, you're leaving money on the table. Build or buy tools to handle it.
Measure everything. You can't improve what you don't measure. Track inquiry-to-booking rates, delivery times, and profitability per client.
Pricing is a feature. Take time to understand your costs and value. Don't guess.
Your technical skills are a competitive advantage. Most creatives can't build their own systems. Use that.
Process scales, talent doesn't. A single photographer (you) has a ceiling. Systems allow you to eventually hire other photographers and scale without losing quality.

The best part? Building a creative business taught me more about product thinking, customer psychology, and operations than any tech job ever did. And my ability to code made the whole thing possible.

If you're a developer with creative interests, stop thinking of them as separate. They're complementary. Build systems around your craft, and you'll be surprised how far you can go.

I'm the founder of Candid Studios (candidstudios.net), where we've applied these lessons to help creative service businesses automate and scale.

DEV Community: Savage Solutions

A Hanging Dedup Fetch Killed Our Daily Blog for a Week

The Week Our Blog Went Silent

What the Pipeline Actually Does

The Actual Failure: EAI_AGAIN on Flaky Container DNS

The Fix: Promise.race With a Named Timeout

Why Fail-Closed Is the Right Call Here

What We Added to Monitoring

The Broader Pattern

Key Takeaways

We Were IndexNow-Pinging GitHub PRs Instead of Blog URLs (Here's How We Fixed It)

The Bug Nobody Notices Until Bing Returns a 403

What gitMdx's publishResult.url Actually Returns

The Second Problem: The Key File Was Never Hosted

The Fix, Step by Step

Why This Is Easy to Miss

The Rule That Prevents This

Key Takeaways

One Enum Mismatch Hid Every Blog Video for Weeks

The Bug That Looked Like a Design Decision

What HeyGen Sends vs. What We Expected

Mapping the Broken State Machine

The Fix: One Source of Truth for Status

Bulk-Updating the Existing Documents

Preventing Dead Players from Expired URLs

Why This Stayed Hidden So Long

The Broader Pattern

Key Takeaways

Never Ship a Blog Post Without a Featured Image Again

The Bug Nobody Noticed for Weeks

How the Pipeline Worked Before

The Fix: evaluatePublishGate

What Changed in the Payload Hook

The Async Queue Still Exists, But It Cannot Bypass the Gate

The Rule We Wrote Down

What We Would Do Differently

Key Takeaways

How We Killed Alert Fatigue Without Going Blind

The Problem Was Noise, Not Negligence

The Old Setup and Why It Failed

The Spool Architecture

The Routing Layer: Batch vs. Immediate

The Kill and Demote Lists

What Changed in Practice

Applying This to Your Stack

Key Takeaways

How to Optimize Content So ChatGPT and Perplexity Cite You (Not Just Rank You)

Why AI Engines Cite What They Cite

The Four-Part Structure That Gets Cited

The Canonical URL Is Not Optional

Platform Selection Matters for Indexing Speed

Entity Density: A Practical Checklist

What This Looks Like in Practice

Key Takeaways

A Weekly Cron Died Silently for 10 Weeks. Here Is What We Changed.

The Bug Nobody Saw

Why This Happens

The Two Things Every Scheduled Job Needs

How We Route Alerts

The "Zero Published" Alert Is the Specific Fix

What We Audit Now

Silence Is Not Success

Key Takeaways

How We Make Every Scheduled Job Safe to Re-Run

The Problem With Cron Jobs Nobody Talks About

What Idempotency Actually Means in Practice

1. Find-or-Create on a Stable Dedup Key

2. A 'Used' Ledger Collection

The Weekly Publisher: A Real Example

The Rule We Follow

What This Looks Like in a Real Stack

Key Takeaways

The True Cost of a Custom Website vs Templates in 2026

The True Cost of a Custom Website vs Templates in 2026: A Developer's Honest Breakdown

The Hidden Costs Nobody Talks About

Template-Based Site Costs

The Custom Build Reality Check

Performance: Template vs. Custom (2026 Benchmarks)

The Break-Even Point

When Should You Actually Use Each?

What gitMdx's `publishResult.url` Actually Returns

The Fix: `evaluatePublishGate`