We've all been there, messaging with a friend or a group chat deciding when and where to meet. The conversation always stalls on the same question: where should we meet? Some leave to search a map app, others to restaurant booking and discount apps. Screenshots come back. Somebody points out the first suggestion has nothing vegetarian, the second is miles from the station, the third looks wrong for the occasion. The enthusiasm to actually meet drains away in minutes.

I started InBe because that moment is a product failure, not a fact of life. A failure affecting products across many verticals. The apps we use to organise our social lives are remarkably good at connecting people, but remarkably poor at helping them decide where to go. Why is this? Because it's not that builders don't care. It is that the tools available to them were never designed for the job.

The moment maps don't solve

An enormous amount of real-world meeting now begins inside apps: social apps, messaging platforms, AI assistants, planning tools, communities of every kind. These products create the intent to meet. Then, at the decisive moment, almost all of them leave their customers out in the cold, handing them over to a map or to sort it out themselves.

That handoff is where engagement leaks. The user leaves, the product loses the most valuable part of the journey, and the person is left doing manual research a computer should be doing for them. Everyone loses except the map.

Why generic place APIs fall short

The obvious answer is "integrate a places API", and plenty of teams have tried. What they find is that traditional place APIs were built to serve maps: a pin, a radius, a category, a list of nearby records. That model is superb for "coffee near me". It falls apart the moment a real plan is involved.

Real plans involve more than one person, and each person arrives with constraints. One is vegetarian. One is coming from the other side of the city. The occasion calls for somewhere you can actually hold a conversation. None of that fits into a keyword and a radius, so builders end up writing it themselves: midpoint calculations, stacked requests, filtering on data that is too thin to filter on, and ranking logic that never quite feels right. Most teams sensibly conclude it's not worth it, and the handoff to the map survives another year.

This is not a criticism of the incumbents. They solved their problem exceptionally well. It is simply a different problem from the one modern apps have.

Our bet

Our bet is straightforward: there is a large and growing set of products that organise people digitally but cannot help them meet physically, and giving those products real place-finding ability creates significant value on both sides. The user gets an answer instead of a research task. The product keeps the most engaging moment of the journey inside its own experience.

The name is the thesis. InBetween exists to find the place in between people: between their locations, their preferences, and their constraints. When an app can resolve "where should we meet?" in one request, a moment that used to push users away becomes a reason to stay.

What we believe

Three principles shape everything we build.

You own the experience. We are infrastructure, not a destination. InBe supplies the data and the matching intelligence; you decide how it looks, feels, and behaves in your product. We will never insert our brand between you and your users.

Match people to places, not just a pin. Proximity is one input among many. Preferences, dietary needs, atmosphere, budget, timing, and the shape of the group matter just as much. A recommendation that ignores them is a list, not an answer.

The whole journey should stay in-app. Users should be able to search, decide, and book without leaving the product they are already in. Every forced switch to another app is friction for them and lost engagement for you.

What we're aiming for

Our objective is simple to state and demanding to deliver: make finding relevant places inside any product fast and cost-effective.

Fast means one API call that accepts the messy reality of a plan: several people, several locations, preferences, hard constraints, and context. Cost-effective means you should not need a data science team or a stack of chained requests to get a good answer, and the economics should work at consumer scale.

Neither is possible without two capabilities we treat as the core of the product: genuine preference matching, and native multi-person, multi-location search. Everything else we build sits on top of those two.

How we deliver

It starts with the data. We build ultra-detailed venue profiles covering menus, pricing, dietary coverage, atmosphere, opening times, and the dozens of smaller signals that decide whether a place actually suits an occasion. Generic place records cannot support real matching; ours are built for it.

On top of that sits a search API designed around plans rather than pins. You send us the locations involved, the preferences, non-negotiables, and any other context of the occasion. We handle the fair middle ground between people, weigh the trade-offs, and return a ranked shortlist you can render straight into your interface. One request replaces the stack of map calls and custom logic teams used to write themselves.

We are also deliberate about efficiency. Search returns what you need to present great options; richer detail is fetched only when a user explores a specific venue. You pay for what your users actually use, which is what makes "cost-effective" an honest claim rather than a slogan.

Where we are, and what's next

InBe is live today and open for signups. Our deepest coverage is in London, and we are scaling across major cities at pace, starting with English-speaking markets.

We are working hard to add native booking functionality. If our ethos is that people should be able to find a great place without leaving the app they are in, it has to extend to securing the table too. Search, decide, and book, all in one place: that is the complete journey we are building towards.

An invitation

If you are building a product where people connect, and you have always treated "where should we meet?" as somebody else's problem, we would like to change your mind. You can get an API key and make your first search in minutes, or talk to us if you are weighing up whether InBe fits what you are building.

Software brings people together. We exist to help you take them the last mile, and a table that suits everyone.