Lessons from niranar.com: The Real Cost of Platform Decisions

This article series has spent ten pieces explaining what niranar.com built, how it works, and why it was designed the way it was. This final piece turns to a harder question: what did building it actually teach?

Most case studies describe success. Fewer admit what didn't work. The smallest number describe what worked but came with a price — what was deferred, and which decisions will need revisiting as the product matures. That third category is what this article attempts. Every decision documented in this series had a rationale. That rationale had a cost. Naming those costs is how this series ends honestly.

Five decisions stood out: Supabase as the sole backend service, Leaflet over Google Maps, no authentication or payment in beta, EUR pricing with a Turkish-language interface, and AI-assisted development via Claude Code. Each decision represents a trade-off. Together, they tell the real cost of building this platform at this scale with this team.

Lesson 1: Supabase as the Sole BaaS — Speed at a Scale Ceiling

The center of niranar.com's backend decision-making is Supabase. For a solo developer, the choice is compelling: database, API layer, and dormant authentication infrastructure in a single managed service. Integration complexity stays low. Operational overhead stays minimal. Debugging stays contained to one system. When you're building alone, the compounding value of not context-switching between services is hard to overstate.

The cost of this choice becomes visible at scale.

niranar.com's search runs over 300,000+ listings using multi-parameter queries — location, date range, guest count, property type, amenities — all handled through PostgreSQL. PostgreSQL's full-text search works. But Elasticsearch, or a dedicated search service like Algolia, is purpose-built for this workload. Relevance ranking, faceted filtering, typo tolerance, synonym management, geospatial scoring — these are first-class features in a search engine. In PostgreSQL, they're layers you build on top.

For beta, this trade-off was deliberate and defensible. No additional service, no additional cost, no additional architecture. A user searching for "villa in Bodrum" gets results. That's sufficient for catalog validation. But the next team should see this ceiling clearly: when search quality becomes a competitive differentiator — when users expect ranked results, "did you mean?" suggestions, or relevance tuning — the path forward involves either adding a search layer on top of Supabase or migrating to a dedicated engine. This decision has been deferred, not canceled. Visible deferrals are more valuable than hidden ones.

For the technical context, see niranar.com's Search Implementation and Technology Stack.

Lesson 2: Leaflet Over Google Maps — Free Is Not Free

The map decision looked straightforward. Google Maps charges per request. For a pre-revenue beta, a cost line that grows with usage before any revenue flows is a genuine risk — especially on a platform where map interactions are central to the user experience. Leaflet is open-source. No API key. No per-tile fees. No invoice surprises.

But "free" here means "paid in a different currency": developer time.

Google Maps comes with geocoding, reverse geocoding, places autocomplete, tile management, clustering libraries, and mobile touch handling — all through well-documented SDKs. For a vacation rental platform, these features matter directly: users type city names and expect geographic results, properties on the map need meaningful cluster visualization, mobile interactions need to feel native. Google Maps handles much of this out of the box.

With Leaflet, each of these requires a separate decision. Tile provider selection and configuration is independent. Geocoding requires integration with a separate service — Nominatim, Mapbox, or another source. Mobile touch behavior requires custom handling. Cluster visualization needs an additional library or custom implementation.

niranar.com built what it needed. The map works. Leaflet integration is complete. But the path to that result involved building significant surface area that Google Maps would have provided as defaults. The choice wasn't wrong — unpredictable API costs on a pre-revenue product are a real risk worth controlling through engineering investment. But the next team should understand the actual ledger: Leaflet is not "free maps," it's "maps that require time investment." When scale grows and map UX becomes a differentiator, this equation deserves a fresh review.

For more on the integration approach, see API Integrations and Map Architecture.

Lesson 3: No Auth, No Payment — What Discovery-First Feels Like from Inside

The niranar.com Beta Strategy article laid out the strategic logic: discovery before transactions. In a two-sided marketplace, the fundamental question isn't whether a payment flow works — it's whether users actually search on your platform at all. Validating discovery before building transactional infrastructure is a well-established lean startup approach, echoing the "build-measure-learn" loop applied to product sequencing.

That logic is correct. But this lesson covers the dimension the strategy article didn't: what it feels like to run this strategy from inside the product.

When you have a functional search experience, real results, and a user who found a villa in Fethiye they actually like — and then they can't book — the moment requires something harder than strategic conviction. It requires trust that catalog and search validation comes before transaction capability in the right order, even when the user's signal is "I want to buy something and can't." That gap between user intent and product capability is real, and it produces real friction.

Running a platform without conversion is psychologically different from running one with it. There are engagement signals, but no sales. Search activity, but no commitment. A growing catalog, but no transactions completing. The strategic framing — you're measuring discovery quality, filter usage, search patterns — is accurate. But "accurate framing" and "comfortable situation" are different things.

What the next team should know: discovery-first looks elegant in strategy documents. In practice, it requires holding the priority order while users are expressing the desire to do more than the product allows. The patience required is not just external (managing user expectations) — it's internal (managing your own uncertainty about whether the sequence is right).

Lesson 4: EUR Pricing, Turkish Interface — Serving Two Audiences With One Surface

niranar.com's most interesting tension appears on a single screen: all content in Turkish, all prices in EUR.

This isn't a design error. It's a deliberate dual-audience signal. EUR pricing targets the international tourists visiting Mediterranean Turkey — the Airbnb and Booking.com user who books from Amsterdam or Berlin and expects pricing in a currency they understand. TRY pricing introduces exchange rate uncertainty for that audience; EUR removes it. The Turkish-language interface targets the supply side — local property owners in Antalya, Bodrum, and Fethiye who are more likely to engage with a platform that speaks their language. The logic on both sides holds.

But serving two audiences through one interface creates UX tension that neither audience fully escapes.

An international tourist arrives expecting a browsable experience. The Turkish navigation labels — Destek (Support), Ev Sahipliği (Hosting), Şirket (Company) — are opaque. The property description might be in Turkish. The support pathway is Turkish. The user finds a property they want, sees a price in a currency they recognize, but can't navigate easily past that point. Their discovery experience is functionally capped by language.

Meanwhile, a Turkish host thinking about listing their property sees EUR pricing throughout. Turkish rental markets are priced and thought about in TRY. Framing value in EUR requires a mental exchange-rate calculation that fluctuates. The friction is small but real.

Serving both audiences through one surface is viable at beta scale. But the next milestone — April 2026 launch with authentication and payment activated — may be the moment to revisit localization. Adding language selection or a localization layer comes with real costs: content translation, UI parallelism, testing. Seeing this trade-off before encountering it is more useful than discovering it after.

For the full UX analysis, see UX Decisions and Design Philosophy.

Lesson 5: Solo Developer + Claude Code — What AI Changes, What It Doesn't

niranar.com was built by one developer using Claude Code. A 300,000+ listing catalog, multi-parameter search, Leaflet map integration, custom calendar implementation, two-sided navigation, mobile-responsive design — all from a single-person team, on a timeline that would have required a full team by historical standards.

This is real. AI-assisted development changed what was buildable at individual scale. That's not an abstraction — it's a concrete output visible in the product.

But this lesson is about the half of that story that's less often told: what Claude Code didn't change.

The list of what AI changed is concrete: repetitive code patterns were written faster, integration boilerplate was generated quickly, debugging suggestions accelerated iteration, feature implementation surface area expanded significantly. The compound effect of these accelerations is what enabled the scope.

The list of what AI didn't change is equally concrete: architectural decisions remained human. Supabase or a dedicated search engine? Leaflet or Google Maps? Auth out of beta scope? EUR or TRY? None of these were resolved by AI. They're strategic questions whose correct answers depend on constraints, risk tolerance, budget, and audience — context that lives with the person making the product, not the tool helping them write code. AI can process context when given it. It doesn't carry context across a product's lifetime.

Scope management also remained human. AI makes writing easier; it doesn't make deciding what to write easier. The decision to exclude auth and payment from beta scope was a strategic sequencing call, not a technical limitation. Making that call correctly — understanding its implications, holding it under pressure, communicating it to users — required judgment that no tool provides.

What the next team should take from this: Claude Code changes what one person can build. It doesn't change what one person needs to decide. Calibrating expectations correctly — understanding AI as a capability multiplier on execution, not a replacement for judgment on direction — is how the tool gets used well.

For context on the beta strategy and timeline, see niranar.com's Beta Strategy.

Where the Five Lessons Converge

These five lessons look independent at first: a database decision, a map choice, a beta strategy, a language-currency tension, a development tool assessment. But they all answer the same structural question: for a pre-revenue, single-developer platform in beta, which trade-offs are acceptable?

Each decision followed from that question. Supabase accepted a scale ceiling in exchange for operational simplicity. Leaflet accepted developer time cost in exchange for API cost control. No auth/no payment accepted user friction in exchange for sequencing clarity. EUR plus Turkish UI accepted dual-audience tension in exchange for reaching both sides of the market. Claude Code accepted the boundaries of AI judgment in exchange for individual-scale execution capacity.

All of these decisions are defensible and documented. But defensible doesn't mean permanent. Context changes: a team grows, a budget increases, search quality becomes competitive, international users become the majority. When any of those shifts occur, each of these decisions re-enters the conversation. The value isn't in the decisions themselves — it's in understanding why each decision was made and what condition would make it worth revisiting.

Many case studies document what was built. Fewer document what it cost. The smallest number document both — and include an honest account of which decisions are holding and which are deferred. That third category is the most useful artifact a product team can leave behind for the next team that inherits their work.

For the full series: Product Introduction, Technical Architecture, Data Normalization, SEO Architecture, and Market Analysis.

Conclusion

niranar.com's article series set out to explain the product from every angle. This final article completes that explanation with a different kind of honesty: documenting which decisions had costs, where those costs landed, and what the next iteration should see clearly.

There are no perfect decisions when building a marketplace platform. There are only defensible trade-offs given current constraints. Supabase creates a scale ceiling. Leaflet requires time investment. Running without auth demands patience. Dual-audience design generates tension. AI amplifies execution without replacing judgment. These are the real costs of the beta as it exists.

That honesty is a different kind of trust signal than technical competence. Describing what works is easy enough. Describing what it cost is harder. For teams facing similar problems — building two-sided marketplaces, making BaaS-versus-dedicated-service decisions, running discovery-first product strategies — niranar.com's record shows where the trade-offs are and what the next questions will be.