Technology

Next.js, PostgreSQL, Drizzle ORM, tRPC, ShadCn & Tailwind

Product-led architecture

I read "Product-Led Growth" and wanted to build a software business where the demo is the product, with zero friction.

Validating the idea

I used Claude Code research mode to analyse thousands of articles and forum threads.

Community librarians are caught between the chaos of Excel ("accidentally swipe over a range, and you've suddenly moved a group of cells") and overly complex tools that require them to use the Dewey Decimal system when it's not needed.

I found that no competitor offers a product-led demo; you can't try it before signing up. I designed a solution with just three tables (catalogue, patrons, and loans). Dead simple.

With the scope defined, the more complex challenge is: how do you let people experience it without any friction?

Demo architecture

The challenge was to provide every visitor with their own functional library instantly, without incurring provisioning overhead.

My solution is pristine/pooled library swapping.

• Pre-seed demo libraries: one marked `isPristine`, five marked `isPooled`
• Anonymous users view the pristine library (shared, read-only)
• On first mutation, in a single transaction:

• • Apply their edit to the pristine library
  • Mark it as theirs (isPristine → false)
  • Promote a pooled library to pristine
  • Fire-and-forget pool replenishment

• Generate demo-access-token, save to localStorage
• They continue editing their claimed library

Result

Users can edit real data before signing up, with zero friction, persistent data, and no provisioning overhead. The isFirstMutation check adds just 20ms.

The demo content (projector, coffee urn, folding chairs) shows usage beyond books.

Planning & execution

I spent two days planning on paper before writing code. I sketched every flow and eliminated unnecessary features (multi-library, patron accounts, fine management).

I used drawers for all actions, as consistency is the basis of great UX.

I changed my mind on paper dozens of times, which is much faster than refactoring code. I shipped on day 12.

What I learned

Technical

I learned to be suspicious of any database denormalisation, however minor.

I tried it for item copies and ended up with logically impossible loan states. I found that normalised handling added slight complexity but ensured data integrity, which is essential for any library system.

Market

I learned that validation ≠ access. I validated the need, but reaching scattered non-technical users is harder than I anticipated. My next project will target underserved markets I can feasibly reach.

Planning

I found that planning enabled me to achieve the 12-day timeline. Now I'm systematising it further: component lists, isolated UI sketches, and upfront architectural thinking.

Now the real test is getting this in front of the community librarians who need it.