Developer landing pages often explain the machinery before the value. This guide helps solo developers turn verified product facts into clear headline options, then test whether the full hero section makes sense to the right audience.
Before writing a headline, collect four inputs:
| Input | Question to answer |
|---|---|
| Target user | Who repeatedly encounters this problem? |
| Desired outcome | What tangible result are they trying to produce? |
READY WHEN YOU ARE
YOUR PRODUCT. READY TO MOVE.
Bring your product context into Tomako, then turn a guide, an idea, or a decision into work you can continue.
Start using Tomako| Current friction | What slow, fragile, expensive, or repetitive process do they use today? |
| Verified proof | What can you truthfully say about setup, performance, privacy, compatibility, or ownership? |
You can use these inputs as a starting model:
Eren
Headline hypothesis = desired outcome + relevant context - current friction
This is a drafting aid, not a universal law. The H1 does not need to contain every input. The target user might already be clear from the page, while the sub-headline or proof line can carry the mechanism and supporting details.
The job of the headline is simpler: give the right visitor a reason to keep reading.
Choose a formula based on the product and the visitor's existing awareness. Do not force every product into the same pattern.
| Pattern | Formula | Best used when | Example |
|---|---|---|---|
| 1. Remove a known friction | [Do task] without [painful workaround] | Users already recognize the workaround as a problem | Verify database restores without maintaining custom recovery scripts. |
| 2. Transform an input | Turn [raw input] into [usable output] | The product has a clear input and output | Turn Stripe webhook events into reconcilable ledger entries. |
| 3. Name the specialist | The focused [category] for [specific user or environment] | Narrow fit is a real differentiator | An uptime monitor for single-container homelabs. |
| 4. Replace a fragile process | Stop [fragile process]. [Achieve result]. | The pain is familiar and operationally important | Stop scrubbing production logs by hand. Redact secrets before export. |
| 5. Divide the work | You [high-value work]. We handle [repetitive system work]. | Users want automation without giving up control | You write the queries. We handle pooling, caching, and failover. |
These patterns are starting points. A formula makes a draft easier to produce; it does not make the resulting claim true or persuasive.
Consider a hypothetical open-source CLI that removes secrets from staging logs before those logs are uploaded to object storage.
For this exercise, assume the following product facts have already been verified:
Those facts are the boundary. We should not invent claims about speed, detection accuracy, compliance, or zero-configuration setup.
An asynchronous token-inspection proxy with regex and entropy-based secret classification.
The sentence describes internals, but it leaves the visitor to infer the job, the operating context, and the result.
| Input | Answer for this example |
|---|---|
| Target user | Developers who operate containerized staging environments |
| Desired outcome | Upload usable logs without exposing common credentials |
| Current friction | Maintaining custom redaction rules or reviewing logs manually |
| Verified proof | Local Go binary, standard input/output workflow, MIT License |
Pattern 1: Remove a known friction
Ship staging logs to object storage without exposing API keys or database credentials.
This version leads with the operational outcome and the risk being reduced. It is likely to work best when visitors already worry about secrets appearing in logs.
Pattern 4: Replace a fragile process
Stop maintaining log-scrubbing scripts. Redact common secrets before export.
This version leads with the current workaround. It is likely to work best when visitors already maintain brittle regex rules.
Pattern 3: Name the specialist
A local log-redaction CLI for containerized staging environments.
This version sacrifices some emotional pull for category clarity. It may suit visitors who are already comparing log-redaction tools.
There is no honest winner yet. Each candidate makes a different assumption about what the visitor already understands and cares about.
Every statement above can be traced to the verified inputs. That traceability matters more than making the copy sound impressive.
Use the following prompt to generate options without turning missing information into marketing claims.
You are helping a technical founder draft landing page hero copy.
Use only the verified product inputs below. Do not infer or invent performance,
privacy, compliance, customer, pricing, integration, or setup claims.
Product inputs:
- Product name: [NAME]
- Target user: [EXACT ROLE OR OPERATING CONTEXT]
- Job to be completed: [TANGIBLE USER OUTCOME]
- Current workaround or friction: [WHAT THE USER DOES TODAY]
- Product mechanism: [WHAT THE USER INSTALLS, CONNECTS, OR PROVIDES]
- Verified setup facts: [ONLY CONFIRMED FACTS]
- Verified proof or differentiator: [ONLY CONFIRMED FACTS]
- Primary conversion action: [DOWNLOAD, VIEW DEMO, START TRIAL, ETC.]
Available headline patterns:
1. [Do task] without [painful workaround]
2. Turn [raw input] into [usable output]
3. The focused [category] for [specific user or environment]
4. Stop [fragile process]. [Achieve result].
5. You [high-value work]. We handle [repetitive system work].
Instructions:
1. Select the three patterns that best fit the supplied product facts.
2. Explain why each selected pattern fits.
3. Use active, specific language.
4. Do not use "effortless," "seamless," "next-gen," "all-in-one,"
"supercharge," "unleash," or "revolutionary."
5. If a useful claim is not supported by the inputs, write
"Missing evidence" instead of completing the claim.
6. Do not add a number, timeframe, security promise, privacy promise, or
compliance statement unless it appears in the verified inputs.
For each selected pattern, return:
### Pattern [number]: [name]
- Reason for selection:
- H1 headline:
- Sub-headline:
- Primary CTA:
- Proof line, or "No verified proof provided":
- Key audience assumption:
- What could be misunderstood:
- Test hypothesis:
Finish with a comparison table showing which candidate prioritizes:
- outcome clarity;
- audience specificity;
- friction recognition;
- category clarity.
The prompt cannot validate your positioning for you. Its job is to produce bounded candidates that are safe enough to review and specific enough to test.
A five-second test checks what people notice and understand after a brief exposure. In a standard test, participants see a design for five seconds and then answer questions from memory, as described in Lyssna's five-second test documentation.
Test the complete hero section, not the headline in isolation. Show it to relevant users, hide it, and ask:
Record the words participants use. If several people repeat the same misunderstanding, revise the copy that created it. If answers vary because participants are not part of the intended audience, improve the recruiting before rewriting the headline again.
A five-second test measures first-impression clarity and recall. It does not prove that a headline increases signups or revenue. Once two candidates communicate the product accurately, compare them under similar traffic and conversion conditions.
Before publishing a hero section, check the full message against these questions:
Clear copy is not the finish line. It is a testable explanation of why the product matters to a particular user.
When you are ready to test that explanation in public, compare the strengths and risks of different launch communities in Product Hunt vs Reddit vs Hacker News: Where Should Solo Founders Launch First?.
Tomako is an always-on AI CMO for software builders. The principle behind it is simple: go-to-market work should stay grounded in real product context and remain reviewable before it goes public. If you are building a repeatable distribution habit, you can also use The 30-Minute Daily Marketing Routine for Solo Founders as a practical starting point.
Tomako Founder, Product Strategy & Experience Design
Eren is the founder of Tomako, focused on the decisions that shape SaaS and AI products—from defining a problem and building the product to refining the user experience. As a product manager, product designer, and developer, he looks at products through the combined lens of user needs, positioning, interaction design, and implementation. His writing covers product insight, validation, onboarding, positioning, and how to turn complex ideas into useful product experiences.
View author profile