Every marketplace begins with a frustration. Ours started in a kitchen in south London, surrounded by stacks of paperbacks that had been read once and were quietly waiting for a second life. We knew there were thousands of readers across the UK with the same problem: brilliant books, no easy way to pass them on. We did not want to start a publishing house. We wanted to start a community. ReReadz is the result, and the way we built it is almost as interesting as why.
Why we chose to build with Lovable
Traditional marketplaces take years and seven-figure budgets. We had neither. What we did have was an opinionated vision, a small team, and a refusal to compromise on design. Lovable became our engine room. It gave us an AI-native development environment where ideas could be shipped in hours rather than sprints. We could describe a feature, see it built, refine the copy, tweak the spacing, and have it live behind a feature flag the same afternoon.
For a small founding team, that velocity is not a luxury. It is the difference between launching and never launching at all.
The stack: boring on purpose
ReReadz runs on a deliberately conventional stack: React 18, Vite, TypeScript and Tailwind CSS on the front end, with Supabase handling Postgres, authentication, storage and edge functions on the back end. We layered Stripe Connect for marketplace payments, Sendcloud for shipping, and the Google Books API for ISBN metadata.
This is not a stack you would describe as cutting-edge. That is the point. Boring infrastructure means our energy goes into product decisions, community design and seller experience instead of debugging exotic frameworks at midnight.
From idea to first listing in a weekend
The first version of ReReadz was scaffolded in a single weekend. By Sunday evening we had authentication, a listings table with row level security, an upload flow for book covers, and a search page that actually returned results. The code was rough, but it was real, and we could put it in front of friends.
That early feedback shaped everything. Sellers told us cover photos were too fiddly to take. So we added a barcode scanner powered by the camera and the Google Books API, which fills in the title, author and cover automatically. Buyers told us they could not always tell whether a book was genuinely "very good" or stretching the truth. So we standardised condition descriptions with visual examples and moved to a strict five-tier rubric.
What Lovable changed about how we work
Three things stand out.
First, design and code stopped being separate disciplines. When you can describe a UI change and watch it appear, the conversation shifts from "is this technically possible" to "is this the right thing for the user". Designers, founders and engineers end up looking at the same artefact at the same time. The arguments get better and the meetings get shorter.
Second, prototyping became free. We no longer debate features in the abstract. If we are unsure whether the homepage should lead with personalised recommendations or curated collections, we build both, ship them behind a flag, and let the data decide. That changes the culture of the team. Opinions still matter, but they have to survive contact with a working prototype.
Third, the bar for polish went up. Because shipping is fast, there is no excuse for a half-finished empty state, a missing skeleton loader or a broken mobile layout. Lovable made it cheap to do the small things right, and small things compound.
The hard parts AI did not solve
It would be dishonest to pretend the journey was frictionless. AI tooling accelerates the work, but it does not replace judgement. We still had to make hundreds of decisions that no model could make for us.
How should we handle a sale where the buyer pays but the seller never posts the book? What happens when two buyers try to checkout the same listing within seconds of each other? How do we make a charity onboarding flow that respects the volunteers running the shop? These are product questions, not engineering questions, and they took weeks of conversations with sellers, charity managers and book club organisers to get right.
What AI gave us was time. Because the plumbing was fast, we could spend more of our days listening to users and less of them wrestling with build configs.
Lessons for other founders
If you are thinking about building a marketplace, or any product with a strong community angle, here is what we would tell our past selves.
- Ship something embarrassing in the first week. The fastest way to learn what to build is to put a rough version in front of real users. Lovable makes that achievable for almost any team.
- Pick boring infrastructure. Save your novelty budget for the parts of the product that are actually differentiated.
- Treat copywriting as a feature. The words on a button matter as much as the colour. Iterate on language with the same rigour you apply to code.
- Build the community before you scale the catalogue. A thousand books and ten passionate sellers will out-perform ten thousand books and a silent listings page every time.
- Measure trust, not just transactions. Repeat purchases, seller reviews and community participation are the metrics we care about most.
Where ReReadz is going next
We are heads-down on a few things over the coming months: better discovery for niche genres, a smoother bundling experience for sellers with large collections, and a deeper set of community features around book clubs and reading challenges. Each of these started life as a paragraph in a document and a quick prototype shipped to a handful of users. That feedback loop is the heartbeat of the company.
If you want to see what we are building, the easiest thing is to list a book you no longer need or browse what the community is selling this week. Every listing helps another reader find a story, and every sale keeps a book out of landfill.
People also ask
What is Lovable?
Lovable is an AI-native development platform that lets small teams build production web applications by combining natural-language prompts with conventional code. We use it to ship features at the pace of a much larger team.
Can you really build a marketplace without a large engineering team?
Yes, with the right tools and a disciplined scope. The hard parts are product decisions, trust and community, not the code itself.
Is ReReadz an Amazon alternative?
We are a community-first marketplace for second-hand books in the UK. We focus on independent sellers, charity shops and readers who care about sustainability rather than competing on catalogue size.
How can I support ReReadz?
List the books you no longer read, follow your favourite sellers, and tell another reader about us. Word of mouth is how community marketplaces grow.