phabdev/docsBack to starter kit

Selling and delivering the kit

The product is downloadable source code. The static site can present the offer, send users to a configured hosted checkout and route them to a configured waitlist. It cannot verify payments or privately deliver Pro by itself. The sample Stripe module in Pro is a separate SaaS billing example.

Public routes

The product landing is /starter-kits/spring-boot-angular-saas-starter-kit. Dedicated pricing, waitlist, download and thank-you pages complete the public journey; use the routes documented in apps/landing/README.md. The free ZIP is public under /downloads/phabdev-saas-starter-lite.zip. Pro must never be placed in a static site's public directory.

Simplest initial delivery: hosted digital-product checkout

Choose a provider that can host a checkout and privately deliver a purchased file. Create one digital product, upload the reviewed Pro ZIP from .artifacts/packages/, set the proposed early-access price and check tax/currency display. Configure purchaser receipt, support, terms and refund information in that provider. Copy only the public HTTPS checkout link to the landing configuration.

The repository does not assume an existing Stripe, Lemon Squeezy, Gumroad or Polar account. Provider availability, business verification, fees and legal/tax responsibilities must be checked in the selected account. No account has been connected or test payment completed by generating these files.

Configure the landing's documented sales-ready switch and support/privacy/refund/license URLs only after the corresponding operations exist. A successful build validates configuration shape, not provider behavior. A thank-you URL or query parameter is never payment proof; the static thank-you page must direct purchasers to their receipt/delivery channel without inventing an order status.

Stripe Payment Links can host checkout, but delivery of this private ZIP needs a separate server-side workflow. Stripe Payment Links documentation.

  1. Create a test product/price and Payment Link for the one-time starter purchase, separate from Pro's subscription example.
  2. Create a fulfillment endpoint in your chosen server environment; keep keys outside the static build. Verify Stripe signatures on the raw body using the endpoint secret.
  3. On confirmed successful payment, record a durable order keyed by provider event/order ID. Treat delayed payment methods correctly; do not fulfill only because checkout redirected.
  4. Grant access to a private object-store artifact or authenticated download. Use a short-lived signed URL and provide controlled reissue for legitimate purchasers. Do not email the source as an unrestricted public URL.
  5. Process repeated delivery idempotently and record email delivery failures for retry. Handle refund/access policy according to the reviewed terms.
  6. Test completed, delayed, failed, duplicate and refunded payment cases before setting the landing sales-ready flag.

This fulfillment service is an integration boundary requiring provider/account choices, not an implemented service in this static starter repository. A hosted digital-product provider can own that boundary instead. Stripe fulfillment guidance.

Waitlist

Configure a hosted signup page with purpose-specific consent and a privacy notice. The landing should link to it only when those URLs are present; otherwise show the unavailable state. Confirm a real test lead reaches the provider, consent is recorded, confirmation works and unsubscribe/deletion can be honored. Do not collect emails into localStorage or show a fake successful signup.

Release and handoff procedure

  1. Review QA_REPORT.md, license draft and open launch blockers. Select a release candidate commit and update changelog.
  2. Run both editions' checks and python scripts/package.py. Inspect the archives for secrets, verify checksums and test from extracted directories.
  3. Upload Lite publicly and Pro privately. Record the artifact hash/version on the order-delivery configuration.
  4. Complete one sandbox purchase and verify the exact downloaded Pro archive. Verify a real waitlist submission and free download independently.
  5. Check responsive pages, links, metadata, privacy/refund/support access and any analytics consent behavior.
  6. Publish only after the owner has resolved account/legal/operational requirements. Create a Git Flow release branch and tag when releasing; a feature PR alone is not a production release.

There are no fabricated purchase confirmations, invented order IDs or working-payment claims in the default configuration.

Source: docs/starter-kit/sales-and-delivery.md · Included with the starter kit.