Baqreads — Nando

Act 1 of 8

Overview

Baqreads is a book club whose readings are pinned to a hand-drawn world map, and what began as a map grew into a small product, because each stage made the next real need visible.

Baqreads is a book club whose readings are pinned to a hand-drawn world map, one country per book. I designed and built the public site, the visual system behind it, a members-only reviews platform and a page builder that lets the club’s owner change the site on her own, from the first idea to production.

The project started as a map and ended up as a small product, which is the interesting part of the story, because each stage appeared when the previous one made a real need visible. The product itself is in Spanish, so the screens in this case study stay in Spanish and the captions describe them.

Case study sheet for Baqreads showing the home page with an open-book illustration, the reading map with a Mexico book card, two phone layouts and the club reviews page, all in a cream and forest-green hand-drawn style — Baqreads: a book club that travels the world one book at a time, and a site designed to grow with it. The home page, the reading map, the phone layout and the reviews, as one sheet.

Overview sheet with panels for the site, the design system in light and dark, the before and after of the club's tools, product decisions, flows, architecture and an anniversary video — The whole project on one sheet: the site, the design system, the move from four tools to one place, and the decisions, flows and architecture behind the reviews platform.

Product design
UX & UI
Design system
Reviews platform
Page builder

Act 2 of 8

Four tools, one place

The club lived in a WhatsApp group, a link in the bio, a suggestions form and a Substack, so reviews got lost between messages, and the question became how a small, non-technical club could keep one living home on the web.

The club lived in four places at once: a WhatsApp group for conversation, a link in the bio for everything else, a form for suggestions that landed in a spreadsheet nobody opened, and a Substack for the founder’s long texts. Reviews and opinions got lost between messages, and nothing connected a book to what people had said about it.

Before and after diagram: on the left a WhatsApp group, a link in the bio, a form and a Substack; on the right one place with the reading map, member reviews, comments, links and contact, and an admin panel — Before, four tools; now, one place organized around the map. The Substack stays for the founder's long essays, and the site gives it context.

The problem

How might a small, non-technical club keep a living, beautiful home on the web, one where every book has a place, members can write about it, and the owner can change things at midnight without asking a developer?

Three constraints shaped every decision that followed.

It has to feel like paper, not software. The club is about slow reading, so the interface should be calm, warm and a little handmade.
It has to be cheap and simple to run. I kept it to a handful of managed services with no build pipeline and no server to maintain, so a volunteer never has to babysit it.
The owner has to stay in control. She edits content herself, sees a preview before anything goes live and can undo a mistake.

Act 3 of 8

A design language of paper and ink

I turned a hand-drawn open book, a deep forest green and a cream paper with grain into a small system that every screen reuses, in light and dark, so the whole site feels like paper instead of software.

The visual identity comes from a few brand references: a hand-drawn open book, a deep forest green and a cream paper with grain. I turned them into a small system that every screen reuses, including the admin.

Cream paper and green ink. A warm paper background with grain, one ink color for text, lines and buttons, and a lighter leaf green as the accent.
Hand-drawn strokes. Irregular corners on borders, buttons and fields, and a subtle displacement filter that makes the lines on the map tremble like pen.
Two typefaces. A condensed serif for titles and a readable serif for long text.
Light and dark themes. Both are defined as tokens, so the logo (drawn as a mask) and every component change color without duplicated assets.

Color tokens, type, components and rules, in light and dark mode.

Baqreads home page in light mode with the headline Conociendo el mundo a través de las letras, an open-book illustration and a green The Cozy Hour banner — The home page in the light theme (in Spanish, like the product).

Baqreads home page in dark mode, a deep green background with cream text and the same open-book illustration — The same page in dark mode, driven by the same tokens.

And on a phone.

Act 4 of 8

The map

Every book is a pin on the country it comes from, regions fill with hatching as the club reads more, and a pin opens a card with the cover, the author and the club's reviews, on a keyboard, on touch and on a phone.

The map is the heart of the product. Every book is a pin placed on the country it comes from, regions fill with hatching as the club reads more, and a book opens in a card with its cover, author and the club’s reviews. It works with touch, with a keyboard and on a phone, where the map becomes a scrollable, zoomable surface.

Reading map with North America hatched, a pin on Mexico and a card for the book Pedro Páramo showing the club's review, plus a progress bar per world region — The reading map on desktop: hatched countries have been read, and a pin opens the book's card with the club's reviews.

World map in a hand-drawn style with the countries the club has read hatched in green — Zoomed out to the whole world.

The reading map in dark mode, with cream hatching and pins on a deep green background — The map in dark mode.

The reading map on a phone, with the world map above and the selected book card below — On a phone, the map becomes a surface you can drag and zoom.

Act 5 of 8

Decisions that shaped the product

Constraints did most of the designing, with no framework, a draft and publish flow with a live preview, conflict protection and a Spanish-first voice, all kept deliberately small so a volunteer never has to babysit it.

A few decisions set the shape of the product, each with the reason behind it.

No framework and no build step. The site is a single HTML file rendered by JavaScript, with the data in a JSON file. For a site this size that means instant deploys, nothing in the tooling to break and code a future maintainer can read in an afternoon.
Draft and publish, with a live preview. The editor shows the real site in a frame and updates it as you type, but nothing reaches visitors until you press Publish, which gives the owner room to experiment without fear.
Conflict protection. If two people edit at once, the second save is refused with a clear message instead of silently overwriting the first.
Spanish first. All labels, errors and emails are written for the club’s own voice instead of being translated afterwards.

Small by design

The architecture follows the same idea. The site is a static front end, a few serverless functions, storage for content and images, and managed services for authentication and email. The public pages read a cached JSON file, the admin writes to it through a password-protected endpoint, and the reviews platform adds authentication, a database and transactional email on its own branch, so it can launch without touching the live site.

Architecture diagram: public pages, member account, admin panel and reading map on the left; Vercel API functions and access rules in the middle; Supabase auth, a Postgres database, storage and Resend email on the right; and GitHub deploying through preview branches — From the browser to the serverless functions and the managed services behind them. Every change is tested on a preview URL before it touches the real site.

Act 6 of 8

A members-only reviews platform

Once the map was live the club wanted to write about the books, so I designed a members-only platform where reviews are drafted, approved by the owner and then published, with the owner always having the final word.

Once the map was live, the club wanted to write about the books, so I designed a members-only reviews platform on top of the same site. Before drawing any screen I agreed six rules with the club’s administrator, because rules decide what gets built and what does not.

Diagram titled Reglas antes que pantallas with six product decisions around a central box for member reviews — Six rules before screens: invitation only, club approval, a review belongs to a book and its country, comments for members only, coexisting with the Substack, and magic-link sign-in with no passwords.

What each side can do

Members sign in by invitation, write a review in an editor with a live preview, send it for approval, follow the status of their own reviews and comment on others’ reviews once they are published. The owner sees a queue of reviews waiting for approval, reads each one, approves it or requests changes with a note, gets notified through a bell and by email, and manages the members.

DraftIn reviewChanges requestedPublished

Flow diagram with two lanes: the member receives an invitation, asks for a magic link, signs in, writes with a preview and sends to review; the admin is notified, reads, decides and publishes, with side cases for changes requested, editing and unpublishing — From invitation to publication, for the member and for the admin, with the edge cases resolved in the design.

Writing

Member sign-in screen titled Entrar, with an email field and a button to receive a sign-in link, and a note that no password is needed — Sign in with a magic link, no password.

A member's list of reviews with a status tag on each one: draft, changes requested or published, and the admin's note on the one that needs changes — A member's reviews, each with its status.

Review editor with the writing form on the left and a live preview of the published review on the right — The review editor shows exactly how the review will read as you write it.

A review in the changes requested state, with the admin's note shown above the editor — When the owner asks for changes, her note sits right above the draft.

The review editor on a phone — The same flow on a phone: writing, then previewing.

The review preview on a phone — The same flow on a phone: writing, then previewing.

Approving

Admin queue with tabs for reviews to check, changes requested, published and unpublished, and two reviews waiting for approval — The admin's queue of reviews waiting for approval.

The admin panel with the notification bell open, listing reviews that have arrived — The bell lists the reviews that have just arrived.

Members screen with an invite field and a list of five demo members with deactivate and make admin buttons — Members: invite, deactivate or make admin.

Reading

The public reviews page with a card per published review — The public reviews page.

A published review on desktop, with the book's cover, author, a link to see it on the map and the member's text — A published review, on desktop.

A full published review page, from the header and cover down to the text and the comments section — A full review, from the book it is about down to the comments.

A published review on a phone — Reviews read the same way on a phone.

Status. The reviews platform is built and has been tested on a private preview, and it is launching soon. The screens shown here use demo members and demo reviews.

Act 7 of 8

A site the owner can reshape

The owner wanted something like Wix or Squarespace, but only so much, so I built the middle level of freedom, where she can rearrange, add blocks and create pages, with a preview, a publish step and an undo that make it safe to play.

After the reviews, the owner described a different need. She gets ideas late at night, like adding a section to a page or a whole new tab, and she wanted to try them without learning GitHub, “like Wix or Squarespace, but only so much.”

That last phrase became the design brief. I defined three levels of freedom and built the middle one, which gives her real structural control without letting her break the design.

Edit what exists. Texts, books, links and contact, which was already there.
Rearrange and add. Reorder or hide the home sections, add blocks anywhere and create new pages that appear in the menu. This is the level I built.
Design from scratch. Free layout, colors and fonts, which I left out on purpose, because every block already follows the design system and anything she builds looks like Baqreads.

The blocks are a title, text, an image, an image with text, a gallery, a quote, a button, a YouTube or Spotify embed, cards, a green callout and a hand-drawn divider.

Guardrails that make it safe to play

Live preview. The page being edited is shown in desktop and phone sizes while she works.
Nothing is public until Publish. Hidden pages never leave the server.
Version history. Every publish keeps the previous version, and the last 25 can be restored with one click.
Safe by construction. Links are limited to safe destinations, embeds to YouTube and Spotify, and every block is validated on the server, so a typo or a pasted script cannot break the site.

Site editor with the home page and the extra pages on the left and a live preview of the site on the right — The pages overview: the home sections and the extra pages, each one reorderable and hideable.

The home sections in the editor, each with buttons to move it up or down, hide it or edit its text — The home sections, each one reorderable and hideable.

The home page as a stack of sections and blocks, with add-block buttons between them and the live preview beside it — A page as a stack of blocks, with a live preview beside it.

An image-with-text block open for editing, with its fields on the left and the live page on the right — Opening a block: its fields on one side and the live page on the other.

A demo page built from blocks: a title, a map, a quote, three cards and a green callout, all in the Baqreads style — A demo page built from blocks, in the Baqreads style.

The page shown in these captures is demo content created for testing; it is not a real page of the club’s site.

Act 8 of 8

What changed, and what I learned

The lessons were that constraints are a design material, that a safe place to experiment builds more confidence than any feature, and that the best roadmap came from watching how the club really used the site.

The process in motion

A short recap of the whole process, narrated with on-screen text in Spanish, like the product. It runs 3:29 and needs no audio.

The process in 3 minutes and 29 seconds, in Spanish, with on-screen text and no sound.

What changed

The club’s readings, reviews and contact now live in one place instead of four.
The owner can publish changes on her own, with a preview and an undo.
The site runs on a handful of managed services without a build step.

What I learned

Constraints are a design material. Choosing no framework, invitation-only sign-up and a fixed set of blocks made the product simpler, cheaper to keep alive and more consistent than a flexible one would have been.
Give people a safe place to experiment. Preview, publish and history together did more for the owner’s confidence than any feature, because her fear was breaking something rather than not having enough options.
Let real needs set the roadmap. Reviews and the page builder were not in the first brief, and both came from watching how the club actually used the site.

Design, UX, UI and front-end by Hernando Saieh, built with the help of Claude Code.

End of the story

Next scene

That was Baqreads. Joynup is up next, or head back to the full list of work.