Mistakes We Made While Building a Startup: The Roomrr Story

A familiar name felt like a finished decision.

When we first needed OTP messages, we went with Twilio. It was a name we knew, a popular service, and it felt like the obvious choice. We thought: great, OTPs are sorted. One less thing to worry about.

Looking back, we were caught up in the hype. We focused on whether the service could send messages and did not spend enough time understanding what it would cost us to use and test it for our users in India.

Testing is not a one-time event when you are building an app. You sign in again, test a new device, fix a bug, try the flow once more and ask someone else to do the same. Those little checks add up.

Testing told us what our research should have.

After spending money on testing alone, we realised Twilio was an expensive option for our India-focused use case. That was not a fun discovery for an early-stage team watching every expense.

About fifteen days before our planned launch, we started looking for alternatives. Suddenly, a decision we thought was behind us was back on the table, alongside everything else we needed to finish. It added stress at exactly the time we had hoped things would be getting calmer.

The lesson was simple: check the pricing for the country you actually serve, estimate the cost of development and testing as well as real usage, and compare options before calling the problem solved. A service can be good and still be the wrong fit for a particular budget or market.

We knew we needed payments. We did not understand the whole route.

Our next mistake came from half-knowledge about payments. We chose Razorpay because it is a good service, but we had not fully understood what our particular payment flow required.

For Roomrr, we want a tenant to pay rent through the app and have the money reach the owner or university providing the accommodation, while Roomrr helps with the payment experience and keeps a record of what happened. That is a core part of what we are building, not an extra feature we can casually leave for later.

As we looked closer, we learned about Razorpay Route, a feature designed to route payments to linked accounts. We also learned that Razorpay’s Route eligibility requirements include a domestic turnover above ₹40 lakh, or an export turnover above ₹5 lakh, along with other checks. We are an early-stage startup without that turnover, and we are asking Razorpay about our options.

Finding that out late made us lose our minds a little. With launch approaching and payments central to Roomrr, we started looking for alternatives as quickly as we could. The mistake was ours: we had looked at the gateway, but had not checked access to the exact settlement feature our model needed.

Razorpay itself is not the problem here. The lesson is to ask how the complete flow works—from the person paying to the person receiving the money—and whether an early-stage business can actually access it before building around it.

We are still learning, and that is part of the story.

Neither of these moments felt particularly inspiring while we were in the middle of it. One cost us money during testing; the other sent us searching for a payment solution under pressure. Both made it clear that a recognisable name is not a substitute for checking the details.

Going forward, we want to ask better questions earlier: What will this cost in our market? What will testing cost? Are we eligible for the feature we need? What happens from the first tap all the way to the final result?

We will make more mistakes while building Roomrr. The important part is to notice them, be honest about them, and use what we learn to make the next decision better. That is what we are doing now—and we will carry these lessons with us as we move towards launch.