Building KitaPhone: Why I Wanted International Calling to Work From a Browser

There are plenty of apps for communication.

That was actually part of the problem.

When I started thinking about what eventually became KitaPhone, I kept coming back to a simple question:

Why should making an international phone call require installing another app?

For many people, calling abroad is still unnecessarily complicated. You might need a local SIM, an international roaming package, a VoIP application, an account with a large telecom company, or some combination of all of them.

I wanted to see whether the experience could be simpler.

Open a browser. Enter a number. Make a call.

That idea became KitaPhone.

Starting With the User Experience

When building a product, it is easy to begin with technology.

Which framework should I use?

Which database?

Which provider?

Which API?

Those questions matter, but they are rarely what the customer cares about.

The customer wants the outcome.

In KitaPhone's case, the outcome is straightforward:

I need to call someone in another country.

Everything between that thought and the actual phone call is friction.

So I started thinking about how much of that friction could be removed.

No separate desktop software.

No requirement to change SIM cards.

No traditional calling card.

No complicated subscription just because you occasionally need to make an international call.

The browser became the obvious interface.

Building Around Existing Infrastructure

One of the biggest lessons I have learned building small software products is that you do not need to build every layer yourself.

Modern products can combine existing infrastructure for payments, communications, authentication, hosting and analytics while focusing development effort on the part customers actually interact with.

That is especially important when you are building independently.

Your advantage is not having a team of 100 engineers.

Your advantage is speed.

You can build something, put it in front of people, watch how they use it and change direction quickly.

That has been my approach with KitaPhone.

Launching Before Everything Is Perfect

There is always another feature you could add before launching.

Messaging.

More countries.

More payment methods.

A better dashboard.

More onboarding.

More analytics.

Eventually, however, additional development becomes a way of avoiding the most important question:

Will anybody actually use this?

So instead of waiting until every possible feature was complete, I started putting KitaPhone in front of real users.

Reddit.

LinkedIn.

Direct conversations.

Founder communities.

People travelling internationally.

Expats.

Digital nomads.

People who still need to call traditional mobile and landline numbers.

Those conversations have been more valuable than another month spent polishing features nobody requested.

Distribution Is Part of Building

Developers often think that shipping the software is the finish line.

I have increasingly realised it is closer to the halfway point.

A product that nobody knows exists has the same number of users as a product that was never launched.

Zero.

So I now consider distribution part of product development.

That means writing about what I am building, responding to users, experimenting with landing pages, publishing useful articles and talking directly to people who might have the problem I am solving.

It can feel uncomfortable compared with writing code.

But it is necessary.

What I Am Learning

KitaPhone is still evolving, and that is exactly what makes the project interesting.

Building it has reinforced a few principles I want to carry into future products:

Build around a real action someone wants to complete.

Reduce steps instead of adding features.

Launch earlier.

Talk to users constantly.

Treat marketing as part of product development.

And above all, keep the product simple enough that someone understands it within a few seconds.

For KitaPhone, the idea remains the same as when I started:

If you need to call someone abroad, your browser should be enough.

I will continue documenting what works, what fails and what I learn while building it.