Forem: edhiblemeer

I built reach for 14 days. Then realized I had nowhere for it to land.

edhiblemeer — Wed, 06 May 2026 16:22:51 +0000

The morning after I shipped my Build-in-Public post #6 (Stripe webhook silently failing for 5 days), I got a question that hit:

"PR is great. But how do I actually turn this into deals?"

Honest answer: I didn't have one.

In 14 days I'd built:

26 blog posts on the company landing page
A Zenn technical post (Japanese)
A dev.to technical post (English)
50+ URLs indexed in Google Search Console
Search clicks growing from 0 → 40

The PR was working. But "And then what?" had no answer.

The structural problem: no landing page for the leads

Picture the funnel for a reader of my Stripe webhook incident report:

They read the technical post on dev.to → reach
They click my profile to see who wrote it → bio
They think "interesting, who is this person and how do I hire them?" → no answer → bounce

My company landing page (tasteck.tech) is for buyers of the SaaS — store owners and individual operators in Japan's nightlife industry. Nothing there speaks to "I read your Stripe debugging post and want to hire you for a NestJS spot project."

PR reach × landing page quality = deals. If the second factor is zero, multiplying the first one harder doesn't help.

What I shipped in one day

A. Built `/work` in Next.js (~30 min)

A consulting page at tasteck.tech/work. Contents:

4 services, tiered by engagement size:
- 1-hour tech / industry consult: ¥5,000 ($33)
- Stripe / billing design review: from ¥30,000 ($200)
- NestJS / Next.js spot dev: from ¥100,000 ($670)
- Build-in-Public ghostwriting / ops: from ¥50,000 / month ($335)
10 concrete achievements, not vague claims:
- 8 years of running a niche-SaaS in production
- 1467× query speedup on a slow report endpoint
- Stripe incident: full repair in 4 hours
- Multi-feature release executed in a single day (April 15)
- EC2 migration with no downtime
- 14-day Build-in-Public campaign with measurable SEO lift
- Two products in beta concurrently
- Multilingual content rollout (JP + EN)
- 14-column CSV export for tax filing
- Full rebrand
English CTA for international readers (hourly $40)
FAQ: cross-industry OK / NDA / process / payment terms
Contact: mailto:info@tasteck.tech direct (no form yet)

☝️ The achievements section started at 4. A friend pointed out, "your past commits and blog posts are full of bigger wins than what you're claiming." That outside view doubled the credibility of the page. SaaS operators are too modest about themselves.

B. Wire up 6 channels in the same day (~15 min)

Just having the page isn't enough — readers don't go hunting. So I added a "I'm available, here's where" signal everywhere:

Header nav on tasteck.tech → "Consulting" link
Footer same
sitemap.xml (priority 0.85)
dev.to bio: website_url, summary, available_for, skills_languages, location — all rewritten in English
Zenn (Japanese tech platform) website URL → tasteck.tech/work
X bio: added "🛠 Consulting → tasteck.tech/work"
X pinned tweet: replaced "company intro" with "consulting available"

Six surfaces, one day.

C. Request GSC indexing (~1 min)

URL inspection → "Request indexing." Done.

Design decisions

Transparent pricing

Hiding numbers means people who can't afford you waste your time. Putting ¥5K / ¥30K / ¥100K / ¥50K-month up front filters in only the people who actually have the budget. Funnel quality > funnel volume.

Tiered services as a stairway

1-hour at ¥5K is a low-friction entry. Monthly retainer at ¥50K is the ceiling. The intent: someone might come in for the cheap consult, find it useful, then escalate to spot dev → ongoing retainer. Turn one-time encounters into multi-stage relationships.

Cross-industry / English explicitly OK

I run a vertical SaaS in Japan's nightlife industry. But my technical stack (Stripe / NestJS / Next.js / TypeORM / AWS) is fully transferable. So the FAQ explicitly says "non-industry projects welcome, English inquiries welcome." That single sentence dramatically expands the addressable market.

`mailto:` over Stripe Payment Link / Google Forms

For the first inquiries, lower friction wins. I want to read what people are asking before deciding whether structured intake is even useful. Once volume justifies it, I'll add a form.

Audience layers

Three concentric circles:

Layer	Source	Likely ask
Domestic SaaS founders / side-project devs	Zenn, X, landing blog	Stripe webhook bug fixes, NestJS spot work, 1-hour consults
International SaaS devs	dev.to, GitHub	NestJS / Next.js spot dev, Build-in-Public ghostwriting
Nightlife industry shops	Landing page TOP	Custom development on top of my SaaS, ops outsourcing

Confidence ranking: Layer 1 highest (warm Japanese audience), Layer 2 next (right after each English post), Layer 3 slowest-burn.

What I'm measuring (Day 15-21)

GA / GSC pageviews on /work
mailto: link click count
Actual inquiry email volume
Conversion to paid engagements + ARPU
Referrer breakdown

I'll publish raw numbers in Build-in-Public post #8 in two weeks.

Takeaway

The "right" order would have been: ship /work first, then drive PR at it. I did it backwards.

But there's a silver lining to the wrong order: the credibility section on /work is filled with specific, dated, verifiable achievements because the PR phase forced me to document them. A /work page launched on Day 1 with no track record would have been forgettable.

If you're a SaaS operator running PR and wondering where the deals are: spend half a day shipping a landing page for the leads. The ROI on subsequent PR changes the moment that page exists.

Original Japanese version: Build-in-Public 第 7 弾
Hire me: tasteck.tech/work — non-industry projects welcome, English OK
Previous post: Stripe webhook silently failing for 5 days

Stripe Webhook Was Silently Failing for 5 Days: The 4xx Retry Trap and the Beginning-of-Month Time Bomb

edhiblemeer — Wed, 06 May 2026 08:36:01 +0000

TL;DR

21 invoice.paid webhooks failed for 5 straight days in production.
We only noticed because Stripe sent a "we'll auto-disable this endpoint by 5/10" warning email.
Root cause: a DB integrity gap caused our handler to throw HttpException(BAD_REQUEST) 竊・Stripe treats 4xx as retry-eligible 竊・infinite retry loop.
Lesson: Stripe webhook 4xx is not "client error, give up." It's "please try again." DB lookup misses should be console.warn + 200 OK.
Bonus lesson: invoice.paid only fires on subscription cycle (once a month). Five days of silent failure went completely unnoticed.

I'm running tasteck, an industry-specific SaaS for the Japanese nightlife industry. This is a real incident report from production.

The wake-up call

One morning, an email from Stripe:

We've encountered an issue when sending an event to your webhook endpoint at https://api.tasteck.tech/.../payment/webhook

We've attempted to send 16 events since 2026-05-01 02:02:21 UTC, all failing.

Stripe will stop sending events to this endpoint by 2026-05-10 02:02:21 UTC.

If we didn't fix it before 5/10, the endpoint would be automatically disabled. Subscription invoice notifications would just stop. That's catastrophic for a billing-driven SaaS.

Triage: is the endpoint dead?

First, a sanity check with curl:

curl -X POST -H "Content-Type: application/json" \
  -d '{"type":"ping"}' \
  https://api.tasteck.tech/.../payment/webhook
# 竊・201 Created

The endpoint is alive. Only specific events from Stripe are failing. Different problem.

Finding the actual error in PM2 logs

ssh prod "grep 'subscription' /home/ec2-user/.pm2/logs/api-error.log | tail"

# 竊・HttpException: Subscription item not found.  ﾃ・0+

The handler code (NestJS + TypeORM):

const stripeSubscriptionItem = await em
  .getRepository(StripeSubscriptionItem)
  .where("stripe_id = :stripeId", { stripeId: subscriptionId })
  .getOne();

if (!stripeSubscriptionItem) {
  throw new HttpException(
    "Subscription item not found.",
    HttpStatus.BAD_REQUEST  // 竊・this is the problem
  );
}

Trap #1: Stripe webhook 4xx IS retry-eligible

This is where REST-API instincts betray you.

A normal API: "client gave us bad data 竊・return 4xx 竊・client should fix it 竊・don't retry."

But Stripe webhooks are not a normal API. From their docs:

Stripe considers any HTTP response code in the range 200-299 as a successful delivery. Anything else, including 4xx and 5xx, is treated as a failure and Stripe will retry.

So our chain was:

DB has integrity gap for one customer
Handler can't find the record
Handler throws HttpException(400)
Stripe sees 4xx 竊・schedules retry (exponential backoff)
Retry hits the same DB gap 竊・another 4xx 竊・another retry
After 3 days, Stripe gives up 竊・emits "we'll auto-disable in 7 days" email
Endpoint gets auto-disabled. Game over.

The fix is structural: webhook handlers should almost never return 4xx for application-level "data not found" cases. Log a warning, return 200, move on. The 4xx semantic doesn't fit the protocol.

Trap #2: `invoice.paid` only fires on the 1st of the month

Why didn't we notice for 5 days?

Because invoice.paid is a subscription cycle event. For a monthly subscription, it fires once a month, on renewal day. So:

Day 1 of the month: 20 customers renew 竊・1 of them is broken 竊・1 failure that day
Day 2-3: Stripe retries that 1 failure several times 竊・spikes our error log briefly
Day 4-30: nothing happens. Logs are silent. Sentry alerts based on rolling-7-day baselines see no change.

This is a class of bugs I'd call calendar-aligned bugs: they only fire on a specific day of the month, hide inside normal noise, and Sentry's "anomaly detection" can't see them because the baseline includes the spike too.

For SaaS founders, the takeaway:

Daily error count alerts won't catch month-aligned failures.
You need per-event-type success rate alerts that fire on absolute thresholds, not anomaly-based ones.

The real cause: one customer with no `subscription_items` row

I queried prod RDS to figure out which customer was hosed:

SELECT * FROM company_groups WHERE customer_id = 'cus_xxx';
-- 竊・1 row (plan='starter')

SELECT * FROM stripe_subscriptions WHERE company_group_id = 96;
-- 竊・2 rows (1 active, 1 deleted)

SELECT * FROM stripe_subscription_items
  WHERE stripe_subscription_id IN (175, 176);
-- 竊・0 rows 笞・・```
{% endraw %}


Zero rows. The {% raw %}`stripe_subscription_items`{% endraw %} table just had no record for this customer. Probably a missed INSERT during a data migration, or a race during initial subscription creation. We don't know exactly when.

## Fix A: data repair (root cause)

Look up the actual subscription item from the Stripe Dashboard:

- subscription item ID: {% raw %}`si_xxx`
- price: `price_xxx` (ﾂ･15,000 / month)
- 竊・matches DB plan_type `starter`

Insert the missing row:



```sql
INSERT INTO stripe_subscription_items
  (stripe_subscription_id, stripe_id, plan_type, is_annual)
VALUES
  (176, 'sub_xxx', 'starter', 0);

Click "Resend" on a failed event in Stripe Dashboard 竊・30 seconds later: 201 OK 笨・

Fix B: handler robustness (preventive)

Data repair is a per-customer band-aid. To prevent future "data integrity gap 竊・retry storm" cases, change the handler:

// Before (3 places in customer.subscription.deleted and invoice.paid)
if (!stripeSubscriptionItem) {
  throw new HttpException(
    "Subscription item not found.",
    HttpStatus.BAD_REQUEST
  );
}

// After
if (!stripeSubscriptionItem) {
  console.warn(
    `[webhook] StripeSubscriptionItem not found for sub_id=${stripeSub.id} (stripe_id=${subscriptionId}), skipping plan update`
  );
  break;  // exits switch, returns 200
}

3 throw sites in two case blocks (customer.subscription.deleted and invoice.paid), all replaced with warn + break. Stripe sees 200, stops retrying. The plan-update side effect is skipped, which is fine because the customer's plan was already correct (we just couldn't verify it via DB).

Verification

After Fix A, manually triggered retry from Stripe Dashboard:

2026-05-05T05:27:01.500Z POST /payment/webhook 201 2 Stripe/1.0

Next day, Stripe's natural retry of the remaining 20 failed events:

2026-05-06T04:15:28.736Z POST /payment/webhook 201 2 Stripe/1.0
2026-05-06T04:17:25.577Z POST /payment/webhook 201 2 Stripe/1.0

All clean. 5/10 auto-disable risk fully averted.

Checklist for your own webhook handlers

Borrow this if it's useful:

[ ] Are you throwing 4xx for any DB lookup miss in your webhook? 竊・consider warn + 200 instead
[ ] Do you have a default: case that returns 200 for unknown event types?
[ ] Are you alerting on per-event-type success rate, not just total error count? (Catches month-aligned failures)
[ ] Is there a periodic batch checking referential integrity between your subscription / customer / item tables?
[ ] Are your webhook signature verification failures returning 4xx (they should 窶・that's the correct use of 4xx, since Stripe needs to know its retry won't help)?

The meta-lesson

The bug here was small (a missing DB row). The damage was disproportionate because:

The protocol's "4xx = retry" semantic doesn't match REST intuition
Calendar-aligned events hide inside normal logs
Sentry-style anomaly detection can't see month-1 spikes

Webhook integrations are deceptively easy at first and quietly break later. Worth a half-hour audit of yours.

Posting these as I find them. I run tasteck, a vertical SaaS, and I've been writing about the operational side in Build-in-Public posts (Japanese). This is the first one I've written in English 窶・if you want more in this style, say so in the comments.