Third-Party Integrations on niranar.com: What We Built and Skipped

Every third-party integration is a bet. When you add a maps service to your platform, you're not just gaining mapping functionality — you're accepting a dependency on someone else's pricing decisions, API contract stability, and uptime record. When you integrate a payment processor, you're not just enabling transactions — you're inheriting their fraud policies, PCI compliance obligations, and the operational complexity that comes with moving money at scale.

niranar.com is a vacation rental marketplace covering Mediterranean Turkey with over 300,000 active listings. This article examines the platform's integration decisions: what was integrated and why, what was deliberately left out and why, and what those choices reveal about the engineering philosophy behind a solo developer building a marketplace product. For the underlying architecture context, see the earlier article in this series on niranar.com's Technical Architecture.

Integration Decisions Are Architectural Decisions

When a developer selects a library or service, they're answering a set of questions that extend well beyond the immediate technical problem: Which responsibilities belong inside our system? Which problems can we safely hand off to external services? What dependencies are we willing to accept in exchange for that capability?

Getting this wrong — particularly on a solo developer project — multiplies long-term maintenance burden. Getting it right enables maximum product quality with limited capacity.

niranar.com's integration map falls into three categories: systems actively integrated, things deliberately deferred, and things deliberately excluded. Each category is the result of a decision, not an omission.

Maps: Leaflet vs. The Paid Alternatives

niranar.com uses Leaflet for its map interface. Leaflet is an open-source JavaScript mapping library — no API key required, no per-request billing, no vendor relationship necessary to keep it running.

The obvious alternative is Google Maps Platform. Google's mapping service offers richer feature sets, higher-quality place data, and a developer experience that many teams default to. But Google Maps Platform's pricing structure creates a meaningful constraint for a pre-revenue platform.

Google Maps charges for dynamic map loads beyond a monthly free tier. The cost per 1,000 requests is manageable for a revenue-generating product — but for a platform still in beta, still building toward its first booking, the cost structure looks different. A catalog of 300,000+ listings with users browsing between properties, zooming in on neighborhoods, and navigating across regions generates significant map interaction volume. The free tier erodes quickly; the billing starts before any revenue flows.

Leaflet eliminates this cost curve entirely. Zero cost regardless of map load volume. No request limits. The library is bundled directly into the project — no external dependency required to keep the maps working. If Google decides to change its pricing model tomorrow (as it has done before), Leaflet users are unaffected.

What Leaflet Provides (and Doesn't Need to Provide)

The question worth asking is: what does a vacation rental marketplace actually need from a maps integration?

For niranar.com's core use case, the requirements are relatively well-defined. Users need to see where properties are located on a map of Mediterranean Turkey's coastline. They need to be able to navigate within a region — Bodrum's peninsula, Fethiye's bay, Antalya's sprawling coastal strip. They need property markers that correspond to list view results. This is what Leaflet delivers, and it delivers it well.

What Google Maps adds — branded map tiles, higher-resolution satellite imagery, detailed Points of Interest data, Street View integration, turn-by-turn navigation — none of these capabilities is relevant to the core "show me where this villa is" use case. The gap between Leaflet and Google Maps is real, but it exists at the level of features niranar.com doesn't need.

This is cost engineering: identifying the capability floor that the product actually requires and finding the most cost-effective way to meet it. Not every product needs Google Maps. Most vacation rental search experiences do not.

Calendar and Availability: The Case for Building In-House

niranar.com's calendar and availability system is a custom-built implementation. There is no third-party calendar API mediating between the platform and its availability data.

This might seem surprising. Calendar APIs designed for vacation rental platforms exist. Some of them handle iCal synchronization, multi-source availability aggregation, and booking conflict resolution. Integrating one of them might appear to reduce initial development effort compared to building from scratch.

But the reasoning for building in-house becomes clear when you consider what the calendar does in niranar.com's architecture. Availability data isn't a peripheral feature — it's central to the search experience. When a user searches for a property in Antalya for two weeks in August, date-based availability filtering is one of the first operations the search executes. The calendar is not a module that sits alongside the core functionality; it's woven into it.

Handing that to an external service means accepting external dependency on the most critical part of the product's data model. If that service has an API outage, availability filtering breaks. If the API contract changes, the platform's search behavior changes with it. If pricing increases, the cost of running the search experience increases.

Owning Core Functionality

There's a useful principle at work here: the more central a feature is to a product's value proposition, the more expensive it is to have an external dependency on it.

A vacation rental platform's entire value sits on the answer to "which properties are available for my dates?" If the answer to that question depends on a third-party service's reliability, the platform's core promise becomes contingent on someone else's infrastructure decisions.

A custom implementation keeps that dependency internal. The calendar logic lives within the platform's own codebase. No external uptime risk. No API contract versioning problems. The availability data model can evolve exactly as the platform's requirements evolve, without waiting for or working around a vendor's roadmap.

This does require maintaining the system. But a known, contained maintenance responsibility is generally more predictable than the open-ended operational risk of a critical external dependency.

Supabase: One Integration, Three Capabilities

niranar.com's backend runs on Supabase, a Backend as a Service (BaaS) platform that bundles PostgreSQL database, API layer, and serverless functions under a single service.

To appreciate the integration significance of this choice, consider what the alternative might look like. A platform at niranar.com's scale could reasonably require: a managed PostgreSQL database with its own connection pooling and backup configuration, a separate API server layer (Node.js, Express, or similar) to translate database queries into HTTP responses, and a serverless compute platform for business logic that doesn't belong in the database or the API server. That's three services, three API contracts, three billing relationships, three sets of documentation to maintain, three monitoring integrations to configure.

Supabase collapses all three into one.

The Auto-Generated API Layer

One of the less-discussed benefits of Supabase is that it eliminates the need to build and maintain a separate API server. When database tables are defined, Supabase automatically generates REST and GraphQL endpoints for those tables. No separate Express server to write, deploy, version, and maintain.

For niranar.com, this means queries against 300,000+ listings — filtered by location, date availability, guest capacity, property type, and amenities — run through Supabase's PostgreSQL layer without requiring a separately maintained API service. The developer's time goes to building the search experience, not to maintaining the plumbing that serves data to it.

Supabase vs. Firebase: A Comparison for Context

For international readers more familiar with Firebase (Google's BaaS offering), Supabase occupies a similar conceptual position: it provides database, auth, and real-time capabilities as a managed service, reducing the need for separate infrastructure components.

The key difference is the underlying database. Supabase uses PostgreSQL — a relational database that handles complex queries, full-text search, and relational data modeling well. For a search platform filtering across 300,000 records with multiple simultaneous parameters, PostgreSQL's query capabilities are a meaningful advantage over Firebase's document-oriented Firestore. It's also open-source and portable in ways that Firebase is not.

The Auth Module: Ready When Needed

Supabase includes a full authentication module covering email/password login, social OAuth providers, and magic link authentication. On niranar.com, this module is present but not currently activated.

This is worth being precise about. The capability exists within the platform's current infrastructure. Activating user authentication is not a new integration project — it's enabling a module that's already part of the system. No new vendor relationship. No new API contract. No new billing relationship to set up.

When the platform's April 2026 launch activates the full booking flow, user authentication will become a necessary component. The infrastructure for it is already in place.

Deliberate Absences: Payment and Authentication

The most informative integrations on niranar.com are the ones that aren't there. Two major capability categories were deliberately kept out of the beta scope.

No Payment Integration — Deliberate Beta Scope

niranar.com currently has no payment infrastructure. Credit card processing, bank transfer management, EUR currency handling, refund management — none of these exist in the current system.

This is not an oversight. It is a scope decision with a clear rationale.

Payment integration carries obligations that extend well beyond the technical implementation. PCI DSS compliance requirements, fraud detection and management, dispute resolution processes, cross-border transaction handling for EUR-paying international guests, and the operational infrastructure to handle chargebacks and refunds — these responsibilities don't stand alone. They require legal framework, customer support capacity, and operational procedures that would be difficult to manage responsibly before the core discovery experience has been validated.

The sequencing logic here is straightforward: build the catalog first, validate that the discovery experience works, then add the transactional layer. With 300,000+ listings already in place and an active search experience running in beta, the discovery-side validation is underway. The April 2026 launch adds payment and booking — but only after establishing that people actually want to use the platform to find properties.

This is a pattern seen in the most successful marketplace launches: validate demand before building supply-demand matching infrastructure. The alternative — building payment and booking before knowing whether users want to search and discover — risks significant wasted development effort on transactional complexity that only matters if discovery works.

No User Authentication — Deliberate Beta Scope

Similarly, user accounts and authentication are absent from the beta. Visitors can search across 300,000 listings, view property details, browse by map, and filter by dates and amenities — without registering, without creating an account, without providing an email address.

The practical effect of this absence is twofold. First, it defers the design and development of registration flows, onboarding sequences, and session management until they're actually required by a booking flow. Second, it eliminates friction from the discovery experience: users who just want to browse available villas in Fethiye can do so without gatekeeping.

Discovery-phase users — people who are researching whether they want to go somewhere and what's available — don't need accounts to get value from the platform. The absence of authentication at this stage is a deliberate UX choice, not an engineering gap.

As with auth generally, Supabase's authentication module is already present in the infrastructure. The transition from anonymous discovery to authenticated booking is a configuration step, not a new integration project.

The Integration Philosophy: Minimize Dependency Surface

The pattern across niranar.com's integration decisions is consistent: keep the dependency surface as small as possible while still meeting the product's core requirements.

Leaflet eliminates the Google Maps billing dependency while providing sufficient geographic visualization for the use case. The custom calendar keeps the most critical data capability inside the platform rather than delegating it to an external service. Supabase consolidates what would otherwise be three separate service dependencies into one. Payment and authentication are deferred until the platform has enough validated demand to justify the operational complexity they bring.

Solo Developer Context Makes This Sharper

Any engineering team can benefit from minimizing dependency surface. But for a solo developer project, the calculation is particularly stark.

Every external dependency generates ongoing maintenance noise: API updates to track, version migrations to manage, unexpected outages to respond to, billing changes to absorb. In a team of five, that noise is distributed across multiple people. For a single developer, every piece of maintenance noise competes directly with product development time.

Keeping the dependency surface small is how a solo developer maintains a sustainable operational load. Supabase is one integration point. Leaflet has no external API contract to maintain. The custom calendar depends only on the platform's own code. This structure makes it possible for one person to operate the platform without being overwhelmed by the maintenance overhead of its constituent services.

What This Demonstrates

niranar.com's integration map reflects a principled approach to third-party dependencies — one that's cost-conscious, strategically scoped, and calibrated for the operational reality of a single developer.

The Leaflet choice shows that map integration is treated as a solved problem that doesn't require paying for features beyond what the product needs. The custom calendar shows that core functionality stays inside the platform's control. The Supabase consolidation shows that integration complexity is managed deliberately — fewer dependencies, not more. The payment and auth deferrals show that transactional complexity is sequenced after discovery validation, not added preemptively.

For a potential client evaluating Smart Maple for a marketplace or integration-heavy platform project, this pattern is meaningful. Integration decisions at the architecture stage shape maintenance load, operational cost, and development flexibility for years. Making them thoughtfully — asking not just "what can we integrate?" but "what should we integrate, and when?" — is part of building a platform that stays manageable as it scales.

The next articles in this series examine niranar.com's SEO architecture and beta strategy. For the broader context on how these integration choices fit into the platform's overall technical approach, see niranar.com's Technical Architecture.