Back to all projects

todrawn.com

Language(s): Java, TypeScript
Published: Updated:
todrawn.com landing page for Scribe, showing the hand-drawn video workflow and controls for trying Scribe or opening a board.

Summary

todrawn.com is a full-stack visual creation product built around Scribe, which turns text, code and freehand sketches into stroke-by-stroke videos in the browser. Collaborative whiteboards are the supporting workspace for drawing, diagramming, images and shared refinement. I built the product end to end and this case study focuses on the board mode: a Java 21 and Spring Boot API, a Next.js, React and TypeScript canvas client, PostgreSQL for durable data, Redis for short-lived coordination, WebSockets for live updates and Stripe for billing. The product is deployed at todrawn.com. Its free tier is enforced transactionally with limits of three owned boards, five images per board, four people per board and two Scribe exports per UTC day. The available evidence describes the architecture and product limits, but does not include traffic, latency or revenue results.

Verified facts

  • 421 commits are recorded for the private whiteboard repository.
  • The product combines Scribe with collaborative whiteboards at todrawn.com.
  • The board stack includes Java 21, Spring Boot, Next.js, React, PostgreSQL, Redis, WebSockets and Stripe.
  • FREE limits are enforced transactionally: 3 owned boards, 5 images, 4 people and 2 Scribe exports per UTC day.

Problem

The collaborative board mode has to keep drawing and board state in sync for connected clients while accounts, boards and subscriptions remain part of the same product. The architecture addresses those concerns in one deployed application.

Responsibilities

I built the project end to end. The scope covers the Spring Boot API and Spring Security, the Next.js and Konva canvas experience, real-time updates, PostgreSQL and Redis data handling, Stripe billing, and the containerised delivery path.

Decisions and trade-offs

  • WebSockets: board updates move between connected clients in real time.
  • PostgreSQL and Redis: PostgreSQL stores boards and account data, while Redis supports fast, short-lived state.
  • Konva: the canvas renderer is kept in the frontend where drawing interactions happen.
  • Delivery: Docker, GitHub Actions and Google Cloud Run provide the build and hosting path; Stripe is integrated in the Spring Boot backend.

The public project description does not publish latency, traffic or scale figures, so this case study keeps the result qualitative.

Technical architecture

  • Backend: Java 21, Spring Boot and Spring Security handle the API, authentication and authorisation.
  • Frontend: Next.js, React and TypeScript provide the UI, with Tailwind CSS and Konva for the canvas.
  • Data: PostgreSQL is the system of record for boards, accounts and related data; Redis is used for short-lived state.
[ Next.js / React / Konva ] <--WebSocket--> [ Spring Boot API ]
                                                    ↓
                                    [ PostgreSQL ]     [ Redis ]

Result

The result is a live todrawn.com product with Scribe for hand-drawn video creation and collaborative boards, with Stripe subscriptions, a containerised application, automated GitHub Actions delivery and a backend hosted on Google Cloud Run.

Lessons learned

Building the product end to end connected frontend interactions, real-time transport, persistence, authentication, billing and deployment in one system. It also made the boundary between durable data in PostgreSQL and short-lived coordination in Redis explicit. The public material documents the architecture and production URL; it does not include a performance or incident history.

How this was verified: Open the live product ↗

Technologies Used

Java 21Spring BootNext.jsReactTypeScriptPostgreSQLRedisWebSocketsStripeDockerGoogle Cloud Run