DEV Community: Alex Sinelnikov

How to improve your waitlist landing page and get more signups?

Alex Sinelnikov — Fri, 07 Nov 2025 12:11:44 +0000

Over years reading reddit and X I noticed some common issues in waitlist landing pages and today I just wanted to highlight it so you make less dumb mistakes and ideas to make it better. To save few words, I will name waitlist landing page as just landing page. Lets go:

Too generic heading - This is a problem for most waitlist landing pages. Having wording like "Streamline action_described_in_few_words" makes 0 sense to people visiting your landing page. It should be more simple, and more clear explanation. Is your app helps to create invoices automatically? Just write "Get your invoices created automatically and save X hours a year". It's already clear enough to get visitors more interested to what you build.
Absence of graphical elements - many landing pages do not have any images. With generic heading, this makes your landing "yet another generic HTML page" with no value at all. Just add screenshot from your WIP app or even Figma design. Show your users what exactly are you building. Combined with clear explanation, it can already be a huge conversion boost
Generic Design - another problem of many landing pages since most just vibe code it without putting any effort. There are tons of free and paid landing pages on internet. Pick any you like - change color scheme and you have unique landing page. The same thing applies to logos. Don't fucking use emojis as your logo! It's dumb and cheap, showing you don't really care about your product. Try to use icons instead of emojis. Arrows, etc - there are tons of free icon packs, just pick one you like and use it. Most even provide SVG to copy from browser, so no need to install anything.
Platform subdomain - many people not even visiting apps with domain like xxxx.vercel.com or yyyy.netlify.dev. Spend $15 for custom domain. Having custom domain will add more credibility to your app
Social proof - its nice to show # of users who signed up. If you don't have many - ask few friends to sign up and just use their avatars as social proof until you get more waitlist signups.
Features section - its not mandatory, but its nice to have features section where you describe what features will you have on launch. This is another reason for users who really interested in what you build to actually join waitlist
FAQ - Another section which can be useful for some products. Here you can explain some aspects of your app, or how are you different from other similar apps.

Having those bullet points in mind, you can craft a very attractive waitlist landing page. When building your landing page - you need to understand a simple concept - why would anybody sign up if I didnt put enough effort to build good landing page to attract customers. Another thing to keep in mind - you can convert good waitlist landing page into real landing page by adding few more sections, pricing, etc, saving yourself time & money later on launch day.

Few more tips:

Have your users to confirm their email. It will filter out spam emails, bots, but also users who aren't really serious about your app. There's literally 0% chance you can convert them later - I tested that myself, and it does not work at all. You can wrap that confirmation email into something like "Please confirm your email so that I could send you more product updates and eventually invitation when we launch". Don't fool yourself with just # of emails in database, you only care about those who will convert.
Share updates, build excitement. In my recent 2 apps I added release notes widget with big button next to waitlist form where visitors could see the progress. I found a tool called updatify. I tried to post at least once a week, and in few months I had enough updates to call it "build in public". Furthermore, I also was sending emails each month. I simply just put together all my update posts and using same tool was sending emails to users on my waitlist.
Do not delay your launch. Try to make sure you launch no later than 3-4 months after you launched your waitlist page. After that time many users will probably find alternative to your tool or just will not need it at all
Add analytics. Track visits, and try to see what kind of promotion works best for you. If you have visitors but not sign ups - that means something wrong with your landing page, value not clear or it's just buggy. You can spot it long before you launch the app and get some feedbacks.

I hope these tips will help someone to actually build better converting waitlist landing page.

How I switched from ruby to elixir and to learn it better — built a product

Alex Sinelnikov — Thu, 23 Oct 2025 09:27:36 +0000

Hey everyone! In this post I wanted to share some of thoughts from my learning process. I’m developing apps for about 15 years, with main lang — ruby and ruby on rails framework. Over my career I worked with pretty much everything — embedded development, mobile, desktop, web.
I know about elixir since 2017 or so when I first saw Chris McCord vid on YouTube about Phoenix. Always wanted to try but never had a chance. Last year I decided to build a product for my own needs and thought what if I use Elixir/Phoenix for that.

To start — I decided to use boilerplate. I won’t be sharing the name, but overall I wasn’t really happy about it. I had to rewrite about 70% of code because it simply didnt work for my needs, even though my app isnt that special and doesnt have anything non standard. Its simply code wasn’t really extendable or reusable, so for my next product I will probably just start with empty PHX app.

It took a bit of time to get used to Elixir functional approach. I could not understand Quote/Unqoute concept until very recently, but that didnt stop me from implementing most of my app with out it. Ecto concept was always not the most pleasant. While I understand why it was made that way, I had cheatsheets always with me simply because I could not memorize function names and arguments, esp when you can use macro syntax for things like select, etc.

LiveView is miles ahead of Rails’s turbo. At some point I was even overusing it for simple UI interactions such as opening dropdown, etc. Later I refactored code to use Alpine.js for everything UI related and I’m happy about that. Hooks are really nice addition too, but I only used it once in my case. Just LV and Alpine.js was enough for me. I live in Europe, but I host app on DO in NYC region and have no latency issues with LV. I even tested it through few VPN connections to add some latency and it was working better than most modern react based apps. And overall I was happy with ease of use. I don’t really understand complexity made with layouts(root, live, app) so took a bit to get used to it.

ObanJob was nice surprise for me. Finally I didnt need to run another instance of app for background jobs(hello sidekiq) and it required 0 extra infra or maintenance. Maybe for big queues it would made sense, but I have few jobs running every few mins, so it works well.

I had issues with deployment. There are few ways to deploy apps and I went with dockerizing compilation. Dockerfile was pretty simple multistage build, but when running I had OOM errors on my 4gb instance. After hours of googling and debugging I found this ERL_MAX_PORTS=1024 which solved all my memory issues. It was just a message on elixir forum without much explanation.
Testing tools are a big rough. Rails has many useful gems to help with it like factory bot, etc. ElIxir/Phoenix seem like a bit behind in this terms(but I might just didnt find good tools or good approach).

What I really like — elixir’s case statement. Handling different call results not much easier because of pattern match. So things like {:ok, result} -> … {:error, message} -> helps to handle errors much easier. And overall pattern matching feature is super useful and helped me to write really good code comparing to same in ruby. It’s also nice Phoenix has generated authentication code. Unlike from devise — it has minimal implementation, but it’s really quick to add anything you need. In my case I added google/github authentication in just few hours.

Some of recent updates made regular controller/template/views a bit weird for me. For some reason now templates, views and controllers under same controller folder making it really hard to manage it, would be nice to have separate folder for templates/views outside of controllers.

The app I build — updatify.io is a release notes tool where you can embed widget to your web app. I also used LV to power the widget. I have some JS code to create modal, but then it just creates iframe inside with LV powered app. I was afraid it will be tricky, but it just works out of box.

One of the features — blog which you can host on subdomain — took a bit of time to get sorted with subdomains. I came up with few plugs that helped me to serve requested blog on subdomain, and it was one of first things I covered with tests because I still feel like it could be done better. For some 3rd party services there isnt a package, so I had to write my own harness, but its not that hard and mostly can be done in matter of hour.

I also had few back and forth with image uploads. Originally I stored them in app, but eventually decided to move to CDN, because it was simply cheaper($5 for DO Spaces). Took a bit to understand ho presign_ function works and thats first time I used hooks. I still don’t really like how its implemented and I feel like it could be done easier

Overall I’m really happy with my elixir/phoenix experience. I already pitched this tool for another paid project I’m about to start. The biggest complexity was to convince client there’s enough developers on market to support it. For my own projects I plan to use it more. I’m not sure how well it will work just of API type of projects, since LV is a big part of framework and one of reasons people like it.

Added: I tried LiveViewNative few months ago. Saw Dockyard CEO post on twitter and gave it a try. Its in very early stages of development, but it can definitely has its own audience and niche. Its not be used for apps where you might be offline, but I feel like e-commerce type of apps could benefit from it