Noelia Viscelli
The site of a coach who sells e-books and a four-month program. She edits her own pages, and her students take the course on a platform of their own.
Noelia sells e-books, booked calls and a program called Método SER with three plans. She changes prices, offers and copy often, and every change went through a developer. Her students also needed a place to watch the lessons, hand in work and book their one-on-one sessions.
Three decisions that shaped it.
- 01
Each section is a row with a draft next to it
Why. Every section instance is a JSON row in Postgres with its published content and its draft. A zod schema from the catalog checks each save. The page merges what is saved over the defaults in code, so a field added later shows its default without migrating rows. Publishing first copies the old content into a revision, and a revert does the same, so it can be undone too.
Trade-off. Postgres sees the content as text, so nothing inside it can be queried. Publishing updates the rows one by one, outside a transaction, and the section order has no history of its own.
- 02
The preview is the real page
Why. The editor shows the public page in an iframe with ?preview=1. A signed cookie that lasts 30 minutes switches that page to the drafts. There is no second renderer to keep in sync, and the desktop and phone toggle shows exactly what visitors will get.
Trade-off. Reading the cookie makes both pages render on every request. The live site answers with cache-control: no-store, and every visit queries Postgres.
- 03
Hotmart sells, Calendly books, the platform teaches
Why. The e-books link to Hotmart checkouts, and calls are booked in an embedded Calendly. Hotmart already handles payment, receipts and delivery, so I spent the time on the platform: lessons, progress, comments, ratings, submissions and forms.
Trade-off. Sales never reach the admin. After a payment, the student account and the enrollment are created by hand, and the limits of each plan live in code.
Noelia Viscelli
The site of a coach who sells e-books and a four-month program. She edits her own pages, and her students take the course on a platform of their own.
- Role
- Full build
- Stack
- Next.js 16, React 19, TypeScript, Prisma, Postgres, Cloudinary
Noelia sells e-books, booked calls and a program called Método SER with three plans. She changes prices, offers and copy often, and every change went through a developer. Her students also needed a place to watch the lessons, hand in work and book their one-on-one sessions.
Three decisions that shaped it.
Each section is a row with a draft next to it
Why. Every section instance is a JSON row in Postgres with its published content and its draft. A zod schema from the catalog checks each save. The page merges what is saved over the defaults in code, so a field added later shows its default without migrating rows. Publishing first copies the old content into a revision, and a revert does the same, so it can be undone too.
Trade-off. Postgres sees the content as text, so nothing inside it can be queried. Publishing updates the rows one by one, outside a transaction, and the section order has no history of its own.
The preview is the real page
Why. The editor shows the public page in an iframe with ?preview=1. A signed cookie that lasts 30 minutes switches that page to the drafts. There is no second renderer to keep in sync, and the desktop and phone toggle shows exactly what visitors will get.
Trade-off. Reading the cookie makes both pages render on every request. The live site answers with cache-control: no-store, and every visit queries Postgres.
Hotmart sells, Calendly books, the platform teaches
Why. The e-books link to Hotmart checkouts, and calls are booked in an embedded Calendly. Hotmart already handles payment, receipts and delivery, so I spent the time on the platform: lessons, progress, comments, ratings, submissions and forms.
Trade-off. Sales never reach the admin. After a payment, the student account and the enrollment are created by hand, and the limits of each plan live in code.