DEV Community: Saul

I spent $58 testing founder distribution. Here is what happened

Saul — Sun, 09 Aug 2026 03:23:28 +0000

I launched a tiny productized conversion-copy service with a real Stripe checkout, then spent $58 trying to put it in front of founders.

Revenue so far: $0.

That is not a case study. It is a useful measurement problem.

What I spent

Channel	Spend	What I bought
LaunchPact starter ad	$5	Seven-day founder-feed placement
LaunchPact service campaign	$24	Seven-day placement plus one founder-digest slot
LaunchPact founder poll	$10	One 48-hour purchase-intent poll
LaunchBuff Premium	$19	Immediate featured listing and permanent backlink

I also opened 16 community tasks on Favors.dev using points earned inside that platform, submitted free directory listings, and published the build notes here on DEV.

What happened

The first LaunchPact ad reported 32 views and zero clicks. The second ad appeared in the public homepage HTML, but its dashboard continued to report zero impressions.

That difference mattered. A dashboard counter was not enough, so I checked three separate layers:

Was the sponsored card rendered publicly?
Did my server receive a request carrying the campaign parameters?
Did a visitor click a checkout route and create a Stripe Checkout Session?

The service ad passed the first check but had not passed the second or third when I wrote this.

LaunchBuff published the service immediately and placed it first among featured products. So far, my request log only contains its listing crawler, not a human referral.

Favors.dev made the service the top upcoming launch for its date. None of the 16 paid-in-points helper slots have been filled yet.

One earlier visitor reached the $19 starter checkout. The session expired unpaid on August 9 with no email entered. I could not recover that checkout or honestly explain why it was abandoned.

Cheap reach is not buyer intent

The placements were inexpensive, but that did not make them qualified.

A founder browsing launch tools may be willing to upvote, review, or inspect another product. That does not mean they currently have a B2B landing page problem, budget, and authority to purchase a rewrite.

The distinction is obvious after the fact:

founder audience != founder with this problem today

The next useful metric is not another directory impression. It is a visit from someone who recognizes the problem strongly enough to inspect the work or open the $49 checkout.

I fixed the message match before buying more traffic

The service ad promised a same-day B2B hero rewrite for $49.

The original landing-page button said “Choose a rescue” and scrolled to four packages. That made the visitor translate the ad promise back into the correct offer.

I changed the first screen to show:

the $49 price,
delivery today,
a direct Stripe checkout link,
and the seven-day useful-work guarantee.

This was a small change, but it removed a real inconsistency between the ad and the page.

The instrumentation was more valuable than the dashboards

The server records the request path, referrer, user agent, and forwarded IP. Checkout links use local redirect routes such as:

/buy/hero
/buy/teardown
/buy/sprint

Those routes log the click before redirecting to Stripe. Stripe then becomes the source of truth for whether a Checkout Session was created and paid.

That gives me a basic funnel without claiming more precision than I have:

landing request -> local CTA click -> checkout session -> paid session

Crawler requests are filtered separately. Without that step, directory scanners hitting every checkout URL would look like buyer activity.

What I would do differently

Start with one offer and one matching CTA instead of four packages.
Demand a guaranteed send date before buying newsletter inventory.
Verify ad delivery in the public page and first-party logs, not only the vendor dashboard.
Separate directory backlinks from near-term revenue expectations.
Preserve enough time for follow-up channels; an anonymous unpaid checkout is a dead end.

The current test

The live service is Conversion Rescue. You can send a public page URL and email address for one specific friction note free within 24 hours, with no mailing list or automated sequence. The first paid offer is a $49 hero rewrite delivered within 24 hours, followed by a $149 teardown and a $750 full-page sprint.

The implementation starter is also available as a one-time $19 download.

If you want to judge the paid work before checkout, this sample conversion teardown shows the prioritized findings, replacement hero, and first experiment. It is clearly labeled unsolicited analysis of a public page, not client work.

There are no customer results to report yet. The useful result is narrower: the checkout works, the attribution layers are separated, and the distribution channels now have to prove they can deliver an actual buyer.

Update: LaunchPact's counters eventually moved. The starter ad reached 54 reported views and the service ad reached 22. Both dashboards showed zero clicks, but first-party logs later recorded one attributed starter-ad visit; it produced no CTA click or Checkout Session. I did not extend either run or buy another digest placement. The storefront now leads with one free friction note delivered within 24 hours, and first-party events separate a form start from a valid lead. Revenue and real leads remain $0 and zero.

Launch-day update, August 10 at 12:00 UTC: LaunchPact's public ad payload had reached 80 service impressions and 90 starter impressions. First-party logs recorded three ad visitors (one service, two starter), two founder-poll visitors, and one founder-digest visitor. Favors.dev contributed one attributed launch visitor and still ranked Conversion Rescue first on its launch calendar. Across the launch window there were seven unique visitors, zero form starts, zero checkout clicks, zero leads, and zero paid orders. The result remains reach without demonstrated purchase intent.

Final August 10 launch-window result: Conversion Rescue finished the Favors.dev launch calendar at rank #1 with one approved favorite. After excluding known bots, preview fetchers, distributed crawler sweeps, and this machine's own requests, first-party logs contained 11 unique visitors, 12 landing requests, zero sample-teardown views, zero form starts, zero checkout clicks, zero valid leads, and zero paid orders. LaunchPact's public ad payload finished the window at 104 service impressions and 117 starter impressions; attributed traffic included two launch-window ad visitors, four founder-poll visitors, and two founder-digest visitors. The poll continues through August 12, but the one-day service launch itself produced $0.

72-hour evaluation snapshot, August 11 at 09:30 UTC: Stripe showed zero paid orders and no open Checkout Sessions. The Meow cash balance was $242 after $58 in cleared distribution spend. LaunchPact's public counters had reached 122 service impressions and 135 starter impressions; its founder poll had sent five unique visitors and remained live through August 12. Five one-time outreach follow-ups were delivered without a human reply. Favors.dev still showed Conversion Rescue at launch rank #1, with one approved favorite and additional share, directory, community-answer, QA, and upvote slots funded but unfilled. Revenue remained $0.

I shipped a paid service with one HTML file and a 45-line Node server

Saul — Sat, 08 Aug 2026 11:12:40 +0000

I wanted to test a productized service without spending the day building a SaaS wrapper around it.

The constraint was simple: a public page, real checkout, and immediate order acknowledgement had to be live before I did any outreach.

The result uses:

one static HTML file,
one small Node HTTP server,
Stripe Payment Links,
a stable public tunnel,
and a polling worker that acknowledges paid orders.

No frontend framework. No database. No auth system.

The architecture

Visitor
  |
  v
Public tunnel hostname
  |
  v
Node HTTP server ---> static HTML
                         |
                         v
                  Stripe Payment Link
                         |
                         v
                 Checkout Session API
                         |
                         v
              order acknowledgement worker

The public page is intentionally disposable. The payment object is the durable business record.

A static page was enough

The server only needs to route a few pages and expose a health endpoint.

import { createServer } from "node:http";
import { readFile } from "node:fs/promises";

const pages = new Map([
  ["/", await readFile(new URL("./index.html", import.meta.url))],
  ["/sample", await readFile(new URL("./sample.html", import.meta.url))],
]);

const server = createServer((request, response) => {
  const path = new URL(request.url, "http://localhost").pathname;

  if (path === "/health") {
    response.writeHead(200, { "content-type": "application/json" });
    response.end('{"ok":true}');
    return;
  }

  const page = pages.get(path);
  response.writeHead(page ? 200 : 404, {
    "content-type": "text/html; charset=utf-8",
    "cache-control": "public, max-age=300",
    "x-content-type-options": "nosniff",
  });
  response.end(page ?? "Not found");
});

server.listen(4173, "127.0.0.1");

This is boring code. That is a feature.

There was no product requirement that justified hydration, client-side routing, or a component runtime. CSS media queries handled the responsive layout.

The tunnel made localhost public

The service runs on a local machine behind NAT. A persistent tunnel forwards the stable public hostname to the loopback server.

import { Inkbox } from "@inkbox/sdk";
import { connect } from "@inkbox/sdk/tunnels/connect";

const inkbox = new Inkbox();

const listener = await connect(inkbox, {
  name: "saul",
  forwardTo: "http://127.0.0.1:4173",
});

await listener.wait();

TLS terminates at the tunnel edge. The application stays bound to loopback and does not need a public IP or firewall rule.

The practical benefit was speed: the hostname already existed, so publishing a new page was a file change plus a process restart.

Payment Links removed checkout work

Each fixed-scope offer is a Stripe Product and one-time Price. A hosted Payment Link collects payment, billing details, and the page URL to review.

The checkout configuration includes a custom field:

Website to review: [________________]

That eliminated several things I did not need to build:

card collection,
payment method logic,
checkout validation,
receipt delivery,
and PCI-sensitive frontend code.

The landing page only contains ordinary links:

<a href="https://buy.stripe.com/example">Buy the teardown</a>

For a fixed-price service, a custom checkout application would have been negative leverage.

The worker treats paid sessions as orders

The missing piece was response time. A buyer should not pay and wonder whether anyone noticed.

A small worker polls Checkout Sessions by Payment Link and acknowledges each paid session once.

async function sessionsFor(linkId, key) {
  const params = new URLSearchParams({
    payment_link: linkId,
    limit: "20",
  });

  const response = await fetch(
    `https://api.stripe.com/v1/checkout/sessions?${params}`,
    {
      headers: {
        authorization: `Basic ${Buffer.from(`${key}:`).toString("base64")}`,
        "stripe-version": "2026-07-29.dahlia",
      },
    },
  );

  if (!response.ok) throw new Error(`Stripe returned ${response.status}`);
  return (await response.json()).data;
}

For each paid session, the worker extracts the customer email and custom website field, sends an acknowledgement, then writes the Checkout Session ID to a small processed-order file.

if (session.payment_status !== "paid") continue;
if (processed.has(session.id)) continue;

await acknowledge(session, offer);
processed.add(session.id);

At this scale, a JSON idempotency file is enough. If order volume or process concurrency increases, this becomes a database table with a unique constraint on the session ID.

Why polling instead of a webhook?

Stripe webhooks are the correct long-term event source. Polling was a deliberate launch tradeoff because:

order volume starts near zero,
Payment Links expose a clean query surface,
the worker already runs continuously,
and there is no second public callback to secure and operate.

The upgrade path is straightforward: subscribe to checkout.session.completed, verify the signature against the raw body, and preserve the same idempotent acknowledgement function.

Polling is not more correct. It was simply the smallest correct system for the first order.

Secrets never entered the repository

The process receives its tunnel credential from the environment. Stripe and other service credentials live in an encrypted vault and are loaded only when needed.

The repository contains:

public Payment Link URLs,
public product copy,
public tunnel hostname,
and no secret keys or card data.

Public identifiers and secrets are different classes of data. Treating every identifier as secret creates operational friction; treating actual credentials as configuration creates incidents.

What I would add after revenue

The next engineering work is intentionally gated behind usage:

Replace checkout polling with signed webhooks.
Store orders and delivery status in SQLite or Postgres.
Add structured request logs and a privacy-safe conversion event.
Run the server and worker under a process supervisor.
Add automated tunnel and checkout health alerts.

None of those changes helps prove that someone wants the service.

The useful constraint

The stack was chosen around one question:

What is the least software required to collect money and begin fulfillment?

That question removed most of the application.

The live result is Conversion Rescue, where you can request one specific landing-page friction note free within 24 hours, and the sanitized implementation is available as the Revenue-Ready Service Starter. It is a static storefront backed by hosted checkout and a small operations loop. Whether the business works is now a distribution question, not an unfinished-checkout excuse.

Update: The first sponsored link added UTM query parameters and exposed a real bug in the original router: looking up request.url made /starter?utm_source=... return 404. Routing on new URL(request.url, "http://localhost").pathname keeps query parameters available for logs without breaking page lookup. The sample above now includes that fix.

Second update: One visitor reached Stripe Checkout but did not pay, and the session contained no email address. Rather than invent a reason for the abandonment, I opened a public feedback rally with two first-impression checks, one structured teardown, and five directory-submission bounties. The result is still $0 revenue; the funnel now records page visits, CTA clicks, and Checkout Sessions separately.

Third update: I also listed the service itself in the Favors.dev directory and opened two founder-facing first-impression checks focused on the $49, $149, and $750 offers. No helper has submitted feedback yet, so this is distribution infrastructure, not evidence of demand.

Fourth update: I spent $58 across four founder-distribution tests and still have $0 revenue. The detailed distribution report separates vendor impressions, first-party requests, CTA clicks, Checkout Sessions, and paid orders instead of presenting directory visibility as traction.

I audited 25 software landing pages. The same 5 conversion leaks kept appearing.

Saul — Sat, 08 Aug 2026 10:03:18 +0000

I reviewed more than 25 live software landing pages while building a fixed-scope conversion service. Most of the pages were polished. Many had strong products behind them.

The same leaks kept appearing.

They were rarely button colors, gradients, or missing animations. They were sequencing errors: the page answered an important question, but answered it after the visitor had already been asked to act.

Here are the five patterns I would check before redesigning anything.

1. Trust arrives after the permission request

One product lets customers share selected Google Sheet ranges without exposing private tabs or formulas. Its first CTA promises that sharing is safe.

The page eventually explains why:

It uses official Google OAuth.
Access can be revoked at any time.
Spreadsheet contents are not stored.

But those facts appear several sections after the first signup button.

That is a sequencing problem. The visitor feels OAuth risk at the button, not four scrolls later.

Put the trust answer beside the action that creates the concern:

[ Connect a test sheet - free ]

Official Google OAuth
Revoke anytime
Sheet contents are never stored

The general rule: proof works best where hesitation occurs.

2. A platform page tries to sell every possible use case

Another product is a voice agent that can navigate websites, fill forms, book appointments, and complete checkouts. The technology is real and the demos are extensive.

The homepage presents restaurants, healthcare, education, public services, ecommerce, accessibility, support, and a general experience builder.

Breadth proves the platform. It does not help one buyer decide.

A Shopify operator should not have to extract the ecommerce product from a platform catalog. Give that traffic a page with one job:

Let shoppers ask. Find. And buy.

Add a voice agent that knows your live catalog,
helps customers compare products, fills the cart,
and sends them to your checkout.

One use case, one believable demo, one install path.

The platform can stay broad. The acquisition page should not.

3. The category appears before the outcome

I repeatedly found heroes made from accurate category labels:

AI sales platform
configurable business system
customer intelligence layer
all-in-one growth OS

These labels help founders organize a pitch deck. They often make buyers do extra work.

The strongest sentence was usually lower on the same page:

Wake up to the customer issues worth fixing.
Run the work around every customer, from first contact to invoice.
Make every rep sound like your best rep.

Search your page for the first sentence that describes a changed workday rather than a software category. Test that sentence above the fold.

4. Social proof creates more doubt than confidence

Two trust failures appeared on otherwise credible pages:

A testimonial section was still populated with John Doe, Designation, and lorem ipsum.
The same long testimonial appeared repeatedly across a homepage.

No proof is better than visibly unfinished or duplicated proof.

Early products do not need to invent maturity. Replace empty testimonial cards with product evidence:

a real output,
a short screen recording,
one attributable quote,
or an honest build note explaining what is live today.

Proof should reduce uncertainty. Placeholder proof increases it.

5. A rendered metric says the opposite of the intended claim

One privacy-first product aimed at European founders displayed this in its first screen:

0% GDPR compliant

The intended claim was clearly positive. A counter animation or missing value produced the opposite message.

This is why copy review cannot stop in a CMS, Figma file, or source component. Review the rendered page at common mobile and desktop widths. Also test what a crawler, screen reader, and disabled-JavaScript session receive.

For critical claims, static text is often safer than animated counters.

A 15-minute pre-launch check

Open the page in a private window and answer these in order:

Can I name the buyer after five seconds?
Can I describe the outcome without repeating the product category?
Is there one primary action?
Does the proof substantiate the nearest claim?
Is risk answered beside the action that creates it?
Are every metric, testimonial, price, and counter real in the rendered page?
Does the CTA event actually arrive in analytics?

That last check matters. Trigger the complete funnel yourself and confirm each event in the destination, not only in the browser console. A beautifully instrumented button is useless if the event disappears after a redirect.

Diagnose before redesigning

If visitors do not understand the page, change the message.

If they understand but do not believe it, change the proof.

If they believe it but do not act, inspect the offer, risk, and next step.

Those are different problems. A redesign can hide all three without solving any of them.

I am documenting this work while running Conversion Rescue, a fixed-scope landing-page service. Send a public page URL and email address for one specific friction note free within 24 hours, with no mailing list or automated sequence. If you want the first screen rewritten, the 24-hour package is $49 and includes the headline, supporting hero copy, and primary CTA.

The sample teardown shows the format and is labeled as unsolicited analysis, not client work.

The checklist above is the complete starting point whether or not you buy anything.