Introduction
DirectCall was WebRTC browser video calling at directcall.app: share a link, call with no install and no account.
The goal was frictionless browser-based video calling for people who mostly need to reach family or friends.
No downloads. No messengers. Just a link.
What DirectCall Was
Peer-to-peer video in the browser.
The user flow was:
- Open the website
- Generate a unique call link
- Share the link with another person
- The other person opens it in a browser
- Video call starts instantly
This approach removed most of the friction found in traditional messaging apps and video calling platforms.
Problem It Was Trying to Solve
DirectCall was built for users who:
- don’t want to install apps
- struggle with complex messaging platforms
- just need a quick video call without an app
- may face restrictions on popular communication apps
The goal was to make communication as simple as opening a link - a video calling app without signup or setup.
Technical Stack
DirectCall was built on:
- WebRTC for peer-to-peer video communication
- Lightweight backend hosted on DigitalOcean
- Simple session-based link generation system
The full technical breakdown is in Building DirectCall - The Tech Behind the Simplicity.
What Worked Initially
At the beginning, the system worked as expected:
- I personally used it
- My family tested it
- Calls were fast and simple
- No onboarding friction worked exactly as intended
For a short period, it validated the core idea: no-installation video calling without setup can actually work.
The Core Problem: WebRTC Reliability and Network Restrictions
The main issue was not product design or implementation.
It was external network behavior.
Over time, WebRTC connections started failing in certain regions.
In some cases:
- calls would not connect at all
- peer-to-peer connection could not be established
- no clear error or fix was available
This created an unstable user experience that could not be reliably reproduced or resolved - the kind of situation people describe when video calls are not connecting and browser video calls are not working in some countries.
Why This Became a Critical Issue
The problem was not just technical - it was systemic.
The environment around the product was changing:
- network-level restrictions were increasing
- WebRTC connectivity became inconsistent in some regions
- reliable global communication could not be guaranteed
This meant the product depended on external conditions that were outside of my control - less a bug in code and more a real-time communication in the browser problem tied to infrastructure and policy.
Why I Decided to Shut It Down
The decision was not sudden.
It became clear over time that:
- this was not a “build once and scale” type of system
- the problem required continuous adaptation
- there was no stable long-term solution guaranteed
Instead of improving toward stability, the system required ongoing reactive fixes.
That made it difficult to justify further investment or monetization. It is a straightforward failed startup case study in dependency on factors you cannot control.
In practice, winding down meant leaving directcall.app up as a static pause page for people who still had the link, instead of running the full calling stack.
Key Lessons Learned
-
Some problems are not product problems - Not every technical idea becomes a stable product. Some depend heavily on external infrastructure and conditions, which is why startups sometimes fail due to technical limitations that are really environmental.
-
Early validation is critical - Real-world constraints (like network behavior and why WebRTC fails in specific places) should be tested as early as possible.
-
Avoid emotional attachment to prototypes - Just because something works technically does not mean it is viable as a long-term product.
-
Launch early, validate faster - The earlier a product is exposed to real-world conditions, the faster fundamental issues surface.
Key takeaway
DirectCall was technically functional WebRTC video calling, but failed at global reliability because of external network constraints - not because the core implementation was wrong.
Related Work
You can read the technical deep dive here: Building DirectCall - The Tech Behind the Simplicity.
I am also working on voice-first products such as ViaVox (Android, voice translation and AI companion). A separate ViaVox post-mortem may follow if that story becomes worth telling the same way.
Conclusion
DirectCall was a fully functional browser-based video calling system that demonstrated a simple idea: communication should be accessible without installation or setup.
However, due to increasing network-level restrictions and unreliable WebRTC connectivity in certain environments, the system could not provide consistent global reliability.
As a result, the project was discontinued.
While it did not become a long-term product, it provided valuable insights into real-world system limitations beyond code and architecture.
FAQ
Why did DirectCall fail?
Because WebRTC connections became unreliable in certain regions due to network-level restrictions and inconsistent connectivity, not because the app lacked core features.
Was DirectCall a technical failure?
No. It worked technically for many users, but it failed at global reliability - the kind of WebRTC connection issues you cannot fully fix in application code alone.
Can browser-based video calling work today?
Yes, but reliability depends heavily on network conditions, signaling, TURN/STUN infrastructure, and regional policy. Peer-to-peer video calls in the browser remain powerful and legitimate; they are not guaranteed everywhere without operational and infrastructure investment.
You may also find these posts interesting: