A year ago I launched DialHard, a browser-based service for making international phone calls to regular landlines and mobiles. No app, no download. You open a webpage, enter a number, click dial. The person on the other end picks up a normal phone call.
Some numbers after a year
* ~€600 MRR, ~1,400 registered users
* 60%+ of call traffic goes to the US, rest split between Germany, France, Singapore, UK, Australia
* Credit-based PAYG, starting at $0.03/min or PRO plan for $29/mo
* Live closed captions to actually understand what's the clerk on the other end saying
* Built and run entirely by one person (I also have a full-time day job)
Stack: Rails, WebRTC, Twilio for PSTN termination, Stripe for payments. Event-sourced architecture that took several iterations to get right
Infrastructure cost is low. Twilio charges per minute so my costs scale linearly with revenue
What I learned
The product-market fit is narrow but real. The people who need browser-to-landline calling really need it, phone interpreters who work hours at a time, expats dealing with government offices that don't answer email, people stranded abroad who need to reach a car rental or insurance company right now. These aren't hypothetical use cases; they're actual support emails I've received. But this audience isn't growing. Most person-to-person calling has already moved to WhatsApp, FaceTime, etc. What's left is the long tail of situations where the other side only has a phone number.
IRSF fraud is real and will find you. Within the first few months I lost about $100 to automated calls to premium numbers in places like Guinea and Sierra Leone. Not a lot of money, but enough to make me build a destination blocklist and velocity limits. If you're building anything that terminates calls to the PSTN, budget time for this.
Telecom is operationally unglamorous. There's no viral loop. Nobody tweets about their calling service. Growth is slow, mostly organic, mostly from people who google "call international number from browser" and find me. I posted on Indie Hackers when Skype shut down and got a small bump. The product gets genuine appreciation from the people who use it, but the feedback loop is long and quiet.
Copy and brand voice are harder than code. I spent more time this year rewriting landing page copy than shipping features. The original branding leaned into a Die Hard movie reference (hence the name). It was fun but didn't match the product's actual audience — people making calls to immigration offices and doctors' offices. The current voice tries to be plainspoken and transactional: "Their phone rings. No app on their end."
Event sourcing in Rails is doable but has a cost. I built an event-driven architecture (EventBus, EventStore, projections) that I'm glad I have now, it makes the system transparent and auditable, which matters for a product handling phone calls and money. But it took multiple iterations and there were periods where the architecture was ahead of the product. If I started over, I'd probably still do it, but I'd start simpler.
What I'm working on next: real-time transaltion during calls and a proper iOS app (currently public beta in TestFlight).
Happy to answer questions about WebRTC, Twilio integration, telecom fraud, or running a side project alongside a full-time job.
d0min0•1h ago
Some numbers after a year
* ~€600 MRR, ~1,400 registered users * 60%+ of call traffic goes to the US, rest split between Germany, France, Singapore, UK, Australia * Credit-based PAYG, starting at $0.03/min or PRO plan for $29/mo * Live closed captions to actually understand what's the clerk on the other end saying * Built and run entirely by one person (I also have a full-time day job)
Stack: Rails, WebRTC, Twilio for PSTN termination, Stripe for payments. Event-sourced architecture that took several iterations to get right Infrastructure cost is low. Twilio charges per minute so my costs scale linearly with revenue
What I learned
The product-market fit is narrow but real. The people who need browser-to-landline calling really need it, phone interpreters who work hours at a time, expats dealing with government offices that don't answer email, people stranded abroad who need to reach a car rental or insurance company right now. These aren't hypothetical use cases; they're actual support emails I've received. But this audience isn't growing. Most person-to-person calling has already moved to WhatsApp, FaceTime, etc. What's left is the long tail of situations where the other side only has a phone number.
IRSF fraud is real and will find you. Within the first few months I lost about $100 to automated calls to premium numbers in places like Guinea and Sierra Leone. Not a lot of money, but enough to make me build a destination blocklist and velocity limits. If you're building anything that terminates calls to the PSTN, budget time for this.
Telecom is operationally unglamorous. There's no viral loop. Nobody tweets about their calling service. Growth is slow, mostly organic, mostly from people who google "call international number from browser" and find me. I posted on Indie Hackers when Skype shut down and got a small bump. The product gets genuine appreciation from the people who use it, but the feedback loop is long and quiet.
Copy and brand voice are harder than code. I spent more time this year rewriting landing page copy than shipping features. The original branding leaned into a Die Hard movie reference (hence the name). It was fun but didn't match the product's actual audience — people making calls to immigration offices and doctors' offices. The current voice tries to be plainspoken and transactional: "Their phone rings. No app on their end."
Event sourcing in Rails is doable but has a cost. I built an event-driven architecture (EventBus, EventStore, projections) that I'm glad I have now, it makes the system transparent and auditable, which matters for a product handling phone calls and money. But it took multiple iterations and there were periods where the architecture was ahead of the product. If I started over, I'd probably still do it, but I'd start simpler.
What I'm working on next: real-time transaltion during calls and a proper iOS app (currently public beta in TestFlight).
Happy to answer questions about WebRTC, Twilio integration, telecom fraud, or running a side project alongside a full-time job.