niranar.com Architecture: Solo-Built 300K-Listing Platform

When a traveler searches for a beachfront villa in Bodrum on niranar.com, a request chain fires in under a second: the browser loads a Next.js-rendered page, the search query travels to Supabase, PostgreSQL returns matching listings, and a Leaflet map plots property locations on screen. The entire system runs on AWS Amplify, written and maintained by a single developer.

This is not a trivial engineering problem. A vacation rental platform serving Mediterranean Turkey must handle geo-location search, date-range filtering, property category browsing, mobile-responsive interfaces, and search engine indexing — all simultaneously, with a team of one.

This article walks through how niranar.com is built and why each architectural decision was made the way it was. It's written for technical decision-makers and evaluators, not developers. No code knowledge required.

The Architecture at a Glance

niranar.com sits on three layers: a frontend (Next.js), a backend-as-a-service layer (Supabase), and cloud hosting (AWS Amplify). Each layer has a clear boundary of responsibility. The frontend controls what users see. Supabase manages where data lives and how it's queried. AWS Amplify ensures the application is reliably accessible on the internet.

This separation matters. When layers have clear boundaries, a change in one layer doesn't cascade unpredictably into another. A database query optimization doesn't require touching frontend components. A UI redesign doesn't alter how data is stored. For a single developer maintaining a platform at scale, these clean lines reduce cognitive overhead and lower the risk of unintended side effects.

Request Flow

Here's what happens when a user submits a search:

The browser requests a page from Next.js, which processes the request server-side. Search parameters — destination, check-in/out dates, guest count — are passed to Supabase as a query. Supabase queries PostgreSQL and returns matching listings. The data flows into Next.js components which render the results. When a map view is requested, Leaflet renders property locations client-side in the browser.

Every step in this chain is built with minimal complexity. The goal isn't architectural elegance for its own sake — it's a system one person can operate, debug, and extend without being overwhelmed.

The Frontend: Next.js

The user interface is built with Next.js, a React-based framework that adds server-side rendering, routing, and performance optimization on top of React's component model.

Why Next.js for a Vacation Rental Platform?

Vacation rental platforms have an inherent tension: they need rich, dynamic search experiences but also need to be indexed by search engines. Traditional client-side applications (where the browser builds the page using JavaScript) struggle with search engine indexing because search engine crawlers don't execute JavaScript as well as real browsers do.

Next.js resolves this by rendering pages server-side — the server builds the HTML and sends it to the browser ready to display. Search engines receive fully-formed HTML they can index immediately. Users see content without waiting for JavaScript to load and execute. Both problems solved with one approach.

App Router and React Server Components

niranar.com uses Next.js's App Router with React Server Components (RSC). This means a large portion of each page is built on the server, with only the interactive parts (a search form, a map, a calendar) running in the browser. Pages that don't need browser interactivity send zero JavaScript to the client.

For a platform with 300,000+ listing pages, this matters. Less JavaScript per page means faster loads. Faster loads mean better user experience and better search engine rankings. The App Router architecture makes this the default behavior rather than something requiring manual optimization.

Streaming SSR

Next.js supports streaming server-side rendering — the server can begin sending parts of a page to the browser before all data is ready. For a property search result page, this means users see the page structure and first results immediately, with remaining listings filling in as they load.

In a category where attention is short and competing platforms are one browser tab away, perceived performance matters as much as measured performance. Streaming SSR addresses the experience of waiting, not just the technical metrics.

Skeleton Screens

Before data loads, niranar.com displays skeleton screens — placeholder shapes in the layout of property cards. This progressive loading pattern gives users visual feedback that content is coming. An empty white screen creates uncertainty; a skeleton communicates the system is working.

This is a deliberate UX engineering decision. It requires building placeholder states for every content-bearing component. The payoff is a loading experience that feels intentional rather than broken.

Tailwind CSS for Responsive Design

The UI is styled using Tailwind CSS, a utility-first CSS framework. Tailwind's approach means the same codebase produces responsive layouts across phones, tablets, and desktop screens without separate stylesheets per device. A single change updates the UI across all breakpoints simultaneously.

Vacation rental browsing is predominantly mobile. A solo developer can't maintain separate mobile and desktop codebases — Tailwind makes it unnecessary.

The Backend: Supabase as BaaS

Backend-as-a-Service (BaaS) is the concept of outsourcing the infrastructure layer of an application — database hosting, authentication systems, API endpoints — to a managed service. You write the product logic; the BaaS handles the plumbing.

niranar.com uses Supabase for this layer.

What Is Supabase?

Supabase is an open-source Firebase alternative built on PostgreSQL. Where Firebase uses a document-based NoSQL database (not well-suited to relational queries), Supabase gives you a full PostgreSQL instance with auto-generated REST and GraphQL APIs, serverless functions, and — when needed — a built-in authentication system.

It's worth explaining the Firebase comparison because it's the most common BaaS reference point for international readers. Firebase and Supabase both handle database, API, and auth. The difference is the database underneath: PostgreSQL's relational model gives Supabase more power for complex queries — the kind you need for multi-parameter vacation rental search.

What Supabase Does for niranar.com

Supabase handles three things simultaneously: hosting and managing the PostgreSQL database, serving an API layer that frontend components call to retrieve listings, and providing a serverless function runtime for backend logic.

The practical consequence for niranar.com's solo developer: no server to configure, no database maintenance to schedule, no security patches to apply manually. Supabase handles operations. The developer builds features.

PostgreSQL as the Search Backend

niranar.com's search runs entirely on Supabase's PostgreSQL. Queries against 300,000+ listings — filtered by location, date range, guest count, amenities, and price tier — are resolved as PostgreSQL queries.

A notable architectural choice: no dedicated search engine is in use. Elasticsearch, Algolia, and similar tools specialize in full-text search at scale, but they add infrastructure complexity and operational overhead. For the beta phase, PostgreSQL's query capabilities are sufficient. This is a deliberate decision to keep the system simple — an additional search service can be layered in later if scale requires it.

Serverless Functions

Business logic that doesn't fit neatly into database queries — processing input, interacting with external services — runs as serverless functions via Next.js API routes and Supabase Edge Functions. Serverless means these run on demand: they start when a request arrives, execute, and stop. No always-running backend server to manage or pay for at idle.

Maps: Leaflet

niranar.com includes map-based property browsing. Leaflet, an open-source JavaScript mapping library, provides this functionality.

The most common commercial alternatives are Google Maps and Mapbox. Both charge based on map loads and API calls. At 300,000+ listings and growing user traffic, API call costs can become significant. Leaflet eliminates this variable.

There's also a strategic consideration: third-party API dependencies create exposure to pricing changes and terms-of-service updates outside your control. Leaflet is open-source, community-maintained, and has been stable for over a decade. No licensing risk, no cost escalation tied to traffic growth.

Map points are rendered client-side in the user's browser. This distributes the rendering work to the user's device rather than the server, reducing server load as the map layer scales.

Hosting: AWS Amplify

niranar.com is deployed on AWS Amplify. Most Next.js applications default to Vercel, the platform built by the creators of Next.js. AWS Amplify is a deliberate alternative.

Why Not Vercel?

Vercel is purpose-built for Next.js deployment and is the path of least resistance. The reason to choose AWS Amplify instead is about ecosystem alignment.

Amazon Web Services is the world's largest cloud infrastructure provider. AWS Amplify is Amazon's managed service for deploying and hosting frontend and fullstack applications. Choosing Amplify means the application lives within the AWS ecosystem from day one.

As niranar.com grows — and as features requiring more infrastructure appear — AWS services are available in the same environment. Message queuing, data processing pipelines, CDN configuration, advanced monitoring: all of these are available as AWS services without cross-cloud integration overhead. Authentication, access management, and billing are centralized.

There's also a cost profile consideration. Vercel's pricing scales with traffic and build frequency in ways that can surprise teams at growth inflection points. AWS Amplify offers a different cost curve more suited to platforms that anticipate substantial traffic.

SEO Architecture

Turkey's vacation rental market is competitive, and niranar.com's target audience includes international tourists searching in English as well as Turkish travelers searching domestically. Technical SEO is not optional.

SSR as an SEO Foundation

Server-side rendering means every listing page — all 300,000+ of them — is delivered as fully-formed HTML to search engine crawlers. Google, Yandex, and other search engines can index this content without needing to execute JavaScript. This is a baseline requirement for a catalog-scale platform to be discoverable.

Schema.org Structured Data

niranar.com implements two schema.org markup types in the page head:

WebSite: Identifies the site to search engines with structured metadata about its purpose and content.

SearchAction: Signals to Google that the site has search functionality. When implemented correctly, Google may display a search input directly in the search results listing — users can search within niranar.com from a Google results page without first visiting the site. This is called a sitelinks searchbox, and it meaningfully increases engagement from organic search.

For an international tourist searching "villas Turkey" or "Bodrum vacation rental," structured data that surfaces niranar.com with a search prompt creates a discovery advantage over sites that haven't implemented it.

Accessibility

An accessibility partner verification tag is present in the site code. This indicates active compliance work, not just aspirational intent. Accessibility matters both for reaching a broader audience and for meeting legal compliance requirements that are becoming standard in EU markets — relevant given niranar.com's EUR-denominated pricing and international tourist audience.

What Isn't Built Yet

niranar.com is in beta. Two significant features are absent by design.

No User Authentication

There are no user accounts, no login, no profile pages. This is not an oversight — it's a scoping decision. Building a secure authentication system (password storage, session management, email verification, account recovery) requires substantial development investment. In the beta phase, that investment is directed at the core discovery experience instead.

Supabase includes a built-in auth module that niranar.com isn't yet using. When accounts become necessary, the infrastructure is already present in the stack — activation is the work, not architectural redesign.

No Payment Processing

Booking transactions don't happen on the platform today. Users can find properties, browse listings, and use the search and map features — but cannot complete a reservation through niranar.com.

This reflects a deliberate product philosophy: validate demand before building transaction infrastructure. The beta phase answers the question "do users come, search, and engage?" before investing in payment provider integration, booking flow design, reservation management, and host payout systems.

Payment infrastructure will be built on confirmed user behavior, not assumptions.

The Solo Developer Constraint as Architecture Input

300,000+ listings. Full location, date, and guest search. Interactive maps. SEO-optimized pages. EUR pricing for international tourists. Mobile-responsive across all devices. Built and operated by one person.

The solo developer constraint is not incidental to the architecture — it shapes it. Every technology choice can be re-evaluated through the lens: "Can one developer maintain this without it becoming a full-time burden?"

Supabase: eliminates infrastructure operations. AWS Amplify: standardizes deployment. Leaflet: removes third-party dependency risk. Next.js App Router: handles performance optimization within the framework rather than requiring manual tuning. Claude Code was used in development, multiplying the solo developer's effective output — architectural decision cycles and implementation cycles compressed significantly.

The result is a system where each layer does its job without creating operational overhead in adjacent layers.

Architecture Assessment

niranar.com's architecture demonstrates what lean, well-scoped engineering looks like in practice. The technology choices — Next.js, Supabase, AWS Amplify, Leaflet — are individually sound, widely adopted, and well-documented. The value isn't in any single choice but in how they're composed: each layer optimized for maintainability by one person, each decision reducing operational friction.

The beta phase scope is disciplined: auth and payment are absent because the platform is validating its core hypothesis first. 300,000+ listings are present because catalog coverage is the primary value proposition. The architecture serves the discovery mission without overbuilding for capabilities not yet needed.

Smart Maple designed and built this system. For a deeper look at technology selection rationale and what niranar.com is, see the companion articles in this series. Technology selection, layer architecture, and scope decisions followed the framework described here. The platform is targeting an April 2026 beta launch — and the current architecture positions it to grow into fuller functionality when that phase begins.