DEV Community: Chen777

I built a 27-point trust scanner for product pages after launching products nobody bought

Chen777 — Thu, 09 Jul 2026 05:50:06 +0000

I launched 30 products. Nobody bought. So I turned everything I learned about why strangers don't trust product pages into an automated 27-point check.

That sentence sounds a little dramatic, but it is the honest origin story.

I had source-code kits, code labs, product pages and checkout links. What I did not have was evidence that a stranger would trust the page enough to buy.

So I built ProofScan.

What ProofScan does

Paste a Gumroad, Lemon Squeezy, Payhip or independent landing page URL.

It reads the public page content and metadata, then checks:

OG image;
title specificity;
price visibility;
screenshot count;
demo or preview;
license terms;
refund policy;
support boundary;
seller identity;
HTTPS and mobile viewport;
CTA clarity;
file / deliverable explanation;
FAQ;
social proof or build-log substitute;
contact path;
image alt text;
and other buyer-trust signals.

It then scores the page across five buyer questions:

Can a stranger explain what this is in 10 seconds?
Why should they trust you?
Why buy now?
What exactly do they get?
What feels most scammy or risky?

Dogfooding it on my own pages

The first dogfood scans were humbling:

Page	Score	Main issue
PanelDocket	92	fewer than 3 meaningful screenshots; no visible refund policy
WrenchLine	95	no visible refund policy
Audio DSP Blueprint Code Lab	57	checkout/trust gap, screenshots and preview clarity

I liked this because the tool did not flatter me. It found boring trust problems.

Boring trust problems are the ones that stop strangers.

What it is not

Not code review. Not a sales guarantee. It finds the trust gaps a stranger sees in your listing's first 60 seconds.

It will not tell you if your product should exist. It will not make traffic appear. It will not certify security or compliance.

But if you already have a page and nobody buys, it can help answer one narrow question:

Is the page giving a stranger enough proof to trust checkout?

I launched the public version here:

https://www.inresonancewell.com/proofscan?utm_source=dev&utm_medium=community&utm_campaign=proofscan-launch-w1

The free scan gives a score and the top 3 fixes. The paid report unlocks the full 27-point breakdown, export and rewritten first-screen copy.

If you sell templates, code labs, boilerplates or small software products, I would love to know: what product-page detail makes you leave immediately?

If your digital product launched to silence, what was actually wrong?

Chen777 — Tue, 07 Jul 2026 10:48:32 +0000

I keep noticing a very specific indie-maker problem.

Someone builds a digital product, packages it properly, puts it on Gumroad / Lemon Squeezy / Payhip / Whop / a self-hosted checkout page, posts about it once or twice, and then...

nothing.

No sales.
No useful feedback.
No clear reason why.

The hard part is that "no sales" can mean several completely different things:

the product is too generic;
the buyer is unclear;
the page does not explain the outcome;
the screenshots, demo, or docs are missing;
the proof/trust layer is too weak;
the price feels wrong for the promise;
the launch channel is wrong;
the product is okay, but the first audience was too cold;
the product should be a service first, not a downloadable product yet.

I am trying to turn this into a practical launch-triage framework for small digital products.

Not a "guaranteed sales" thing.
Not a motivation thread.
More like:

If a stranger lands on this product page, what is unclear before they decide whether to buy?

If you have launched a digital product that got little or no traction:

What did you later realize was actually wrong?

The more boring and specific, the better.

What should a solo founder have ready before setting up Lemon Squeezy, Paddle, Polar, or Stripe?

Chen777 — Tue, 07 Jul 2026 10:03:11 +0000

I’m working through payment setup for a few small digital products, and I’m realizing the hardest part is not always the API integration.

Sometimes the harder part is making the business, product, website, and fulfillment story clear enough for review.

For example, before applying to a payment processor or merchant-of-record platform, you may need to think through:

what exactly the product is
how customers receive it after purchase
whether it is a SaaS, digital download, template, course, service, or something mixed
whether the pricing page is clear
whether the refund/support policy is clear
whether the website looks real enough
whether there are screenshots, a demo, docs, or a working product path
whether the support email and company details are consistent

I’m curious how other solo founders handled this.

If you were approved by Lemon Squeezy, Paddle, Polar, Dodo, Stripe, Gumroad, or a similar platform:

What did you actually have ready before applying?

And if you were rejected or delayed:

What was missing?

I’m not looking for hacks, shortcuts, or “how to bypass review” advice. I mean the opposite: what should a legitimate indie founder prepare so the product and business are easier to understand?

I’m especially curious about:

pricing page
terms / privacy / refund policy
product demo or screenshots
business email / company details
what your website needed to show
mistakes that caused rejection or back-and-forth
whether AI/SaaS/digital-product businesses are harder to explain now

I’m collecting notes from my own setup process and may turn them into a small launch-readiness checklist for indie builders if there is enough interest.

Would love to hear what actually mattered in your experience.

Six tiny Python examples that made audio DSP less abstract

Chen777 — Tue, 07 Jul 2026 08:45:32 +0000

When I first learned audio signal processing, the hard part was not memorizing terms like FFT, STFT or MFCC.

The hard part was seeing what each step actually produced.

A lot of audio tutorials jump quickly into a library call, a polished plot, or a model. That is useful later, but it can hide the basic shape of the signal-processing pipeline.

So I rebuilt an old audio DSP learning pack into something much smaller:

generate a waveform;
inspect frequency content with an FFT-style spectrum;
create a small STFT spectrogram;
compute mel / MFCC-style features;
compare spectral centroid, bandwidth and rolloff;
use those features in a tiny nearest-centroid classifier.

The goal is not to build production DSP software.

The goal is to make the intermediate outputs visible.

The learning habit I wanted

For beginners, I think one habit matters more than the specific library:

generate an output file you can inspect after each step.

That might be a WAV file, a CSV table, an SVG plot, or a small text result.

If every step produces something visible, then terms like "spectrogram" or "spectral centroid" stop being abstract labels. You can look at the artifact and ask:

what changed in the signal?
what did the transform keep?
what did it discard?
what parameter changed the output?
what would break if the input were noisier?

That is slower than importing a powerful library and jumping to the final plot.

But for learning, slower can be better.

Why I avoided third-party packages in this small lab

This was a deliberate constraint.

Libraries like librosa and SciPy are excellent. I am not arguing against them.

But if the goal is to understand the pipeline, dependency-light examples force the code to stay close to the idea:

loops are visible;
bins are visible;
windows are visible;
feature summaries are visible;
the toy classifier is obviously a toy.

That last point matters. A small classifier demo should not pretend to be a serious audio ML system.

In my rebuilt version, the classifier is only there to connect feature extraction with a downstream decision. It is not there to claim production accuracy.

The six-example path

The learning path looks like this:

Waveform basics

Generate and normalize a small audio signal, then write a WAV, CSV and SVG preview.
FFT spectrum

Inspect frequency peaks instead of only looking at the waveform.
STFT spectrogram

See the time-frequency tradeoff on a small generated chirp.
Mel / MFCC-style features

Build a simplified learning version of perceptual feature extraction.
Spectral summaries

Compare centroid, bandwidth and rolloff across small synthetic samples.
Tiny audio classifier

Use extracted features in a nearest-centroid classifier and inspect the predictions.

Again: this is not a replacement for a real DSP stack.

It is a small bridge between theory and inspectable code.

What I packaged

I turned this into a compact paid code lab:

six runnable Python examples;
six supplementary PDF guidebooks;
generated output files;
setup notes;
included-files notes;
explicit limitations.

The examples are intentionally small. They are for people who want FFT, STFT, MFCC-style features and simple spectral summaries to feel less mysterious before moving into larger libraries or models.

If that sounds useful, the Gumroad page is here:

https://chen77studio.gumroad.com/l/audio-dsp-blueprint-code-lab

Price: USD 19.

What I am testing with this launch is simple: whether a small, honest, runnable code lab is more useful to learners than another broad "complete audio ML course" promise.

What Makes a Source-Code Starter Kit Worth Buying?

Chen777 — Fri, 03 Jul 2026 12:51:11 +0000

I have been turning old code projects into sellable source-code products.

The hard part is not changing the cover image.

It is not renaming the ZIP.

It is deciding whether the project deserves to be sold at all.

A lot of old apps are useful to the person who built them. Far fewer are useful
to a stranger who has never seen the repo, never heard the backstory, and only
wants to know one thing:

Will this save me time, or will it become another folder I regret buying?

Here is the checklist I now use before treating a source-code project as a
starter kit.

1. The buyer must understand the workflow

"Full-stack dashboard" is not enough.

A buyer should immediately understand the workflow the project helps with.

For example:

a review and scoring portal;
a maintenance and work-order dashboard;
an email-template governance tool;
a runnable technical code lab.

The more generic the product sounds, the harder it is to buy.

I now try to answer this in one sentence:

This kit helps [specific buyer] start from a working foundation for [specific
workflow].

If I cannot fill that sentence honestly, the project is not ready.

2. A stranger must be able to run it

"It runs on my machine" is not a product standard.

A buyer needs a path from download to working state.

That usually means:

setup instructions;
environment notes;
seeded demo data;
demo accounts or fixtures;
expected local startup behavior;
known limitations;
a simple smoke-test checklist.

The goal is not perfection. The goal is that a competent developer should not
have to reverse-engineer the project before deciding whether it is useful.

3. The product needs proof, not adjectives

Marketing adjectives are cheap:

production-ready;
powerful;
scalable;
enterprise-grade;
battle-tested.

Most of those words create more risk than trust if they are not backed by
evidence.

Better proof looks boring:

screenshots;
a short demo video;
a verified release ZIP;
install notes;
architecture notes;
included / not-included boundaries;
a changelog;
clear licensing terms.

For a source-code product, "boring proof" is often more persuasive than a
beautiful landing page.

4. The boundary matters as much as the feature list

One mistake I see in starter kits is pretending the product is more complete
than it is.

A starter kit is not automatically:

a hosted SaaS;
a managed deployment service;
a compliance-certified system;
a guarantee that the buyer's exact use case is solved;
unlimited custom support.

It is better to say:

This is a source-code foundation. It includes the core workflow, docs and
release package. Deployment and custom implementation are separate.

That sounds less exciting, but it sets the right expectation.

Good buyers do not need fantasy. They need to know what they are actually
getting.

5. The product should save a specific kind of time

People do not buy starter kits because they love ZIP files.

They buy them because starting from zero is expensive.

The saved time has to be concrete:

authentication and roles are already mapped;
the workflow states are already represented;
the demo data shows how the product is supposed to behave;
the UI has a real domain structure instead of empty placeholder pages;
the project gives the buyer a reference architecture to adapt.

If the only value is "this has a tech stack", it is probably not enough.

6. The price should match the risk

Early pricing has to respect the trust gap.

If there are no customers, no public reputation and no reviews, the price has
to make the first buyer's risk feel reasonable.

That does not mean racing to the bottom.

It means the price should be tied to:

clarity of the workflow;
quality of documentation;
proof that the package works;
depth of the included source;
how much setup time it can realistically save.

The price can rise after real buyer proof, not before.

7. Not every old project should become a product

This is the least comfortable part.

Some projects should stay archived.

Some should become portfolio pieces.

Some should become free examples.

Only a few should become paid products.

My current rule is:

If I would be embarrassed to support a stranger after they buy it, I should
not sell it yet.

That rule is annoying, but useful.

The short version

Before selling a source-code starter kit, I want to know:

Who is the buyer?
What workflow does it help with?
Can a stranger run it?
Is there proof beyond marketing copy?
Are the boundaries honest?
Does the price match the buyer's risk?
Would I be willing to answer support questions about it?

Old code can become a product.

But only after it is cleaned, explained, packaged and bounded.

Otherwise it is just a private project with a checkout button attached.

A free checklist

I turned this into a short buyer-side checklist here:

https://www.inresonancewell.com/resources/source-code-starter-kit-buyer-checklist?utm_source=devto&utm_medium=article&utm_campaign=starter_kit_quality_gates

I am also applying the same filter to a small catalog of workflow-focused
source-code kits here:

https://www.inresonancewell.com/products?utm_source=devto&utm_medium=article&utm_campaign=starter_kit_quality_gates

No hard pitch. I am mainly interested in whether this checklist matches how
other developers judge source-code products.