Another Turn

Home Page
How it works
List a toy
Pick up

Inspiration

Another Turn started from something very ordinary and very familiar as a parent.

I would often see big toys outside homes, in apartment corridors, or near play areas, slides, ride-on cars, walkers, activity tables and many of them looked perfectly usable. At the same time, I was about to buy one of those toys for my own child, even though I knew it might be used for only a short time and then take up space at home.

That made the gap very clear: many parents already have toys that are still valuable, but they sit unused once a child outgrows them. Another Turn was built around that idea every toy deserves another turn.

The app makes toy sharing practical by combining rental, resale, and lending in one marketplace. Since this involves parents, children’s products, payments, and local pickup, we also wanted trust, moderation, and payment handling to be part of the product from the beginning, not something added later.

What it does

Another Turn is a hyperlocal toy marketplace where parents can browse toys nearby, save items, create booking requests, message other users, and complete payments through Razorpay sandbox.

Owners can list toys with pricing, availability, pickup logistics, images, and condition details. They can choose whether a toy is available for rent, resale, or both.

Admins can review listings, verify owners, inspect payment records, handle refunds, and manage moderation and safety workflows. This is important because the app is not just a catalog, it is a marketplace where trust matters.

How we built it

The app is built with Next.js App Router and deployed on Vercel. The frontend handles the marketplace experience: browsing toys, viewing listings, creating bookings, managing owner flows, and accessing admin screens.

The backend logic lives inside Next.js route handlers under app/api/* and server-only service modules under lib/. The browser never talks to the database directly. All database access is handled on the server side.

For the database, we chose PostgreSQL on AWS Aurora as the system of record. This was a deliberate architectural choice because Another Turn is a relational, transaction-heavy marketplace.

A booking connects many pieces of state: the user, toy listing, owner, availability, payment, refund, review, moderation state, and sometimes dispute history. PostgreSQL fits this well because it lets us model these relationships clearly using tables, joins, constraints, and transactions.

Aurora gives us managed PostgreSQL on AWS, so we get the flexibility of SQL along with a production-ready database foundation. It suits the app better than a pure NoSQL approach because our main challenge is not massive key-value throughput. The challenge is keeping marketplace state consistent — especially around bookings, payments, approvals, and refunds.

Core product state such as listings, bookings, notifications, saved items, trust-and-safety records, owner verification, and payment state is persisted in Aurora PostgreSQL. Razorpay handles checkout and payment verification. AWS SES is used for email flows. AWS S3 handles uploaded avatars and listing images.

The database schema is bootstrapped through SQL scripts in scripts/, which keeps the structure explicit, inspectable, and easy to reason about as features evolve.

Challenges we ran into

The main challenge was keeping frontend behavior aligned with backend state as the app grew. Marketplace workflows involve multiple roles and state transitions, so a change in one area often affected several others.

Several features needed both schema changes and UI changes at the same time, especially around bookings, admin moderation, listing approval, and payment metadata.

We also had to resolve a number of integration issues:

schema mismatches between existing data and newer features
idempotent payment callback handling
sandbox Razorpay flows that needed to work without false failure states
SES and S3 configuration details that had to be handled carefully in production-style code paths
making sure setup and bootstrap scripts did not wipe out live data on reruns
keeping public listing queries separate from admin-only moderation state

Accomplishments that we're proud of

We turned the project into a real end-to-end marketplace instead of a static prototype.

The app now supports:

a Vercel-deployed Next.js marketplace experience
authenticated user and admin workflows
listing creation with images, pricing, availability, and pickup details
listing approval and owner verification
booking requests with validation and availability checks
Razorpay sandbox payment flow
payment callback handling with invoice and receipt metadata
notifications and email-ready hooks
trust and safety workflows like blocking, reporting, and moderation
production-oriented database ownership and role handling

We are also proud that the app now has a consistent data model across user, owner, listing, booking, payment, and admin flows.

What we learned

We learned that marketplace apps are mostly coordination problems.

The hard part is not just building pages. It is keeping different roles and different states consistent across the product. A toy can be listed, pending review, approved, booked, paid for, picked up, returned, disputed, or removed. Each of those states affects what users, owners, and admins are allowed to do.

We also learned that:

schema discipline matters more than adding features quickly
approval and payment logic must be server-side
idempotency is essential for payments and callbacks
setup scripts are useful, but they must be treated as bootstrap tooling, not runtime logic
a clean PostgreSQL data model makes the frontend easier to stabilize
Aurora is a strong fit when the product needs relational correctness, not just storage

What's next for Another Turn

The next steps are mostly around polish, reliability, and marketplace readiness:

finish replacing any remaining mock-backed paths with fully persistent data
tighten the admin experience for moderation, payments, and user review
improve invoice and receipt rendering so documents are easier to use in support workflows
expand notifications and email flows through SES, which is currently in sandbox
add more robust analytics and audit logging for marketplace operations
improve search, discovery, and location-aware browsing
support better availability handling for overlapping bookings
add stronger owner and parent verification flows
continue reducing edge cases between booking availability, payment state, and listing lifecycle

Another Turn started with a simple parenting observation: toys do not stop being useful just because one child has outgrown them. The goal is to make reuse practical, local, and trustworthy, so more toys get another turn.