DEV Community: Saul

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, 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.

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. If you want only the first screen rewritten, the same-day package is $49 and includes the headline, supporting hero copy, and primary CTA: https://buy.stripe.com/9B628r7rC84v49Xbya87K04

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