Most software projects have a default technology path. Pick a popular framework, use the cloud provider's recommended settings, reach for the familiar tools. There is nothing wrong with this — defaults exist because they work in most situations. But defaults are not decisions. niranar.com is built on decisions.
Each component of the stack was chosen against two constraints: a solo developer and a beta launch goal. This article explains the reasoning behind those choices — not just what was selected, but why it was selected over the alternatives.
The Stack at a Glance
niranar.com's technical infrastructure:
- Frontend: Next.js (App Router, React Server Components, Streaming SSR)
- CSS: Tailwind CSS
- Backend: Supabase (Backend as a Service)
- Database: Supabase PostgreSQL
- Hosting: AWS Amplify
- Maps: Leaflet (open-source JavaScript mapping library)
- Development approach: Claude Code (AI-assisted development)
Two things are notably absent: payment processing and user authentication. These are not overlooked features — they are deliberate exclusions tied to beta scope discipline. More on that at the end.
Next.js: The Right Foundation for a Content-Heavy Marketplace
Why Server-Side Rendering Matters Here
niranar.com is a vacation rental marketplace covering Mediterranean Turkey. Travelers searching for a villa in Antalya or an apartment near Fethiye's beaches find listings through search engines. For a marketplace that lives or dies by organic discovery, server-side rendering is not an optimization — it is a baseline requirement.
Traditional React applications render in the browser. When a search engine bot visits, it receives an empty HTML shell and leaves without seeing the content. Server-side rendering (SSR) generates the full HTML on the server and delivers it to both the user and the crawlers. With 300,000+ listings across multiple locations, the difference between SSR and client-side rendering translates directly to how many listings appear in search results.
Turkish vacation rental queries come in multiple languages — Turkish, English, German, Russian — reflecting the international tourism market. SSR ensures every page is indexable regardless of the visitor's origin or the query language.
Next.js provides SSR at the framework level. There is no additional rendering layer to configure, maintain, or debug.
App Router and React Server Components
The Next.js App Router with React Server Components (RSC) shifts data fetching to the server. A listing page can fetch its data during server rendering and deliver pre-built HTML — the user's browser does not need to download, parse, and execute JavaScript to see the content.
This architecture has a concrete impact on mobile performance. The Turkish vacation rental market, like most consumer internet segments today, is mobile-first. A listing page that loads in two seconds instead of four is not a minor UX improvement — it directly influences whether users browse further or leave.
RSC also reduces the JavaScript bundle sent to the client. Lighter pages, faster interactions, lower data consumption for mobile users on cellular connections.
Streaming SSR and Skeleton Screens
Streaming SSR allows pages to deliver content in chunks as each piece becomes ready, rather than waiting for the full page to complete. niranar.com uses skeleton screens — placeholder layouts that fill in as data loads. Users see the page structure immediately; listings populate as the Supabase queries return results.
This pattern is a well-established approach to managing perceived performance. The technical mechanism is Streaming SSR; the user experience is a platform that feels fast even when fetching data from a large catalog.
Supabase: One Service, Five Jobs
The Solo Developer Management Problem
Building a platform alone is fundamentally a management problem before it is a technical one. A conventional backend architecture requires separate deployment, configuration, and ongoing maintenance for each service: a relational database, an authentication system, an API layer (REST or GraphQL), file storage, and optionally a realtime subscription layer. Each service has its own update cadence, monitoring requirements, and failure modes.
Supabase consolidates all of this into a single platform. The value proposition is not just cost — it is cognitive load. One dashboard, one set of API keys, one service to monitor, one billing relationship.
For niranar.com, the active components are database (PostgreSQL), API access, and serverless functions. Authentication and file storage are available in the same Supabase project, ready to enable when the product roadmap reaches those features.
PostgreSQL as the Foundation
It is worth being explicit about what Supabase actually is: a managed Backend-as-a-Service layer built on top of PostgreSQL. This is not a proprietary database or a novel storage engine — it is decades of battle-tested relational database technology with a developer-friendly API surface on top.
For developers familiar with Firebase, Supabase is often described as the open-source PostgreSQL alternative. The comparison is useful because it highlights the architectural difference: Firebase uses a proprietary document database (Firestore), while Supabase uses standard relational SQL. For a marketplace with structured listing data, locations, availability dates, and price tiers, relational data modeling is a natural fit.
niranar.com's search backend, detailed in our search architecture article, runs on Supabase PostgreSQL queries. When a user filters by location, date range, guest count, or amenities, those filters translate into PostgreSQL WHERE clauses and JOIN conditions — predictable, debuggable, and optimizable using standard SQL tools.
Development Velocity in Beta
Supabase's dashboard provides real-time table management, API key management, and query inspection. Schema changes are reflected in the API immediately — there is no need to write and deploy a separate API layer that mirrors the database structure.
For a solo developer working through a beta feature list, this eliminates an entire category of synchronization work. The database is the API, until more sophisticated access patterns require custom logic.
AWS Amplify: Choosing, Not Defaulting
The Vercel Question
Most Next.js applications deploy on Vercel. This is the obvious choice — Vercel builds and maintains Next.js, the integration is seamless, the deployment workflow is well-documented, and the developer experience is excellent. Choosing Vercel for a Next.js project is a reasonable decision that requires no justification.
niranar.com chose AWS Amplify instead. This deserves explanation.
Cloud provider diversity. Smart Maple builds products across multiple clients and platforms. kotireitti.fi, the Finnish travel platform also in Smart Maple's portfolio, deploys on a different infrastructure. AWS Amplify for niranar.com adds cloud provider diversity across the portfolio — reducing concentration risk and broadening the team's practical deployment experience across major cloud platforms.
AWS ecosystem fit. AWS Amplify provides native integration with the broader AWS infrastructure. As niranar.com scales beyond beta, expansion into other AWS services — CloudFront for CDN, Lambda for additional serverless logic, S3 for storage — follows naturally from the existing deployment foundation. The integration surfaces are already configured.
Deliberate evaluation over default selection. The choice to evaluate Amplify against Vercel rather than defaulting to Vercel reflects a systematic approach to technology decisions. Vercel may well have been the better choice on some evaluation criteria. The point is that the question was asked. Defaults are valid starting points for evaluation, not substitutes for it.
Leaflet: Cost-Conscious Engineering for a Pre-Revenue Product
The Real Cost of Map Interactions
Vacation rental platforms are map-intensive. Users want to see where properties are located, compare nearby options, and understand the geographic context of a listing — beach proximity, town center distance, neighboring properties. niranar.com has coordinates for its listings, making maps an active search and discovery tool rather than a decorative element.
Google Maps API charges per map load and per interaction. At low traffic volumes, these costs are negligible. As usage grows, the API billing grows proportionally. For a product that has not yet established a revenue model, variable API costs tied to user engagement create an awkward incentive structure: more users browsing the map means higher operating costs with no corresponding revenue.
Developers in the Next.js and startup ecosystem will recognize this pattern. Google Maps is the default choice for mapping because of its feature richness and brand recognition — but its pricing model is designed for businesses that have already validated their product and can afford variable infrastructure costs.
What Leaflet Provides
Leaflet is open-source and free. No API key required, no per-request pricing, no monthly bill tied to map load volume. The core functionality covers what niranar.com needs in beta: rendering property locations on a map, supporting zoom and pan interactions, and displaying listing pins that users can interact with.
Leaflet does not provide Google Maps' full feature set — Street View, Places API, turn-by-turn navigation. But niranar.com's beta does not need those features. The requirement is geographic property visualization and basic map-based browsing. Leaflet addresses this completely.
This is a recurring theme in the niranar.com stack: building what the product needs now rather than architecting for every possible future requirement. The Google Maps upgrade path exists when the product reaches a traffic and revenue level that justifies it.
Claude Code: Expanding What One Developer Can Build
The Scale Question
niranar.com launched its beta with 300,000+ active listings across Mediterranean Turkey — a catalog that in traditional development terms would require a team to build and maintain. It was built by one developer.
This is the practical context for Claude Code. AI-assisted development, when used as an execution accelerator rather than a code generator on autopilot, allows a solo developer to operate at a higher throughput than would otherwise be possible.
The distinction matters: Claude Code does not replace architectural judgment, product decision-making, or quality control. The developer still designs the system, defines the requirements, reviews the output, and owns the product. What changes is the speed of execution on well-defined tasks — component scaffolding, repetitive API integration patterns, test case generation, boilerplate that would otherwise consume disproportionate development time.
What This Means for a Solo Developer Building a Marketplace
A marketplace has a predictable set of recurring patterns: listing pages with similar structure, search filters applied across multiple dimensions, map integration components that follow the same mounting pattern, form validation that uses the same rules. These patterns are well-defined — a developer who knows exactly what they want can produce them faster with an AI collaborator than without one.
For niranar.com, this translated into a compressed development timeline. The choice to use Claude Code throughout the project is part of the same philosophy that drives the rest of the stack: use leverage where it exists, and apply focused human judgment where it matters.
A Broader Signal
niranar.com is an early example of a product category that will become common: solo-developer platforms at scale, made possible by AI-assisted tooling. The fact that a single developer can bring a 300,000-listing marketplace to beta is a capability shift worth noting — not as a novelty, but as a signal of what modern development tooling makes achievable.
What Was Deliberately Left Out
No Authentication System
niranar.com does not have user accounts, login flows, or session management in its current beta. This is not an oversight — it is a deliberate scope decision.
The beta focuses on listing discovery: finding the right property, seeing its location, understanding its features and pricing. User authentication creates a parallel product surface: registration flows, password recovery, profile management, notification preferences, account security. Building and testing this infrastructure before the catalog value has been validated adds complexity and lead time without advancing the core beta hypothesis.
Supabase includes a built-in authentication module. When the product roadmap calls for user accounts, enabling it within the existing Supabase project is significantly less work than building from scratch. The infrastructure is deferred, not abandoned.
No Payment Processing
The same logic applies to payments. The current beta has no booking flow and processes no transactions. niranar.com at this stage is a discovery platform — users browse, filter, and explore properties. The reservation and payment layer comes later.
Payment integration is non-trivial work: payment provider selection, currency handling (niranar.com prices in EUR), refund and dispute flows, PCI compliance, fraud detection considerations. Introducing this complexity into a beta that is primarily testing whether users can find valuable listings efficiently adds engineering scope that competes for attention with the core product questions.
The product development sequence matters: validate the listing discovery experience first, then layer on the transaction infrastructure once the catalog's value has been established.
Reading the Stack as a Whole
niranar.com's technology choices form a coherent system rather than a collection of independent selections. Each decision answers the same two questions: what does a solo developer need to build and maintain this productively, and what does a beta marketplace need to validate its core hypothesis?
Next.js provides server-rendered pages that search engines can index across a 300,000-listing catalog. Supabase consolidates the backend into a single managed platform. AWS Amplify deploys to a cloud ecosystem with a known expansion path. Leaflet brings geographic property visualization without variable API costs. Claude Code extends the development capacity of a single-person team to marketplace scale.
The absent features — authentication and payments — are not gaps. They are scope boundaries that keep the beta focused on its actual purpose: connecting travelers with vacation rental properties in Mediterranean Turkey, and proving that purpose works. For the broader architecture behind these decisions, see niranar.com's Technical Architecture.
niranar.com is a Turkish vacation rental marketplace developed by Smart Maple. Beta launch: April 1, 2026.
Related Articles
MLOps Guide: Taking Machine Learning Models to Production [2026]
87% of machine learning models built by data science teams never reach production. The models work — they pass cross-validation, they score well on holdout sets, they demonstrate genuine predictive value. The problem is not the modeling. The problem is everything that happens between a notebook experiment and a reliable, monitored, production system. MLOps is the discipline that closes that gap. This guide covers the full MLOps stack: maturity levels, tooling choices (MLflow, DVC, Kubeflow
Read MoreLLM Fine-Tuning Guide: Custom Model Training with LoRA and QLoRA [2026]
General-purpose LLMs are impressive. They can write code, summarize documents, answer questions, and translate between languages with reasonable accuracy. But "reasonable" is not good enough when your application requires consistent output format, domain-specific terminology, a particular tone, or behavior that the base model was never trained to exhibit. That gap is where fine-tuning matters. Fine-tuning updates a model's weights on your specific data, changing how the model behaves — not
Read MoreComputer Vision Applications: Object Detection, OCR, and Industrial AI [2026]
Computer vision has moved well past the research phase. The models are trained, the frameworks are mature, the hardware is accessible, and the use cases are generating measurable returns. What was a specialized capability requiring deep expertise in 2018 is now deployable infrastructure — if you know which component to reach for and where the real complexity lives. This guide covers computer vision applications across industrial, medical, logistics, and document processing domains. It expl
Read More