DEV Community: David Diaz

Eight landing-page checks before you launch

David Diaz — Mon, 10 Aug 2026 15:00:04 +0000

AI disclosure: This article was developed with AI assistance and reviewed against public tests and deterministic audit output.

A page can be technically live and still fail before a customer understands the offer. RELAUNCH DEPT. uses this short pre-launch pass.

1. Delivery

Check the final HTTP status, redirect chain, HTTPS and mixed-content risk. A 200 response is necessary, not sufficient.

2. Search basics

Verify the title, meta description, canonical URL, page language and mobile viewport. Missing metadata makes a finished product look temporary.

3. Social previews

Inspect the Open Graph title, description and image, plus Twitter card metadata. The first impression often happens before the visit.

4. Heading structure

Use one useful H1 that explains the page. A logo, placeholder or decorative slogan is not a substitute.

5. Images

Give meaningful images useful alt text and mark decorative images intentionally empty. This is a basic quality check, not an accessibility certification.

6. Trust leaks

Search for lorem ipsum, TODO, “coming soon,” example domains and unfinished copy. One visible placeholder can undermine the rest of the page.

7. Structured data and favicon

These are small omissions, but they are also visible signals of an incomplete launch.

8. Conversion path

Give the visitor one clear next action instead of five competing buttons.

A reproducible result

A public test against example.com returned HTTP 200 but scored 39/F with eight findings. The useful reminder is simple: “loads successfully” is not the same as “ready to launch.”

I turned this checklist into a bounded open-source Apify Actor. It accepts at most 10 public HTTP(S) URLs, performs one HTML request per page, follows no more than five validated redirects, blocks private or reserved networks and credential-bearing URLs, caps responses at 2 MB, and never logs in or bypasses access controls.

If the report exposes a positioning or conversion problem, RELAUNCH DEPT. offers two bounded one-time repair scopes: a $59 landing-page teardown or $249 launch rescue.

What is the most common “technically live, commercially broken” launch defect you see?

The audit is deterministic rules-based analysis, not legal, security, accessibility-certification or search-ranking advice.

Why a SaaS Launch Gets Visits but No Signups

David Diaz — Sat, 08 Aug 2026 13:33:26 +0000

A four-leak audit for founders who do not need more traffic yet

Transparency: this article was prepared with AI assistance by RELAUNCH DEPT. The examples are illustrative, and the diagnostic framework is provided for general operational use.

A quiet launch creates a tempting conclusion: not enough people saw it. Sometimes that is true. Often it is not the first problem.

If visitors arrive and still do nothing, buying more traffic simply sends more people into the same unclear decision. Before you promote harder, audit four leaks: message, proof, buying path, and distribution fit.

1. The message leak

A weak landing page usually describes the product category instead of the buyer's job.

“An AI-powered platform that transforms your workflow” sounds polished, but it leaves four questions unanswered:

Who is it for?
What painful task does it replace?
What changes after using it?
Why should that happen now?

Try this test: remove the product name and logo. Could a reader still tell which specific person should care and what they can accomplish?

A stronger hero does not need to explain every feature. It needs to earn the next scroll. Name one buyer, one expensive or frustrating job, one concrete outcome, and one next step.

Instead of “Unlock the power of customer data,” try a structure such as: “Turn one hour of customer calls into six sales-ready objections your team can use today.”

Specificity gives the visitor something to accept or reject. Vagueness only asks them to work harder.

2. The proof leak

Claims are not proof. “Fast,” “accurate,” and “easy” are conclusions the seller wants the buyer to reach.

Evidence helps them reach it independently.

Useful proof can include:

a real before-and-after example;
a short product walkthrough tied to one job;
an output sample with sensitive data removed;
a measured result with its source and date;
a named customer statement you have permission to publish;
a transparent limitation that shows where the product is not a fit.

If there is no customer proof yet, do not invent it. Show the mechanism. A concrete input, transformation, and output is stronger than a wall of unsupported superlatives.

3. The buying-path leak

Interest disappears when the next step feels larger than the promise.

Common friction includes competing calls to action, hidden pricing, a required sales call for a simple purchase, unclear delivery timing, and a checkout that introduces a different product name or scope.

Walk through the path as a stranger:

Read the hero.
Click the primary action.
Compare the checkout with the page.
Ask what happens immediately after payment.

The offer, price, delivery window, revision policy, and next step should agree everywhere. Every contradiction creates a reason to postpone.

4. The distribution-fit leak

More channels do not automatically create more qualified attention.

A broad community may produce visits while reaching almost nobody who feels the problem today. A smaller directory, comparison page, technical guide, or marketplace category can outperform a large audience when the intent is closer to the job you solve.

Track channels separately. At minimum, record the page, date, audience, message angle, visits, meaningful conversations, checkout clicks, and payments. Do not call impressions demand, and do not call clicks revenue.

After a useful sample, keep the channels that create qualified actions and replace the ones that only create noise.

The 15-minute decision

Do not redesign everything at once. Score the four leaks and choose the weakest one.

If the message is unclear, rewrite the hero before buying traffic.
If the promise is clear but untrusted, add evidence.
If visitors understand and believe you but hesitate, simplify the buying path.
If the page converts warm visitors but launch traffic is irrelevant, change distribution.

RELAUNCH DEPT. has a free, no-email launch scorecard that turns this audit into ten quick questions: https://www.daradigu.com/launch-scorecard?utm_source=dev&utm_medium=article&utm_campaign=quiet_launch_audit_20260808

If you want the repair executed rather than diagnosed, the $249 48-hour Launch Rescue Sprint covers positioning, a production-ready hero, launch visuals, reusable copy, and focused distribution: https://www.daradigu.com/?utm_source=dev&utm_medium=article&utm_campaign=quiet_launch_audit_20260808#sprint

The goal is not a louder launch. It is a clearer decision for the right buyer.

AI Said “Ready.” Two Sources Disagreed. Here’s the Gate That Stopped It.

David Diaz — Sat, 08 Aug 2026 06:32:56 +0000

AI-assisted disclosure: I used AI tools to help edit this article and the
open-source project it describes. The architecture, tests, deployment evidence,
and claim boundaries were reviewed against the public repository and live
service before publication.

I created this piece of content for the purposes of entering the All Things
Agentic Hackathon.

An autonomous agent can produce a confident status update long before the work
is actually complete. A deployment command can exit successfully while the
public endpoint still fails. A marketplace can display an opportunity that the
authoritative issue has already closed. A generated report can look finished
while one required source is stale.

The problem is not that language models cannot reason. The problem is that
“done” is a state transition, and state transitions need evidence.

I built Proofline to test a
simple pattern: let the model interpret the task, but make a deterministic gate
decide whether the evidence is sufficient.

Separate interpretation from acceptance

Proofline divides the workflow into two layers.

The agent layer uses Gemini 3.6 Flash and Google Agent Development Kit to:

interpret the task contract;
identify the requirements that need proof;
explain missing or contradictory evidence;
call a narrowly scoped evaluation tool.

The verification layer then applies explicit rules. It does not ask the model
whether the task feels complete. It evaluates structured evidence and returns
one of four states:

NEEDS_EVIDENCE — at least one requirement lacks fresh authoritative proof;
CONFLICT — authoritative sources contradict one another;
APPROVAL_REQUIRED — the evidence is complete, but the next action has an external side effect;
READY — every requirement is satisfied and no approval gate remains.

That split matters. The model remains useful where language and context are
messy, while the acceptance boundary stays inspectable and testable.

Make evidence a first-class object

Each evidence item carries more than a sentence saying something worked. It
records the requirement it supports, its source, whether that source is
authoritative, when it was observed, and the value that was actually returned.

A deployment claim, for example, should not be supported by “the command
succeeded.” Better evidence is an external HTTP response from the deployed URL,
the active revision identifier, and a timestamp inside the allowed freshness
window.

The same rule applies outside infrastructure. If a payment platform reports a
test balance, it cannot prove live revenue. If a bounty marketplace says an
issue is open but the repository says it is closed, the authoritative issue
wins and the conflict should stop the workflow.

Hash the decision packet

Once the gate evaluates the evidence, Proofline serializes the result in a
canonical order and computes a SHA-256 packet hash. The hash does not make a
weak claim true. It makes the exact decision inputs and output tamper-evident.

This is useful when an agent runs asynchronously. A reviewer can verify that
the packet being approved is the same packet the gate evaluated. If any
requirement, evidence item, timestamp, or decision changes, the hash changes.

Keep external actions behind a human boundary

Evidence can prove that a form is complete; it cannot decide whether a person
wants to submit a legally binding entry, publish a message, or spend money.
Proofline therefore treats those actions as a separate approval state.

This prevents a common automation mistake: combining technical readiness with
permission to act. The agent can prepare everything and prove that preparation,
but the final side effect remains explicit.

Prove the architecture with a live path

The public demonstration runs as a Google ADK application on Cloud Run. An
external request can discover the proofline app, create a real ADK session,
invoke Gemini, and call the deterministic evaluation tool. The repository also
contains a credential-free test path so the safety boundary can be inspected
without cloud access.

The deployed demo currently uses in-memory state. Firestore and Pub/Sub are
documented extension points for durable packets and asynchronous rechecks; they
are not presented as active components. That distinction is intentional:
architecture diagrams should separate what is live from what is planned.

A practical checklist

Before allowing an agent to declare a real task complete, ask:

What exact requirement is being satisfied?
Which source is authoritative for that requirement?
Is the observation fresh enough for the decision?
What happens when two authoritative sources disagree?
Can the decision be reproduced from structured inputs?
Does the next step create an external side effect?
Can a reviewer distinguish deployed components from planned ones?

If those questions do not have explicit answers, the agent probably has a
status message, not proof.

Watch the contradiction happen in one continuous run

The updated 46-second walkthrough uses one synthetic launch fixture from start to finish: Proofline collects the evidence, finds a 24-hour-versus-48-hour delivery contradiction, stops the action, verifies the correction against fresh sources, records human approval, and seals the evidence packet. No edit is used to hide a failing state.

Watch the continuous demo and inspect the evidence boundary.

You can also inspect the implementation, tests, architecture, and deployment evidence in the public Proofline repository or verify the Cloud Run application discovery endpoint.

What failure mode should the next reproducible fixture cover? Leave it in the comments; concrete examples are more useful than generic feature requests.

If you want an external evidence audit for a launch or automation, RELAUNCH DEPT. offers a USD 59 evidence audit and a USD 249 implementation sprint. These are operational services, not legal, tax, or financial advice.

The JSON Error That Hid the Real Failure

David Diaz — Sat, 08 Aug 2026 03:38:57 +0000

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry.

A migration audit should fail loudly when data is lost. Mine failed loudly too—but, in one edge case, it reported the wrong failure.

The bug lived in a one-command Python showcase built for an open-source Memanto contribution. The command turns a real GitHub discussion into an Open Knowledge Format bundle, runs Memanto's official migration dry run, round-trips the records through production mapping code, and writes a JSON fidelity receipt.

The happy path was straightforward. The uncomfortable path was not.

The pipeline and its two kinds of failure

The final audit is a subprocess. It can return a non-zero exit status for two very different reasons:

it completed the comparison and found lost or changed records, while still emitting a valid JSON receipt; or
it crashed before it could emit valid JSON.

The first case is expected domain behavior. We want to preserve its receipt and then propagate the non-zero status. The second is an operational failure. We want the original CalledProcessError, including its exit code, because that is the evidence that tells a developer what actually went wrong.

The original control flow captured the subprocess error, but then parsed its output before re-raising it:

try:
    audit_stdout = _run(audit_command, capture=True).stdout
except subprocess.CalledProcessError as error:
    audit_error = error
    audit_stdout = error.stdout or ""

report = json.loads(audit_stdout)
report_path.write_text(json.dumps(report))

if audit_error is not None:
    raise audit_error

That looked reasonable until the audit process failed without producing JSON. json.loads() then raised JSONDecodeError first. The original subprocess exception—and its meaningful return code—never reached the caller.

The parser had become an error-mask.

Reproducing the hidden branch

The useful breakthrough was to stop thinking of the output as simply “valid” or “invalid” and model two independent signals:

Did the process succeed?
Is its output valid JSON?

That creates four cases:

Process result	Output	Correct behavior
success	valid JSON	write receipt and continue
failure	valid JSON	write receipt, then re-raise the process error
failure	invalid JSON	re-raise the process error; do not create a receipt
success	invalid JSON	surface `JSONDecodeError` because the producer broke its contract

The masked failure was the third row. A regression test simulated an audit that exited with status 7 and printed plain text instead of JSON:

def fake_run(command, *, capture=False):
    if capture:
        raise run_demo.subprocess.CalledProcessError(
            7,
            command,
            output="audit crashed before producing JSON",
        )
    return run_demo.subprocess.CompletedProcess(command, 0)

The test asserts two things that matter operationally:

try:
    run_demo.run_showcase("acme/repo", 7, workdir)
except run_demo.subprocess.CalledProcessError as error:
    assert error.returncode == 7
else:
    raise AssertionError("Invalid audit output masked the process failure")

assert not (workdir / "audit.json").exists()

It does not merely expect “an exception.” It verifies that the right exception and exact status code survive, and that invalid output is not blessed as an audit artifact.

The fix: preserve causal priority

The correction keeps valid failing receipts, but gives the original process failure priority when JSON parsing also fails:

try:
    report = json.loads(audit_stdout)
except json.JSONDecodeError:
    if audit_error is not None:
        raise audit_error from None
    raise

report_path.write_text(
    json.dumps(report, indent=2, ensure_ascii=False) + "\n",
    encoding="utf-8",
)

if audit_error is not None:
    raise audit_error

The from None is deliberate. In the simultaneous-failure branch, the JSON error is a side effect of missing output, not the root cause. Suppressing that context keeps the traceback focused on the subprocess failure the operator needs to investigate.

At the same time, a valid JSON report from a fidelity failure is still written before the original non-zero result is propagated. That report is valuable evidence; throwing it away would create a different debugging problem.

What changed after the fix

The branch now has explicit regression coverage for both failure modes:

a failed audit with valid JSON preserves the receipt and exit status;
a failed audit with invalid output preserves the original exit status and writes no receipt.

The focused suite reports 25 passing tests, with Ruff checks, formatting, and mypy also clean on the contribution branch. The wider migration demo has additionally completed a 32-record real-data round trip with zero removed or changed portable fields. Those broader results are useful, but the most important outcome of this debugging story is smaller: when the pipeline fails, its diagnostic contract is now trustworthy.

Three lessons I am keeping

1. Error handling needs its own truth table

Nested fallible operations create combinations that a linear happy-path reading hides. A small matrix exposed the missing branch faster than another end-to-end run would have.

2. Test identity, not just category

“An exception was raised” would have passed before and after the fix. Checking returncode == 7 proves that causality survived.

3. Artifacts are part of failure semantics

A diagnostic file should exist only when it is valid. The absence assertion prevents future code from leaving behind a misleading audit.json after a producer crash.

Evidence

The larger PR introduces an OKF portability workflow; this Smash Stories entry is specifically about the real exception-masking bug caught and fixed during its review. The PR is open and mergeable at the time of writing; no merge or bounty award is assumed.

AI assistance disclosure: AI tools assisted with code review and drafting. The behavior, fix, tests, and validation claims above are linked to reproducible repository evidence.

Five Mobile Landing-Page Bugs That Hide in Desktop Review

David Diaz — Sat, 08 Aug 2026 03:28:24 +0000

A practical pre-launch QA pass for 320 px, 375 px and 414 px screens.

A landing page can look polished on a laptop and still lose customers on a phone. The problem is rarely one dramatic failure. It is usually five small defects that make the first action harder than it should be.

1. Horizontal overflow that only appears at one width

Test at 320 px, 375 px and 414 px. Look for clipped copy, carousels wider than the viewport, fixed-width tables and decorative elements that push the page sideways. Record the exact viewport and attach a screenshot; “mobile is broken” is not an actionable bug report.

2. A primary CTA that disappears below the fold

The visitor should understand the offer and see the primary action without hunting. Check whether a tall hero image, consent banner or oversized navigation moves the CTA below the first useful screen. The fix is often hierarchy, not more copy.

3. Touch targets that work with a mouse but not a thumb

Buttons and links need enough space to tap reliably. Use 44 × 44 px as a practical minimum, then check the distance between adjacent controls. Tiny close icons, crowded navigation and text-only links are common failure points.

4. Forms that ignore the mobile keyboard

Verify labels, focus order, error messages, autofill and the keyboard type for email, phone and numeric fields. A form can technically submit and still create enough friction to lose the conversion.

5. Images that steal the performance budget

Inspect oversized hero images, off-screen media loaded too early and layout shifts caused by missing dimensions. The goal is not a perfect laboratory score; it is a stable first interaction on a real connection.

A useful QA report should make every finding reproducible: viewport, steps, expected behaviour, actual behaviour, screenshot and priority. That format gives a designer or developer something they can fix immediately.

I have packaged this process into a fixed-scope Mobile Landing Page QA Audit: one live page, annotated screenshots, a prioritized fix list and one retest, delivered within five business days for $59.

AI-assisted tools may support analysis; every published finding is reviewed before delivery.

Originally published by RELAUNCH DEPT. on Medium.