We run RadarMakers, built by a small team of indie makers. This checklist is for makers preparing their first release or bringing a substantially improved product to new users in 2026. Work through it before launch, keep it open on launch day, and use the final section to plan your next release.

Before launch: make the promise testable

Choose one user and one useful outcome

Write down who the product serves, what task they struggle with, and what they can finish with your help. Be specific enough that someone outside your project can decide whether it fits their work.

For example, a scheduling tool could focus on helping independent consultants collect client availability. That gives you a concrete workflow to demonstrate and a recognizable person to invite.

• Name the first type of customer you want to serve.
• Describe the task they currently handle manually or with difficulty.
• Write one sentence explaining the outcome your product enables.
• Identify the action that proves a new user reached that outcome.
• Record known limitations so your launch copy reflects what works today.

Give the landing page one clear next step

Read the first screen as someone who has never heard of your product. They should be able to explain who it helps, what it does, and what happens when they click the main button.

Show the product doing its central job. A screenshot with readable labels can answer questions that a paragraph of broad claims leaves open. Check the page on a phone and through a fresh browser session.

• Put the user and outcome in the headline or opening paragraph.
• Choose a primary action with a concrete label, such as starting a trial.
• Explain whether that action requires an account or payment details.
• Add a screenshot showing a meaningful result.
• Check links, forms, confirmation messages, and mobile readability.
• Make your support contact easy to find.

Ask someone unfamiliar with the product to describe it after reading the page. If their explanation misses the intended use, revise the copy before adding more sections.

Walk through onboarding with an empty account

Your development account probably contains data, saved settings, and shortcuts that a new customer lacks. Start again with an empty account and follow the same route a visitor will take.

Give each screen an obvious next action. If setup requires importing data or connecting a service, explain why and show how to recover when that step fails. Offer sample data where it helps people understand the workflow.

• Test registration, confirmation messages, sign in, and password recovery.
• Complete the main task without relying on previously saved data.
• Remove setup questions that can wait until later.
• Explain empty states with an action the user can take.
• Check what happens after a failed import or interrupted session.
• Confirm that progress remains available after signing in again.

Make the pricing page answer buying questions

A visitor should understand the price and its boundaries before creating an account. State what the billing unit means, whether prices are monthly or annual, and which limits affect normal use.

If you display a monthly equivalent for an annual plan, make the annual charge explicit. If a trial ends with a payment, explain when that happens. Keep these details consistent with the actual checkout.

• Show the billing interval beside each price.
• Define usage limits and what happens when someone reaches them.
• State which features belong to each plan.
• Explain trial duration and whether payment details are required.
• Describe cancellation and refund terms in plain language.
• Test checkout, plan changes, and cancellation where applicable.

If pricing is still an experiment, choose an initial offer you can explain and support. Keep a dated record of it so you know which terms early customers accepted.

Set up measurement and a feedback inbox

Choose a small set of events that describe the journey from interest to value. Page views alone cannot tell you whether people completed the task your product promises to help with.

Start with a landing page visit, registration, the first useful result, and a return to the core workflow. Include a purchase event if payment is part of the launch. Use your own test account to confirm that each event records correctly without collecting passwords, private documents, or other sensitive content.

• Define the first useful result as a specific event.
• Verify event names and remove duplicate recordings.
• Distinguish your testing activity from customer activity.
• Record the launch baseline before inviting visitors.
• Create one inbox or document for feedback.
• Prepare fields for the problem, context, severity, and next action.

Prepare your listing assets and submission

Gather a product name, tagline, short description, logo, screenshots, website link, pricing model, and category. These are the pieces used in a RadarMakers product listing. Keep them together so you can check the whole message before submitting.

Use screenshots from the current product with private information removed. Lead with the main workflow and include a result people can recognize. Your description should explain who the product helps, what they can do with it, and any limitation that affects trying it.

• Match the tagline to the promise on your landing page.
• Write a short description you can reuse in personal invitations.
• Check that screenshots remain readable at a smaller size.
• Confirm that the website link opens the intended page.
• Select the pricing model and category that fit the product today.

Submit your SaaS to RadarMakers once the product and assets are ready. Submission is free and requires an account. Our team reviews submissions before they go live, so leave room for review when planning your launch communications.

On launch day: launch on RadarMakers and be available

Check the live listing and customer journey

When your reviewed listing is live on RadarMakers, open it and follow the website link as a new visitor. Check the description, screenshots, and pricing model against the product people can actually use.

• Confirm that the live listing communicates the intended use.
• Complete the path from the listing to your first useful result.
• Check that analytics capture the journey.
• Reserve time to respond and investigate problems.
• Keep a short record of issues and questions as they arrive.

Reply to every comment

Signed-in RadarMakers members can leave comments, upvote products, and rate them. Read every comment on your product and reply with something relevant to what the person said.

For a question, answer directly. For a bug report, acknowledge the obstacle and ask for the minimum detail needed to reproduce it. For criticism, clarify the task the person wanted to complete before deciding what to change.

• Reply to every comment, including brief acknowledgments.
• Ask for context when the problem is unclear.
• Move private account details to your support contact.
• Record actionable feedback in your feedback document.
• Give realistic updates when you commit to investigating something.

Ask people you know to try the core task

Send a personal invitation to people whose work matches your intended audience. Explain why the product might fit and ask them to attempt one specific task. Make it easy to decline.

Ask where they got stuck, what they expected, and whether the result would be useful in their normal work. Record whether they completed the task independently or needed your help. Both outcomes teach you something, but they mean different things for onboarding.

• Contact relevant people individually.
• Give them one task with a recognizable finish.
• Ask for honest feedback based on actual use.
• Note any assistance you provided.

After launch: turn reactions into shipped improvements

Read the four rating axes separately

RadarMakers product pages show ratings for idea, execution, design, and value, plus an overall score. Use each axis to form questions. A rating alone does not explain the cause, so compare it with comments, observed behavior, and direct feedback.

• For idea, investigate whether the problem matters to the intended user.
• For execution, check whether the core workflow delivers reliably.
• For design, inspect navigation, readability, and confusing interactions.
• For value, compare the useful outcome with the price and effort required.

Avoid treating a small number of ratings as a final verdict. Look for specific obstacles you can reproduce or questions you can explore with users.

Build a fix list with clear priorities

Give each issue a short description, supporting evidence, affected workflow, and completion condition. Combine duplicate reports while keeping their context.

Handle broken access, lost work, and failed payments first. Then address obstacles that prevent the first useful result. Schedule smaller improvements after those paths work reliably.

• Separate observed problems from suggested solutions.
• Write a completion condition for each selected fix.
• Choose a small batch you can finish and verify.
• Assign an owner, even if every item belongs to you.

Follow up, ship, and explain what changed

Contact people who reported an issue when you have a relevant update. Explain the change, invite them to retry the task, and ask whether the original problem remains.

Publish a dated changelog on your own site. Describe the affected workflow, the new behavior, and any action existing users need to take. Retest the original failure before marking the fix complete.

Then write a practical guide in the RadarMakers Community. Teach one workflow your product supports, include the starting conditions and steps, and explain a common mistake. Use what you learned from launch questions to make the guide useful.

• Verify shipped fixes against the original reports.
• Follow up with the people affected.
• Publish a changelog with concrete changes.
• Write a Community guide that helps someone finish a task.
• Review whether new users now reach the first useful result more easily.

Ready to put this checklist to work? Prepare your assets, test the customer journey, and submit your product to RadarMakers.

Originally published on the RadarMakers Community.

Start with the people closest to the problem. Talk to existing signups, invite suitable people personally, and make their first session easier. Write down what brings people in and what stops them. Each conversation gives you something concrete to work on before your next invitation.

We run RadarMakers, and our approach here is practical: build relationships you can continue through your own product, website and email. Your first 100 users give you a manageable group to learn from, provided you pay attention to what they actually do.

Decide what counts as a user

Choose one action that means someone has received the product's core benefit. For a file conversion tool, that could be downloading a converted file. For a planning app, it could be creating a plan they intend to use.

Count each person once when they complete that action. Keep visitors, email subscribers and account registrations as separate totals. Exclude your own test accounts.

This definition makes your next decision clearer. If people register but never finish the core action, spend time on their first session. If the people you contact rarely show interest, revisit who you are approaching and the problem you describe.

Track returning use separately too. The first successful session is a useful milestone, while another visit can tell you whether the product fits an ongoing need.

Talk to the people who already signed up

Open your signup list before looking for strangers. Send a personal message to someone who tried the product and ask what they hoped to accomplish.

Keep the request small. Ask one question they can answer without booking a call, such as what they were trying to do when they registered. If they respond, ask whether they managed to finish it.

For someone who stopped partway through, offer help with that specific task. Ask permission to watch them try again, or let them describe where they got stuck. Avoid walking them through every click immediately. Give them room to show you what they expected.

Record their goal, the point of confusion and any workaround. A vague complaint about complexity becomes useful when you learn that someone could not tell which file types were accepted.

After making a relevant fix, reply in the same conversation. Explain what changed and invite them to retry the task. This gives an existing signup a reason to return and tests whether your fix helped.

Reach potential users one person at a time

Describe a narrow group with a recognizable task. Freelancers who send recurring client reports are easier to approach meaningfully than everyone who wants to save time.

Build a short contact list from people you know, introductions and public business websites. For each person, write down why the task might matter to them. If you cannot identify a reason, leave them off the list for now.

Write each message around that reason. Introduce yourself, explain the task your tool helps with, and offer a small next step. That might be trying a sample or answering a question about their current workflow.

Keep any proposed wording truthful. If you have only read someone's website, say that. Describe the benefit your product currently delivers and link to the page that demonstrates it.

Send only as many invitations as you can support personally. When someone replies, learn how they handle the task today before explaining every feature. If they decline or do not want further contact, respect that. A followup should add something relevant, such as a fix for a limitation they mentioned.

Make the first useful result easier to reach

Watch what happens between an invitation and the core action you defined. Test the exact page you sent, using a fresh session and the same route a visitor takes.

Look for decisions that require knowledge a new user does not have. An empty screen may need a working example. An unfamiliar setting may need a sensible default. A failed upload should explain how to recover.

Use this short review after observing an actual attempt:

• Does the arrival page explain who the product helps and with what task?
• Is there an obvious next action?
• Can someone try a sample if they lack suitable material?
• Do required inputs explain what is accepted?
• Does the completed result show what to do next?

Choose the obstacle you actually observed and fix it. Then ask the person who encountered it to try again. Keep a note of whether they reached the useful result without your help.

Launch on RadarMakers and turn responses into questions

Once your live project gives people something to try, a RadarMakers launch is a natural step for inviting other makers to examine it.

Submission is free and requires an account. Submissions are reviewed by the RadarMakers team before going live. Use your listing's tagline, description and screenshots to explain the task your product solves, then provide its website link, logo, pricing model and category.

Submit your project to RadarMakers and invite makers to try it and share an honest assessment.

Signed-in members can upvote, comment and rate products on idea, execution, design and value. Use those different forms of response to guide your next questions. A vote records interest. A comment may explain a difficulty. A rating can suggest an area to investigate, but you still need to understand the experience behind it.

If feedback questions the value, ask what outcome would make the product useful to that person. If someone mentions confusing design, ask which step was unclear. Answer what you can, make a relevant improvement and follow up when it is available.

Keep your acquisition measure separate: a vote or rating does not count toward your first 100 users unless that person also completes your core action.

Write useful content on your own site

Use the questions from conversations as article topics. Choose a specific task your intended users need to finish and explain it clearly enough that the reader gets something useful immediately.

For a reporting tool, that could be a guide to organizing a recurring client report. Explain what to include, show a worked example and identify mistakes the reader can avoid. Label examples as examples rather than presenting them as customer results.

Add a relevant invitation where your product helps with the task. Link to a working sample or the appropriate starting screen. A reader following a guide should arrive somewhere that continues the same job.

Publish on your own site, connect related articles and keep instructions current. You can also send a helpful article directly to someone who asked the question it answers. That gives you a useful reason to reconnect.

Start with one strong page addressing a real question. Improve it when readers reveal gaps, and track whether its readers become users before committing to a large publishing schedule.

Build a simple email list people want to hear from

Give visitors who are interested but not ready a clear way to stay in touch. Place a signup form beside a relevant guide or product example and explain what subscribers will receive.

Keep the promise specific, such as occasional practical tips and product improvements. Make subscription a deliberate choice and provide an easy way to unsubscribe. Keep it separate from creating a product account.

Send a welcome message that delivers what you promised. Include one useful resource, a relevant product link and a question people can reply to. Read the replies yourself while the list is small.

For later emails, choose a concrete reason to write: a new guide, a fix for a common obstacle or an example of how to complete a task. Give readers one clear next step.

When a subscriber becomes a user, record both their original discovery source and the email that prompted them to try. This helps you see how staying in touch contributes to acquisition.

Act on feedback and keep a public changelog

Collect feedback in one place with the task behind each request. Include who encountered the issue, what they needed and how it affected their attempt to use the product.

Prioritize problems that block the core outcome. Look for repeated difficulties, but pay attention to a single report of something that prevents use entirely. Ask for clarification before building a feature whose purpose you do not understand.

Publish a simple changelog on your own site. For each shipped improvement, state what changed, who it helps and how to use it. Include a screenshot when the difference needs showing.

Send the relevant entry to people who raised that issue. Ask whether it resolves their original problem. Avoid treating every update as a reason to contact every person.

When someone has successfully used the product, you can also ask whether they know another person with the same task. Offer a short description they can pass along, leaving the introduction to them.

Keep a spreadsheet for the first 100 users

Create one row per person who completes your core action. Use an internal identifier and record only the detail you need to learn from acquisition.

Include these columns:

• Date of first successful use.
• Original discovery source.
• Specific article, email or outreach conversation.
• Core action completed.
• Main obstacle or feedback.
• Followup and returning use.

Use consistent source labels, such as personal outreach, own-site article, email, referral and RadarMakers. If several steps contributed, record the first source and the later step that prompted action. When the source is unclear, ask how they found you and leave it unknown if they do not answer.

Keep a separate small tally of invitations and visits where you can measure them. User rows alone cannot show how much effort a source required.

Review the sheet each week. Repeat the activity that brings suitable people who complete the task. Where people arrive but stall, investigate their experience. Where invitations miss the mark, adjust your audience or message.

Your next working session can start with one existing signup, one relevant personal invitation and one observed obstacle to fix. Continue those conversations, publish what you learn and give people a reason to return.

Launch your project on RadarMakers, invite honest votes, comments and ratings, and use the responses to improve the experience for the next person who tries it.

Originally published on the RadarMakers Community.

They are not equal. Some are worth an afternoon of careful preparation. Some are worth five minutes. Some are not worth your time at all. This checklist is about telling them apart before you spend the effort, and about preparing a listing that holds up wherever it lands.

Disclosure: I'm building RadarMakers, an early-stage launch platform. The table below comes from submitting it to a batch of other platforms in one day.

Start with the question "who is there?"

The most important property of a launch platform is its audience, and it is also the easiest one to ignore. A large, marketing-focused audience may be a poor fit for a command-line tool aimed at database engineers. A small, focused community of designers might do more for a design plugin than a giant general directory.

Before you submit anywhere, spend a few minutes browsing the platform as a visitor:

• Look at the products launched in the last few weeks. Are they similar to yours in type, price range and audience?
• Read the comments. Are they real questions and feedback, or mostly generic praise?
• Check whether the people commenting look like potential users or mostly other makers promoting their own launches.

If nobody there would plausibly use what you built, the launch is unlikely to bring many relevant users, no matter how well it performs on the day.

Free queue, paid queue, or pay to play

Many directories are free to submit to, but "free" can mean very different things. A common model is a free queue with a long wait and a paid option to skip ahead. Some platforms show the free waiting time openly. Others only reveal it after you have created an account and filled in the whole form.

None of this is wrong in itself. Running a directory costs money. But you should decide with full information:

• Find out how long the free queue really is before you invest time in the listing.
• Check what the paid tier actually adds. Sometimes it is only a faster date. Sometimes it includes a newsletter mention or a featured slot.
• Watch for invoices or "orders" created during a free signup. A zero-amount invoice is usually harmless, but read it so you know what you agreed to.

A long free queue is fine if you are planning ahead. It is a problem if you need the launch to happen this month.

What a real batch of submissions looked like

Here is what I saw when I submitted one product to a set of free platforms on October 20, 2026. Queue times and link attributes change, so treat this as a snapshot and check again before you rely on it.

Two lessons stood out. The listings published on the same day used different link attributes, so speed told me nothing about the link I would get. And tracking verification emails and expiring login links took more time than filling in forms.

Dofollow, nofollow and what a link is worth

If part of your goal is search visibility, look at how the platform links to you. Open a listing for an existing product, inspect the link to its website, and check the rel attribute. Google treats nofollow, ugc and sponsored as hints about how to consider links in Search. They identify unendorsed links, user-generated content and paid placements. "Dofollow" is just the informal name for a link without any of these attributes. Such a link may contribute to rankings, but its SEO value is not guaranteed.

A few other things are worth checking while you are there:

• Is the listing page allowed in the index? Look for a noindex meta tag or header. This is separate from robots.txt, which controls crawling, not indexing. Google has to be able to fetch the page to see a noindex rule at all.
• Can the listing's content be seen after the page renders? Google can render JavaScript, but content that remains unavailable after rendering may not be indexed.
• Does the listing stay up permanently, or does it disappear after a launch window ends?

A nofollow link from a platform with the right audience can still be worth more than a dofollow link from a directory nobody visits. Treat link type as one factor, not the whole decision.

Badge requirements and other strings attached

Some directories ask you to place their badge or a link back to them on your site before they publish your listing, or in exchange for a faster review. This is a trade. You give them a link from your site, and they give you a listing.

Decide in advance how you feel about this:

• Do you want third-party badges on your landing page at all?
• Will the listing be removed if you take the badge down later?
• Is the platform reputable enough that you are comfortable recommending it to your own visitors?

Google's spam policies name two practices here as link schemes. One is excessive link exchanges. The other is requiring a link without giving the site owner the choice of qualifying it, for example with rel="nofollow". So if a directory demands a badge link and forbids you from marking it, the requirement itself is against Google's rules. If you add a badge link, mark it with an appropriate rel value, and don't build a launch strategy on swapping links.

Review times and moderation

Some platforms review submissions manually, while others publish instantly. Review times and publication queues vary, so check both before submitting. A queue of several months does not necessarily mean several months of moderation.

Keep a simple log of every submission. Without it you will lose track quickly, and you will not know which platforms are still pending and which quietly rejected you. A plain table is enough:

Use one email address for all submissions, and store passwords in a password manager, not in the log.

Prepare your listing once, reuse it everywhere

Most submission forms ask for the same things in slightly different shapes. Prepare them once in a single document:

• A one-line tagline. Plain words, no hype. Say what the product does and for whom.
• A short description. Two or three sentences that a stranger could understand without visiting your site.
• A longer description. What problem it solves, how it works, what makes it different, and who it is not for.
• Pricing. State whether the product is free, freemium or paid, and include the starting price.
• Assets. A square logo, a few screenshots at common sizes, and optionally a short demo video or GIF.
• Categories and tags. Pick the honest ones, not the most popular ones.

Here is the difference between a weak and a usable tagline for a hypothetical invoicing tool:

• Weak: "The ultimate AI-powered platform revolutionizing finance."
• Usable: "Simple invoicing for freelancers who bill in more than one currency."

Write the copy so it would still be true if a user read it after signing up. Overpromising costs you trust later, and some moderators reject listings that read like ads.

Measure what the launch actually did

Launch day upvotes are visible and exciting, so it is tempting to treat them as the score. But votes alone tell you little about activation, retention or willingness to pay.

A more useful habit is to check each platform twice, counting from the day the listing is published, not the day you submitted it:

• After 7 days. Visits from the listing (add UTM parameters to the link if the platform allows it), signups, and the quality of any comments or questions.
• After 30 days. Whether those users came back, whether anyone paid, and whether the listing still sends any traffic at all.

Qualitative feedback helps too. Comments that address the idea, the execution, the design and the value of a product tell you more about what to fix than a vote count does.

A short checklist

Before you submit anywhere, ask:

1. Would the people on this platform plausibly use my product?
2. How long is the free queue, and what does paying actually change?
3. Is the link dofollow or nofollow, and is the listing page indexable?
4. Is there a badge requirement, and am I fine with it?
5. How long is review, and have I logged this submission?
6. Is my listing copy honest, clear and ready to reuse?
7. When will I check the results, and what will I measure?

Launching is less about finding the one perfect platform and more about choosing a handful of good fits, preparing well, and measuring what happens afterwards. If you want one more place to try, RadarMakers is free to submit to and is experimenting with ratings for idea, execution, design and value. It is early, so the audience is still small.