The 'Show code' rule

Imagine you are buying a car. You go to the dealership website. Instead of pictures of the car, you see photos of happy families driving something. You see text saying "Best-in-class acceleration" and "Robust safety features." But you cannot see the car. You cannot see the interior. You cannot see the dashboard.

You would assume the car is ugly. You would assume they are hiding something.

This is how 90% of B2D (Business to Developer) companies market their software. They show abstract 3D illustrations of "clouds connecting to nodes." They show stock photos of people pointing at whiteboards. They write paragraphs about "Seamless Integration."

But they hide the product. For a roadmap tool, the product is the UI. For a developer tool, the product is the code.

The heuristic: "Time to <code>"

I have a simple rule when auditing landing pages for developer tools: How many pixels do I have to scroll before I see a syntax-highlighted code block?

If the answer is > 0 (it is not above the fold), your conversion rate is suffering. If the answer is > 1000 (I have to scroll past the "Trusted By" logos), you are losing 50% of your technical traffic.

Developers possess a unique form of "Banner Blindness." Eye-tracking studies by the Nielsen Norman Group show that technical users actively ignore areas that look like ads or "fluff." They scan for high-information density zones.

Their eyes gloss over words like "Scalable," "Powerful," and "Easy." These are null values. "Easy" is a subjective claim.

Code is objective. Code is truth.

Why code converts

When a developer sees a code snippet, they perform an instant simulation:

1. Complexity Analysis: "How many import statements? How many lines of boilerplate?"
2. Paradigm Check: "Is this declarative or imperative? Is it typed?"
3. Vibe Check: "Does this look modern? Does it use async/await or callbacks?"

This simulation happens in milliseconds. It is higher bandwidth than any video or paragraph you could write.

Example: The "Vague" vs "Explicit" test

Company A (Vague):

Headline: "Add Authentication to your App in Minutes." Subhead: "Our robust API allows for secure, compliant user management with minimal overhead. Trusted by enterprise." Button: "Get Started."

Developer Reaction: "Bullshit. 'Minutes' probably means 'Days'. 'Robust' means 'Bloated'. I bet I have to configure 10 redirects."

Company B (Explicit):

Headline: "Auth for people with deadlines." Hero Image:

import { auth } from '@company/client';

// Sign in with GitHub
const { data, error } = await auth.signInWithOAuth({
  provider: 'github'
});

Developer Reaction: "Oh, it's just a function call. It returns a tuple data, error? Minimalist. I like that. I can paste this in my middleware."

Company B didn't just say it was easy. They proved it.

The taxonomy of the hero snippet

Not all code snippets are created equal. A bad snippet is worse than no snippet.

1. The "Hello World" snippet

• Best for: APIs, SDKs, Databases.
• Content: Connectivity. connect(), query(), print(result).
• Goal: Show that the barrier to entry is low.
• Example (Redis): redis.set('foo', 'bar'); const value = await redis.get('foo');

2. The "Config" snippet

• Best for: Infrastructure, CI/CD, DevOps tools.
• Content: A standard YAML or JSON configuration file.
• Goal: Show that the configuration is declarative and readable.
• Example (GitHub Actions):

on: [push]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2

3. The "Interactive" snippet (The gold standard)

• Best for: Frontend Libraries, UI toolkits.
• Content: A live editor where you can change a value and see the result render instantly.
• Examples: React.js homepage, Tailwind CSS.

Implementation guide: Do's and don'ts

DO: Use real syntax highlighting

Do not use a screenshot (image). Use a library like shiki or prism.js to render the code blocks. * Why? Developers will try to copy-paste it. If they can't select the text, it breaks the immersion. * Why? It ensures the font rendering matches their OS.

DO: Support tabs for languages

If you support Python, Node, and Go, provide toggle tabs. * Why? Personalization. A Go developer seeing Python code feels "This isn't for me." A Go developer seeing a Go tab thinks "They respect my ecosystem."

DON'T: Show boilerplate

Use "Marketing Code," not "Production Code." * Hide the imports (unless relevant). * Hide the extensive error handling (unless that's the feature). * Hide the class instantiation. * Focus on the "Magic Line": The single line where the value is delivered.

DON'T: Use generic variable names

Don't use foo, bar, baz. Use semantic names that suggest a use case. * Bad: createUser('foo') * Good: createUser('[email protected]', { plan: 'enterprise' }) * This subtly plants a seed about what the tool is used for.

Summary

Your homepage is not a brochure. It is a technical specification disguised as a webpage.

Respect the visitor's intelligence. They are here to investigate a tool. Give them the specifications immediately.

If you are hiding the code, the developer assumes you are ashamed of it. Show the code. Win the trust.