Ramle. My first project to get 1,500+ registered users.
The story of how we built Ramle, an app for finding friends. How we got our first real traffic, tried to figure out monetization, product metrics and mobile, and eventually shut the project down. Plus a bit about vibe coding, the cold start problem, and things we probably should have thought about before we even started building it.
Background
A year ago, when I moved to a new city for university, I ran into a problem. It was pretty hard to find some kind of social circle. I never really managed to become friends with my classmates, same with people I met at events, so I started wondering how you are even supposed to find someone with similar interests. Before that, I had some experience working at a startup, classic AI stuff that helped track the work of sales teams. After that startup I got really into the whole product scene. I did not really want to go into outsourcing anymore. I wanted to work on a product or build something of my own. So, following all the classic startup rules, I started researching the problem and the market. At first I could not find any international competitors at all. But, jumping a bit ahead, I later randomly came across a whole bunch of mobile first startups. They ranked pretty badly for the keywords I was searching for, so I only managed to find them after stumbling across one, and then found the rest through recommendations.
In Ukraine, one of the more or less popular ones was Hvirtka. The project had some pretty serious UI/UX problems, but there was at least some demand for it. So I decided to make my own version of an app for finding friends, without dating mechanics like swipes, diamonds for likes and all the usual bullshit you see in Tinder, Badoo and similar apps. I called the project Ramle.
The business plan that never existed
When we started development, the market itself was not really researched properly. And for some reason, the fact that I could not find a bunch of direct competitors did not raise any red flags. Everything was built mostly on a gut feeling that it should take off, at least in Ukraine. I did not really think much about user acquisition back then. It felt like I would make a few posts on Threads and people would just show up. Only when I actually started trying to get the first users did I realize one thing: being able to make content and sell in the era of vibe coding is an insanely valuable skill. Building a product that can theoretically be useful to people and that they might even be willing to pay for is not some insanely hard task anymore. But getting traffic to it is a completely different story. By "getting traffic" I mean that when you are building a product, you more or less understand how to get from point A to point B. But when you are trying to bring people in, it is more like who knows. Will the post work or not, where do you even get traffic from besides social media, and so on. Of course, I am saying all of this from the perspective of a developer who did not really have much experience with promoting projects before.
The economics of friend finding apps work differently depending on the product. Some make the freemium so limited that it basically forces you to buy a subscription from the first few minutes because the app is painful to use without it. For example, they give you only a few friend requests per day, heavily limit interactions, or stuff the app with so many ads that you just want to delete it. Others monetize through all kinds of diamonds and similar stuff, pretty much like classic dating apps. You can pay extra to send a message together with a like, send some kind of super like with text, and so on. My own view on monetization kept changing during development. At first I wanted to make the whole product completely free and make money from paid commercial events.
Later I realized that you still have to somehow get to that point first, and it was not really clear where to find clients who would actually pay to promote their events on ramle. So I started looking more at the Hvirtka model, just less painful. Basically, keep a normal freemium that you can actually use, and then offer a cheap subscription, something around the price of 1 or 2 coffees, with some extra features. For example, seeing who viewed your profile, getting some kind of badge, being able to send more friend requests, and so on. In the free version, you could send up to 40 requests per day and have up to 20 active requests at the same time. So if you were just using Ramle normally, that should have been enough. And if you were super actively looking for people or wanted some extra features, then you could move to the subscription.
It all started with the web
The team was two people: a backend developer and a frontend developer. I had pretty limited experience with mobile development and had never built an app from scratch or taken one all the way to production. So we decided to start with the web version.
The screenshots I attached already show version 2.0. We did not have any ready design or template, so we basically had to come up with everything ourselves. It started with generating landing pages using Claude and Gemini. After dozens of generations, I finally got a version that looked good enough and started developing it further. We removed a couple of sections, generated a few new ones, I moved everything from HTML + CSS to Next.js + Tailwind, and a few days later we had the first decent landing page. Then we moved on to the actual platform. We put together the basic APIs in Django and a basic UI/UX. We decided to drop the standard email + password login and go with Google OAuth, with Apple ID planned for later, because it is just way more convenient. In about a month we managed to put together a normal working version that was ready to be shown to the world.
But after the release, silence. Nobody rushed to sign up.
Mom, I'm a vibe coder!
The whole app, from the frontend and mobile app to the backend, was written with Codex and Claude. Of course, there were moments when I had to fix some code by hand, but that was literally around 1%. Code quality in an app like this was not super critical for me, but surprisingly we still ended up with a pretty decent architecture, especially on the web side where I actually knew what I was doing. The small problems started in places where my expertise was already running out , but not completely. For example, the mobile app in Expo. It was a new framework for me, although in some ways it reminded me of Next.js. So, long story short, I had to burn a bit more tokens than was actually necessary.
I attached a screenshot from my Codex profile where you can see the total number of tokens used. The first version of Ramle took somewhere around 1.5M tokens. My longest streak was 47 days. That was basically the period when I was nonstop building Ramle. From the stats you can probably tell that I prefer Codex, but sometimes I used Claude for changes related to design.
Mykhailo, the other developer who was building the backend, says he prefers Claude for development over other models, so basically our entire backend was written with Claude. I do not know the exact number of tokens spent on the backend, but I think it was at least two times less than Codex, which was handling both the frontend and mobile app at the same time. We both had the standard $20 subscriptions and that was more than enough. During development I also used different tricks for speeding things up and saving tokens that I picked up along the way. I will probably write about those separately in future articles.
The first and last good traffic
SEO is obviously cool, but it usually starts working more or less after around 3 months. So I had to remember where indie hackers usually post their projects: Reddit, X, TikTok, Product Hunt, YouTube and so on. I started actively trying to run social media. Started with the classics, Threads and X. Made posts on X and Threads, did the classic Product Hunt launch and... nothing worked. Traffic did not magically start flowing in, and we got zero registrations.
At some point, while scrolling Telegram, I randomly came across a post about us on dev.ua. I was super surprised that somehow someone had even found out about us and posted it in a Telegram channel with 20k+ people. Literally within 2 or 3 days, more than 100 people came in who did not just click "Sign in with Google", but actually completed onboarding. And this continued for about a week, with 100 to 200 new people joining every day from all over Ukraine. At one point traffic reached around 1k people per day, and for me that was just insane. I had never seen anything like that live in Google Analytics on one of my own projects before. So I was just grinding 12+ hours every day purely on enthusiasm.
The traffic scheme, as far as I understood it, was pretty simple. dev.ua apparently has bots that parse different sources, and based on that they pump out a bunch of posts every 20 minutes or so. Their post got picked up by other media that also wrote about us. Then it spread across a bunch of other websites and channels, which ended up bringing us a pretty good amount of traffic.
The traffic was good, obviously. But the profit from it = 0.
My favorite product metrics
Throughout development, one thing kept bothering me: we could not properly see the user funnel, from clicking some post and going through onboarding to whether that person actually became an active user. And activity itself can already be defined through certain events that the user triggers inside the app.
If someone is not familiar with this stuff, basically all analytics is built around events. Page view, closing a page, clicking a button, some specific action inside the app, and so on. Microsoft Clarity, for example, lets you watch a recording of a user session and literally see how someone behaves on the website. This is actually super valuable because you can understand where something goes wrong for the user, where they think something should be clickable but it is not, where they get stuck, or where they never even get to. You can also look at heatmaps and see where people click the most. Another thing I realized is that if a user runs into some problem, they probably will not message you about it. They might just leave a bad review without explaining why. If something like that happens, it should be logged as some kind of trigger that something in the app is wrong.
Once you have the events, you need to build funnels and charts from them. And doing that in Google Analytics without pain is pretty hard. We also had problems collecting backend events. So we decided to add PostHog as well. It turned out to be way better for this kind of stuff. You can collect events from both the frontend and backend, build funnels and charts, and their built in agent can even help generate them from the events you already have. There is one downside though. Once you start sending a lot of events, PostHog gets pretty expensive. Google Analytics is free.
I regret that we did not build proper product dashboards right from the beginning. We could have seen much earlier where the bottleneck in the app was and at what point people were dropping off.
Mobile vs web
These are stats for the current year, but the picture was almost exactly the same during the first week. Most of the traffic came from phones, with only a small part from computers. So I immediately started working on making the web version properly usable on mobile. During that first week we also started discussing a mobile app, but first wanted to see how people would behave further. There was also the hardware problem. Anyone who has ever developed a mobile app probably knows the difference between doing it on Windows and on a MacBook. I do not know exactly why, but even on a pretty powerful PC the emulator can lag, while on a Mac everything runs really fast. So pretty quickly we started checking marketplaces for an M1 Mac. Once I finally had one, it took a little less than a month to get the first mobile version ready. But then came another problem that took roughly another month to deal with, publishing to Google Play and the App Store. For Google Play, we had to find 20 beta testers who would use the app for 14 days. For the App Store, we just had to survive the painful review process for the first release. We found beta testers among our users who agreed to help, plus some family members. Super thankful to everyone who helped. The App Store was a different story. They kept rejecting the app because something did not fit Apple’s rules, and after every submission I had to wait around two more days.
The app finally launched, but no miracle happened. The web audience was very hard to move over to mobile, and getting new traffic directly into the app was not really working either. The last option was to try paid traffic through targeting. I ran Meta Ads for our main audience: Ukraine, Kyiv, 20 to 45 years old, Android. After a few days of testing, the numbers showed that one person who installed the app and completed onboarding cost around $1.4. Of course, I only ran the test for about 5 days with a small budget. You can imagine that with more time the algorithm could optimize, some other factors could improve, and maybe that user could eventually cost somewhere around $1 to $0.8. But that was still too much. The thing is, even that $1 does not guarantee the person will stay. They can literally leave after a few days because there is not enough content, not enough people nearby, or they simply do not like the format. So you either need a decent budget or some kind of marketing instinct to get the whole thing moving and reach a critical mass of users. The classic cold start problem, which I only properly learned about somewhere halfway through the whole story.
Shutting down Ramle
This is not really the time anymore when you can send one newsletter and get 1k users in a day. I also noticed a pattern with investors where a lot of them simply do not want to invest in social apps at all. And honestly, it makes sense. Getting something like this to profitability is a real pain, especially while trying to make sure the project does not just die somewhere along the way.
Building a startup with two technical people in the team also turned out to be not the best combination. I tried taking on sales, marketing and basically everything else that was needed, but as you can probably tell from this story, doing all of those roles at the same time did not work that well.
Maybe shutting Ramle down did not even make that much sense. The maintenance cost was around $16 per month, basically hosting + Google Workspace. So technically the project could have just kept running for a long time. But I also did not really want to keep dragging around dead weight when I no longer understood what to do with it next. So at some point we just decided to shut it down.