I tried to fix loneliness. I ended up building a Places API 280x cheaper than Google.
A couple of years ago, a friend came up with an idea that I still think is worth pursuing.
Moving to a new city is hard. Not because of logistics — but because of the quiet. You have a great coffee shop downstairs, a pool table two blocks away, and zero people to share it with. Dating apps exist. Friend apps don't, not really.
So the three of us built one. The pitch: open the app, see people nearby in cafes and bars who are openly up for a chat, a language exchange, a game of pool. No awkward matching, no swiping — just proximity and intent. A modern Foursquare, but for human connection instead of check-ins.
We built it. We shipped it. And then we completely failed at marketing. The product worked. The growth didn't. Classic indie story.
The technical leftover
One thing stuck with me from that project: the data layer.
Early on we used OpenStreetMap. It's incredible for what it is — but the POI data is inconsistent, incomplete in non-English speaking regions, and hard to work with at scale. Midway through we switched to Overture Maps — an open dataset backed by Meta, Microsoft, Amazon, and TomTom — and never looked back.
After the startup wound down, I kept thinking about Overture. The dataset had grown to 80+ million places worldwide. The license — CDLA Permissive 2.0 — has zero commercial restrictions. And yet almost nobody was serving it through a clean, affordable API.
The Google Places problem
If you've ever built a location-based feature, you know the pain.
Google Places API charges $17 per 1,000 requests for Place Details. Nearby Search is $32 per 1,000. For a startup running 500,000 requests a month, that's $8,500–$16,000. Monthly. Before you've found product-market fit.
The result? Developers either cripple their apps with aggressive caching, avoid the feature entirely, or burn through their Google credit and get an unexpected invoice.
There had to be a better way.
What I built
I spent a few weeks building a REST API on top of the Overture Places dataset, written in Rust with Axum and PostGIS on the backend.
Two endpoints:
Nearby search — find places within a radius, optionally filtered by category:
GET /api/places/nearby?lat=40.71&lon=-74.00&radius=500&category=restaurant
Search by name or brand — find all locations of a specific business:
GET /api/places/search?lat=40.71&lon=-74.00&radius=2000&q=starbucks
This one searches across both name and brand fields simultaneously, so you don't have to know how Overture classifies a particular chain.
Each response includes coordinates, name, category, address, operating status, phones, websites, social links, and emails.
The numbers
Google Places charges $17 per 1,000 requests for Place Details, and $32 for Nearby Search. Commercial use comes with restrictions, and overage bills are a common surprise.
This API starts at $0.10 per 1,000 requests, Nearby Search is included, the license has zero commercial restrictions, and overages are soft — $0.05 per 1,000 if you exceed your plan.
Plans on RapidAPI:
Basic — free, 5,000 requests/month
Pro — $10/month, 100,000 requests
Ultra — $30/month, 500,000 requests
Mega — $80/month, 2,000,000 requests
The Pro plan at $10/month for 100,000 requests — Google would charge $1,700 for the same volume.
The honest part
The data isn't perfect. Overture is updated monthly, not in real-time. In some regions — especially smaller cities outside Western Europe and North America — coverage is thinner than Google's.
If you need reviews, photos, real-time open/closed status, or Google's autocomplete quality — this isn't a replacement. It's an alternative for the use cases where you just need POI data and coordinates, and you don't want to pay Google's prices to get them.
What's next
The API started as a side project for the social app. But honestly, I'm not done with that original idea either. The loneliness problem is real, and I still think proximity-based social has legs — just needs a different approach to growth than what we tried.
For now, the Places API is live on RapidAPI. Free tier available.
And if you're building something in the location space and want to talk — I'm always up for that conversation.
Built solo, with Rust, PostGIS, and too much coffee.
1 designer + base44 + 3 days without proper sleep = Overdrive🤍
A job tracking system for a car repair shop.
✱ One board showing every car on the floor, where each one stands and what’s holding it up.
Add a car, assign the work, and from there it tracks itself- what’s late, which parts have landed, who’s in today. Visit history, receipts, and a widget that tells you the next free slot you can offer someone.
Three days. Not smooth ones. But it’s live❗️
✱ Now the why, because none of those features were my idea.
My client owns the shop. Four mechanics, up to seven cars a day, no front desk. For months he’d complain about the same stuff whenever we talked: parts he ordered and forgot about, mechanics starting one car and getting pulled onto another, people asking when they can bring a car in and him not knowing what to say.
It was never a brief, of course, he was just talking. But one day I asked him properly: what do you need to see the moment you walk in?
✱ He said four things. And those four made sense as widgets, naturally.
Nothing on the job board gets typed in by a person. For example, a car shows as blocked because the mechanic who has it is off today- the board works that out and writes the reason on the card. He doesn’t walk around the shop asking anyone, he can just see it now.
✱ And the part nobody puts in these posts😅
→ It is my first time ever (!) using Base44 and I started without a paid plan, so I had a hard limit on how many prompts I got.
You can’t iterate your way to something like that. Every prompt had to arrive already correct, which meant almost all of the work happened before I typed anything. I designed every screen and every state in Figma first, then worked out exactly what to ask for and in what order.
I spent hours with Claude and Google figuring out how to phrase things, what would break, what to check before changing anything. I’d write a prompt and then throw it away and write a better one, because a wasted prompt cost more than the time did 🤷🏻♀️
Honestly, the constraint made it better. No aimless tinkering. Every change had a reason before it was made, and I still got every core feature I wanted in there.
You made the connection. Carddek helps you keep it.
After a speed networking event, I came home with a stack of business cards and a problem: remembering the people, conversations, and promises behind them.
Scan a business card, keep the details that matter, and turn “great meeting you” into a meaningful follow-up. An interactive living deck brings your contacts to life, while reminders and personalized drafts help you take the next step.
I designed Carddek around the moments networking tools often miss: where you met, what stood out, what you offered, and what you wanted to do next.
My process started with a real experience, grew into a visual identity inspired by physical cards, and evolved through hands-on testing of scanning, card interactions, and mobile layouts. The accompanying video pairs that story with a look inside the app.
The business card still has a place. Now the conversation has somewhere to continue.
Built by Veronica Hernandez, founder of TAKHNIT. #Base44Challenge @base44