Loading the next useful route.
Loading the next useful route.
Launch guide
Use this to choose the right market, learn from customers before public launch, and build trust and distribution across borders.
Choose your first market, learn from customers, and launch from a European base, with practical lessons from European companies that took different routes.
Best for founders based in Europe who want to sell into Europe, the US, or an internet-native global market
Action checkpoints
Start with these sections when you want the practical moves before reading the full guide.
Europe can be the base, not the boundary
Thinking globally from day one does not mean launching to everyone. It means choosing the strongest market for the problem before your location chooses it for you.
Your European city can provide teammates, peers, and introductions without defining who buys the product. A founder meetup in Berlin might help you improve a demo. It cannot tell you whether a buyer in Boston needs it. Start with the people who feel the problem most strongly and can act on it.
Europe-first
Name the country, sector, and buyer. Language, procurement, regulation, and trusted channels can differ between neighboring countries.
US-first
Learn the intended customer's workflow, budget, buying process, and working hours. Your European network can open doors, but it cannot stand in for US customers.
Internet-native
Start with a shared job, such as maintaining an open-source package, rather than a country. Test access, documentation, and support with people outside your own network.
Start narrow
Choose one first market and one launch goal: customer conversations, a paid pilot, product use, or technical contributions. Write down what evidence would justify expanding.
Ask about what actually happened
Do not spend months preparing a public launch before learning how the intended customer handles the problem today. Ask about the last time it happened, not whether your idea sounds useful.
Then put the smallest usable version in front of them. Watch where it stops making sense without your explanation, and keep their words for the launch page.
Langdock's first launch became customer research. In its founder-submitted YC launch, the team wrote that an initial tool for creating LLM plugins gained a few hundred users, but conversations with them exposed a sharper enterprise problem around compliant AI access. The Berlin team redirected towards that problem. A first launch can be useful even when it reveals that the stronger product is not the one you started with.
A public announcement is not always the next step
A launch can bring feedback, customers, contributors, or credibility. Pick the form that helps someone take the next real step, not the one that looks busiest online.
If nobody has tried the product, start with direct conversations and manual onboarding. If the core flow breaks or exposes private data, fix that before inviting more people.
B2B software
Show a costly workflow getting easier. Ask for a demo, trial, or pilot. Legora spent nine months developing alongside lawyers at Mannheimer Swartling before it was ready to launch commercially; a small set of design partners may teach you more than a broad announcement.
Developer tools
Make the product runnable, with documentation, an example, and a clear installation path. Ask people to use it on a real project or contribute.
Consumer products
Show a result someone wants to use, save, or share. Make the first useful action easy instead of stopping everyone at a waitlist.
Deep tech and regulated products
A benchmark, technical paper, approval, deployment, or paid pilot may matter more than a public launch. Black Forest Labs launched the company and FLUX.1 together, with a pro API, non-commercial open weights, an Apache-licensed fast model, and day-one routes through established developer platforms.
Marketplaces
If customers would arrive to an empty product, recruit enough relevant supply before attracting demand. Bolt's founder says he first tested rider demand, then persuaded roughly 50 Tallinn drivers to register their interest before he started building the app.
Remote when it works, present when it helps
Selling in the US does not automatically mean moving there. It does mean making it easy for a buyer to understand, evaluate, and use your product from where they are.
Use European communities for introductions and peer learning, and trips for specific customer work. A nearby conference full of other founders is not a substitute for meetings with your actual buyers.
Dryft is a useful boundary case, not a default to copy. Its German founders chose San Francisco for the core team while working with manufacturers in Europe and North America. Co-founder Anna-Julia Storch has described the concentration of technical talent, an engineering-first environment, and people willing to relocate as important reasons. Start from Europe when it already gives you the customers, team, and operating conditions you need. Reconsider the base only when repeated evidence shows that one critical constraint cannot be solved through focused travel, remote hiring, or a smaller local presence.
Working hours
Agree on a realistic support window. Put time zones on booking links and recheck meeting times around daylight-saving changes; do not imply round-the-clock coverage you cannot provide.
Language and examples
Use the customer's terms, workflow, and references. Translate onboarding when a real user group needs it and you can support that language afterwards.
Buying and trust
Show the price currency, contracting entity, support contact, and relevant security answers. Establish who needs which customer data and why; a reassuring badge is not a substitute for an accurate answer.
Travel
Go for booked customer visits, an implementation, or an industry gathering with relevant buyers. Several weeks near a market can test the value of proximity before a permanent move.
Local presence
Consider hiring or opening an entity when repeated sales or support needs justify it, not for appearances. Verify the legal and tax implications with qualified advisers.
From explanation to useful action
Tell a stranger what the product does, who it is for, and what changes when they use it. A starting point: [Product] helps [specific user] do [specific job] without [current workaround].
Pair that sentence with an honest demonstration. Show a workflow completed, a command producing useful output, or one input becoming something worth saving. Keep the bigger company vision for people who want to know more.
Lovable started with GPT Engineer, an open-source tool for developers. After it drew strong attention, the Stockholm team turned the idea into a commercial web product for non-technical users; the repository has since passed 50,000 stars. The lesson is not to chase stars; it is to let a working first artifact reveal who else wants the outcome and what access they need.
You do not need every platform
Pick a small number of channels you can participate in properly. Base the choice on customer behavior, not the platforms your founder friends happen to use. Track links you control so you can connect visits to useful actions.
Check current platform guidance before posting. The notes below are preparation reminders, not a promise that the rules will stay unchanged.
Direct outreach
When you can name the buyers, write to a specific person about their workflow. Check the outreach rules for the market and channel; do not add people to a marketing list just because they replied.
LinkedIn and X
Use LinkedIn when buyers and operators discuss the problem there; use X when the relevant developer, AI, design, or product community is active there. Show the product and stay available for questions.
Product Hunt
Prepare the account, page, media, maker comment, and feedback goal. Use a direct primary product URL, not a shortened or tracking URL. Ask for feedback, not upvotes. Its launch day follows Pacific time, so plan team coverage accordingly.
Show HN
Share something non-trivial you made that people can try, not just a signup page. Avoid unnecessary signup barriers. Never solicit votes, comments, or submissions; write replies yourself, because HN prohibits generated or AI-edited text in comments. A minor feature update is generally not a new Show HN.
GitHub
Treat the repository, documentation, examples, release notes, and install command as part of the launch. Give contributors a clear way to report problems or help.
Communities
Choose groups where intended users already participate. Explain why the product belongs there and ask moderators when uncertain, rather than dropping the same link everywhere.
Newsletters and media
Pitch a relevant editor when you have actual news, a useful technical explanation, or a customer story you have permission to share. Match the angle to their audience.
Give each person a real reason to share
Several relevant people talking about a product can help it reach beyond the maker's own network. You do not need celebrity accounts. You need people who understand the problem and genuinely want to share what you made.
For willing contributors, prepare a short brief with the product link, demo, checked facts, and intended audience. Let them choose their own words and whether to post. Do not turn help into an obligation or imply independent enthusiasm where there is a commercial relationship.
Juan of Ark Media describes this as a coordinated first wave followed by a second wave the product has to earn. The useful part is giving willing supporters the same checked facts and product moment while letting them choose their own angle. His reach figures are self-reported, so use the structure as practitioner advice, not as a result to expect.
Maker and early users
Explain why the product exists; let willing users describe their actual experience. Do not supply invented praise or results.
Relevant connectors
Ask people who know the sector or target market for an introduction, feedback, or a relevant place to share. A local peer, customer, or niche newsletter may be more useful than a large general audience.
Clear relationships
Make paid, gifted, or employment relationships clear when endorsing the product. For US audiences, check the FTC disclosure guidance below; check applicable rules in other markets too. This is a general reminder, not legal advice.
After the announcement
Answer questions, fix problems, and share real examples with permission. Publish again for a meaningful improvement, customer result, or new market, subject to each platform's repeat-launch rules.
Decide what success means before posting
Choose one primary metric tied to the launch goal. Track a few supporting signals to understand where people stop. A lot of views with no useful action is a different problem from a small audience that keeps using the product.
Reach and interest
Did the intended audience see it, click, reply, read the docs, or request a demo?
First useful action
Did people finish the task, get a usable output, or run the tool on their own project?
Commitment and return
Did they pay, complete a pilot, contribute useful work, or come back? Distinguish a non-binding letter or download from payment and repeated use.
Learning
Review after the first wave and again after the product's natural usage cycle. Decide what to change in the product, audience, price, onboarding, or next launch.
Founder-reported case
Peec AI is a Berlin-registered AI search analytics company. In a 2026 interview, co-founder Marius Meiners described building a rough prototype in a day and a half, using it to secure roughly eight letters of intent, bringing in his technical co-founder, and building the production product in roughly six weeks before its February 2025 launch.
The sequence matters more than the speed. The prototype was good enough to test a concrete workflow, the letters required more action than a compliment, and the production build followed that evidence. Meiners also calls the letters non-binding, so treat this as founder-reported evidence of interest, not as revenue or guaranteed demand.
Problem timing
Meiners saw leading SEO practitioners begin discussing how ChatGPT Search could change discovery and chose that emerging problem as the wedge.
Prototype
The first version let a user submit prompts, query model APIs, and see which brands appeared and how they were described. It was enough to make the proposed workflow concrete without pretending to be the finished system.
Commitment
Roughly eight prospective customers signed non-binding letters of intent based on that prototype. This filtered for people willing to take a small administrative step, but it still did not prove payment or repeated use.
Production and launch
The technical co-founder then built the production product in roughly six weeks. Peec launched in February 2025 and started selling immediately, according to the founder interview.
What to borrow
Put a narrow, working representation of the product in front of people already feeling the problem. Ask for the strongest honest commitment available before expanding the build.
What not to copy
A fast prototype, an LOI, and an emerging category can all produce misleading enthusiasm. Define what evidence comes next, such as a paid pilot, completed work, or repeat use.
Founder-written case
In June 2019, n8n founder Jan Oberhauser published the first version on GitHub and shared it on AlternativeTo and Quora. People began reporting issues, opening pull requests, and emailing him. He spent the next few months learning from that use before taking the Berlin-based product to a wider audience on Product Hunt and Hacker News in October.
This was not one big launch day. The first release made the product usable and opened a feedback loop; the later launch amplified something people had already run and helped improve. n8n describes its model as fair-code, so treat it as a source-available developer-tool example rather than a template for every open-source project.
First audience
n8n started where people were already looking for software alternatives and automation answers, rather than trying to appear on every launch platform at once.
Useful first action
Publishing runnable software on GitHub let people test it on their own workflows. The signal was not merely traffic; it included issues, pull requests, and direct messages.
Time between waves
Oberhauser used the months after the first release to fix shortcomings before the wider Product Hunt and Hacker News launch.
Contribution path
A public repository, integrations, documentation, examples, and clear ways to report problems gave users more ways to deepen their involvement than a launch-page signup.
What to borrow
Give a narrow technical audience something real to run, watch what they try to change, and widen distribution after the product survives use outside your own machine.
What not to copy
A public repository does not create a community by itself. Licensing, documentation, maintenance capacity, and the right first audience still need deliberate choices.
The practical takeaway
Fill this in with your own answers. Use the examples for the level of specificity, not their targets. If an answer is missing, name the next conversation or test that will resolve it.
There is no universal countdown: a small self-serve tool and a regulated product need different preparation. Use this brief to decide what must work before wider exposure, then review what actually happened afterwards.
Customer and market
We are starting with [specific users in a country, sector, or shared technical community] because [observed problem].
Goal and evidence
We want [one result]. We have learned [actual behavior or commitment]; we still need to test [uncertainty].
Claim and demonstration
We help [user] do [job] without [workaround]. We will show [working example] and ask them to [one next action].
Channels and helpers
We will use [a few places these users already follow]. [Willing people] can contribute [their own experience or relevant introduction], with appropriate disclosures.
Access and support
Before posting, [owner] checks [core flow, permissions, pricing, and onboarding]. We can support [languages and hours]; [named market requirement] still needs review.
Measure and review
Our primary metric is [useful action or commitment]. Review [after initial responses] and [after the normal repeat-use interval], not only on launch day.
Next step
If we see [result], we will [change or expand]. Our next update will be based on [real use, a fix, or a new finding], not another version of the same announcement.
Stay close to the signal
Event picks, useful Europe updates, and the occasional interview or video.