Designing and Leading a New SaaS Marketplace Platform

Context

StanNaDan is a new short-term rental marketplace built as a separate system from an older platform. The previous system informed product behavior and supplied legacy data, but the new application was designed and implemented from scratch.

I work as the main developer on a small team and am responsible for a large part of the platform's architecture and implementation. For complex requirements, I work with the technical lead to evaluate impact and decide whether a capability belongs in the current phase or should be deferred.

My role

My responsibilities have included:

• architecture and technology decisions
• framework and starter selection
• database modeling
• API design and route protection
• frontend state management
• search architecture
• logging and observability
• deployment architecture
• development workflow
• code review and shared engineering standards

I remain hands-on with implementation while helping the team maintain consistent technical practices and make deliberate product tradeoffs.

Technical direction

Key decisions included:

• Laravel for the backend
• Next.js and TypeScript for the frontend
• Redux Toolkit and RTK Query for application state and API communication
• Meilisearch for fast geographic and attribute-based candidate selection
• MySQL for relational data and date-dependent business rules
• Rollbar for application error monitoring
• Docker-based application environments
• Bitbucket Pipelines for production CI/CD
• Jira to improve planning and prioritization

One of the most important architectural choices was separating the responsibilities of Meilisearch and MySQL instead of forcing the entire search problem into one system.

Search architecture

Property search follows a multi-stage flow.

Meilisearch first narrows the candidate set using relatively static and index-friendly criteria, including:

• geographic radius
• guest capacity
• property characteristics
• amenities and equipment
• booking options
• parking and garage options
• payment options

The backend then uses MySQL and application logic for the dynamic parts of the request:

• availability for selected dates
• existing reservations
• manually blocked dates
• minimum-stay rules
• booking deadlines
• check-in and check-out restrictions
• stay-specific pricing

This division keeps geographic and attribute filtering fast while preserving a single, consistent place for calendar and pricing rules.

Pricing, availability, and reservations

The most complex domain is the interaction between price, availability, reservations, and external calendars.

A stay price can depend on:

• base, weekday, or weekend pricing
• guest count and additional-guest charges
• prices set for individual dates
• weekly, monthly, or yearly recurring price rules
• early-booking and last-minute discounts
• length-of-stay, seven-night, and twenty-eight-night discounts
• cleaning and other additional charges
• parking or garage selections
• tourist tax
• administrative discounts

The public frontend provides the price preview, while the backend performs the authoritative calculation when the reservation is created. Price inputs are also captured with the reservation so later listing changes do not rewrite historical booking values.

Availability uses the same business rules across search and booking. It accounts for listing status, manual blocks, overlapping reservations, minimum stays, booking deadlines, restricted arrival or departure days, and maximum booking periods where configured.

Reservations move through draft, pending, confirmed, cancelled, and completed states. The platform supports both instant booking and requests that require owner approval.

External calendar synchronization

The platform uses iCal import and export to synchronize availability with services such as Airbnb and Booking.com.

Imported events are regularly synchronized and participate in the same availability checks as internal reservations. The platform also detects conflicts involving imported events, existing reservations, and manually blocked dates.

The boundary is deliberate: this is availability synchronization, not direct OTA pricing or payment integration.

Legacy data migration

I also worked on migrating data from the previous WordPress system and older administration application. The migration included approximately:

• 1,332 properties
• 880 owners
• 1,292 comments
• 340 guest records
• additional fallback guest records and user data

Properties, owners, review-related content, and pricing data were carried into the new model without migrating old reservations.

Production architecture

I designed production delivery as a separate Docker infrastructure project spanning three repositories:

• the Laravel backend and administration application
• the Next.js frontend
• deployment infrastructure

The application pipelines build versioned Docker images and publish them to the image registry. A dedicated production pipeline then triggers deployment over SSH.

Production uses a blue/green model. New backend and frontend containers start in the inactive slot, health checks run, database migrations are applied, and web routing switches only after the new version is healthy. The previous application containers are then stopped, while persistent services such as MySQL, Redis, Meilisearch, and Caddy remain in place.

Versioned images also make it possible to redeploy an earlier release when rollback is required.

Engineering scope

The codebase includes approximately:

• 19 Laravel modules
• 164 database migrations
• 159 module API routes
• 46 backend controllers
• 66 Next.js pages
• 1,100+ TypeScript and TSX source files
• 148 predefined search locations
• 45+ Laravel notification classes
• 18 Artisan commands
• 40+ queued jobs and listeners

These figures describe engineering scope, not product traction.

Current status

The project is in its final development phase. Legacy data migration is complete, the production Docker architecture is prepared, and the current focus is bug fixing and production readiness.

StanNaDan demonstrates hands-on technical leadership across architecture, complex domain logic, data migration, team standards, and production delivery.