Case Study · Application

Praodic

An architectural project collaboration platform for a Tirukoilur-based design and build firm — one product that runs the public brand surface, the internal project workflow, and the external client and contractor review loop.

Open demo →Private project

Status: LIVE
Launch: In active use
Role: Solo · Product, design, and engineering
User: Architecture and construction firm
Stack: Next.jsTypeScriptPostgresPDF Review

Overview

Praodic is an architectural project collaboration platform built for a single design and build firm based in Tirukoilur, Tamil Nadu. The firm designs and delivers homes end-to-end under one team, and Praodic is the product surface that runs that work — from the first conversation with a prospective client, through drawing review with the homeowner and contractor, to project milestones and payments.

The platform runs as two surfaces in one product. A public landing page turns prospective homeowners into qualified leads. An authenticated review tool is the firm's day-to-day workspace — projects, drawings, revisions, comments, mentions, approvals, milestones, and payments, with external clients and contractors brought into the same review flow through tokenized, time-limited links that do not require an account.

One platform that takes a Tirukoilur architecture firm from the first lead to the final homeowner sign-off — public brand surface, internal project workspace, and external client and contractor review loop, all in one product.

Status: In active use
Sector: Architecture and construction
Region: Tirukoilur, Tamil Nadu
Role: Solo · Product + Engineering
Surfaces: Public · Internal · External review
Stakeholders: Owner · Admin · Reviewer · Client · Contractor

Problem

Architecture firms run on review. Every drawing goes through several rounds: the architect revises, the internal team checks, the homeowner weighs in, the contractor flags constructability, and someone has to remember which version everyone actually agreed to. Most firms run that loop on email, PDF attachments, and chat threads — a workflow that loses context the moment a file is forwarded.

Three problems sit underneath. First, there is no single record of what was reviewed and what was approved — the conversation lives in inboxes, and the approval intent is implied rather than captured. Second, drawing revisions have no native identity: a project accumulates dozens of PDFs named 'plan-v3-FINAL-rev2.pdf' and nobody is sure which one is current. Third, the same firm is also the sales team — prospective homeowners arrive through WhatsApp, Instagram, and word-of-mouth, and the firm has no shared place to track who has been contacted, who is meeting, and who has converted.

Praodic exists to give a small design-build firm the same operational backbone a large firm would have — a single product that holds the lead, the project, the drawing, the comment, the decision, and the milestone, end to end.

Users

Praodic serves three first-party audiences with different levels of access — internal staff, external reviewers, and prospective clients — and stitches their work onto the same project record.

The Firm (Owner, Admin, Reviewer)

Runs the business

A small architecture and construction firm in Tirukoilur. The owner runs the business; admins run projects end to end; reviewers comment and approve within their assigned scope. All three live in the authenticated review tool every day.

Pain points

Drawing review scattered across email, WhatsApp, and PDF attachments.
No single record of which revision was approved and by whom.
Lead status tracked informally, with status lost between handoffs.

Goals

One workspace for projects, drawings, decisions, and milestones.
A clear, auditable record of which revision the client approved.
A shared lead pipeline the whole firm can see and update.

The Homeowner (External Client)

Reviews and approves

A prospective or current homeowner who needs to see drawings, leave comments, and approve revisions. Has no account and no app to install — receives a link, opens it, reviews, decides.

Pain points

Email threads with PDFs that lose context after the second reply.
Uncertainty about whether a comment was seen, addressed, or lost.
No clear way to give a single, durable approval on a specific drawing.

Goals

Open a link and see the drawing the firm wants reviewed.
Leave pin-comments directly on the drawing, with replies.
Approve or request changes with a decision that the firm records.

The Contractor (External Reviewer)

Comments on constructability

A contractor brought into the project for a specific scope. Has no account; reviews drawings, leaves comments, but does not decide approval — that stays with the homeowner.

Pain points

Receiving drawings by email with no way to comment against the drawing itself.
No feedback loop when a comment is addressed in a later revision.

Goals

Open a link, mark up the drawing, and have those comments reach the firm.
Stay out of the approval loop — that belongs to the homeowner.

The Prospective Client (Lead)

Begins the journey

Someone who lands on the public site, watches the brand story, and submits a lead form. Has no account, no login — just a first conversation captured into the firm's pipeline.

Pain points

Generic contact forms that go nowhere.
No signal back about whether the firm has even seen the inquiry.

Goals

Reach the firm through a channel that feels personal, not corporate.
Be remembered on the second conversation, not asked the same questions twice.

Solution

Praodic is a single product that runs the firm's full operating loop. The public landing page is the front door: it tells the firm's story, shows the work, and turns a curious visitor into a lead. The authenticated review tool is the back office: it holds every active project, every drawing revision, every comment, every approval, every milestone, and every payment.

The bridge between the two surfaces is the review link. When a drawing is ready for the homeowner or contractor, the firm generates a tokenized, time-limited link. The recipient opens it without creating an account, lands in a focused review surface, sees the same drawing, and can comment, reply, and (for the homeowner) decide approval. The decision is captured against the exact revision, with the comment thread frozen as part of the record.

Underneath, the product is built around a small set of deliberate primitives: a project container, a drawing with an append-only revision history, a comment thread anchored to a point on a page, a session that opens and closes around a review, an approval that freezes a moment in time, and a milestone and payment ledger that lives next to the drawing. Each primitive is a small, named thing the firm can talk about, and each is what the product's screens and workflows are made of.

One record per project. Drawings, comments, decisions, milestones, and payments all hang off the same project, so nothing is split across tools.
External review without accounts. Clients and contractors join the review through a link, not a signup — the friction to participate is the friction to open an email.
Decisions are durable. When a homeowner approves a revision, the decision is captured with the exact drawing bytes and comment thread in view, and it cannot be quietly overwritten.
The brand surface feeds the operating tool. A lead from the public site lands in the same pipeline the firm uses every day, and the work that follows is visible from the first call.

Key Features

The product capabilities that make Praodic a collaboration platform rather than a document tool. Each one is built to keep a stakeholder's work in the same record as everyone else's.

Public lead surface

A landing page that tells the firm's story, shows the work, and routes a prospective homeowner into a lead pipeline. The first conversation happens on the firm's terms, with the inquiry captured into the system before the call.

Lead pipeline with shared visibility

Inquiries move through a clear set of stages — new, reached out, meeting scheduled, proposal sent, converted or lost — with internal notes and ownership. The whole firm can see where every lead stands.

Project workspace

Each active project carries its own record: drawings, milestones, payments, and a timeline of every event. The project page is the single place the firm goes to see the work.

Drawing with revision history

A drawing is more than one PDF. Praodic treats every revision as a named, sequenced object on the drawing — so 'which one is current?' has a definite answer, and the older revisions are still reachable.

Pin-comments on the drawing

Reviewers drop comments at a specific point on a specific page of the PDF. Threads, replies, and resolved/reopened state are first-class. A comment stays attached to the place it was made, not to an email.

@-mentions with autocomplete

Any comment can pull another team member into the conversation with an @-mention. Mentions surface in the notification feed so nothing gets lost in a long thread.

Review sessions and approvals

A review session opens on a revision, accumulates comments, and closes with an approval decision. The decision is recorded against the exact bytes and the exact comment thread, so 'what was approved?' has a single, auditable answer.

Tokenized external review

Clients and contractors join the same review through a generated, time-limited link. No account, no app, no password. The link carries the recipient's role — client or contractor — and gates the actions they can take.

Real-time updates on the drawing

When a comment lands, a session opens, or a decision is recorded, every connected reviewer sees the change without refreshing. The drawing is a live surface during a review.

Milestones and payment tracking

Projects carry a milestone list and a payment ledger, with clear states (pending, paid, cancelled) and race-safe transitions. The firm and the client see the same project state.

Append-only audit log

Every meaningful action — a project created, a revision uploaded, an approval decided, a payment marked paid — lands in an audit log that cannot be edited after the fact. The record is the record.

Notification feed with email

In-app notifications carry the day; email notifications carry the moments a team member is away. Per-event preferences let each person tune what reaches their inbox.

Cross-entity search

A single search bar reaches projects, drawings, and comments. The firm can answer 'where did we discuss that detail?' without remembering which surface it lived on.

Role-based capabilities

Three internal roles (owner, admin, reviewer) carry a defined set of capabilities across the product. The right people see the right actions, and the permission model is owned by the product rather than ad-hoc.

Product Screens

Selected surfaces from the studio's review tool, captured against the live build of the demo.

Praodic workspace — projects list — Workspace — Project list with status filters, search, and a glanceable view of progress, location, and the next milestone per project.

Praodic project detail — Project detail — Drill-down into a single project — drawing set, filterable by review state, alongside the recent activity on that project.

Praodic drawing review — Drawing review — The drawing canvas on the left with the comment thread and approval controls on the right — real-time updates as reviewers engage.

Praodic comment thread — Comment thread — A pin-comment open in the side panel — replies, @-mentions, and resolved / reopened state carried through the thread.

Praodic approval modal — Approval modal — The decision surface — approve, request changes, or reject against the exact revision and the comment thread in view.

Praodic revision history — Revision history — Append-only version history per drawing — every upload summarised, the change list, the reviewer, and the resulting status.

Technical Architecture

Praodic is built as a single Next.js application that hosts both the public brand surface and the authenticated review tool. The public landing page and the authenticated workspace share an infrastructure, a design system, and a deployment — but the surfaces are clearly separated, with the firm-facing workspace gated behind authentication and a role check, and the public page deliberately outside it.

Behind the workspace, the product is structured around a small set of named primitives: a project, a drawing, a revision, a review session, a comment, an approval, a milestone, and a payment. Each primitive has a screen, a capability, and a record in the data layer. Server-side actions on the application drive every change, and the data layer treats a drawing's revision history as append-only — the only way to change a drawing is to add a new revision and point the drawing at it.

The real-time layer is part of the same product, not a separate service. When a comment lands or a session opens, every connected reviewer sees the change without a refresh. The review link surface is part of the same product too: the homeowner or contractor opens a tokenized link and lands in a focused review view that shares the drawing and the comments with the internal team, but with the actions gated to the recipient's role.

Component	Purpose	Technology
Public surface	Brand story, project showcase, lead capture.	Marketing pages with form-driven lead intake
Internal workspace	Projects, drawings, reviews, milestones, payments, leads.	Authenticated Next.js application
External review surface	Tokenized, role-gated review for clients and contractors.	No-account review pages reachable by signed link
Drawing and revision engine	PDF rendering, page navigation, and the revision lifecycle.	Client-side PDF rendering with append-only revisions
Comment and approval engine	Pin-comments, threads, mentions, and approval decisions.	Session-based review with frozen decision records
Real-time layer	Live updates to connected reviewers on a drawing.	Server-sent events driven by an internal event bus
Audit and notification fan-out	Append-only event log and in-app plus email notifications.	Event-driven write side, deferred email transport
Search	Cross-entity search across projects, drawings, comments.	Full-text search with a graceful fallback for short queries
Role and capability engine	Three internal roles plus two external roles, each with a defined capability set.	Server-side capability checks on every action

Data model

Project — the unit of work; carries drawings, milestones, payments, and a timeline.
Drawing — a named asset under a project; points to the current revision and the latest approved revision.
Revision — an immutable PDF revision; identified by sequence; the only thing that changes after upload is the drawing's pointer.
Review session — a window on a revision; accumulates comments and ends with a decision.
Comment — a thread anchored to a point on a page; can be replied to, resolved, and reopened.
Approval — a decision captured against the exact revision bytes and the exact comment thread in view.
Lead, milestone, payment — the surrounding record that turns a drawing into a project and a project into a business.

Authentication, storage, database, and infrastructure details are deliberately out of scope for a public case study of a live client product. The summary above is at the product boundary, not the implementation boundary.

Challenges

The engineering problems that shaped Praodic. Each one is grounded in the work the product actually does, not in aspirational risk lists.

Approvals that survive the next revision

An approval in an architecture firm has to mean something later. The next revision will arrive, the homeowner will need to see what changed, and the firm will need to know which revision the homeowner actually agreed to.

The fix is to freeze the decision at the moment it happens. The decision is recorded against the exact revision bytes that were on screen, with the comment thread in view at the time — so 'what was approved?' is answerable months later without anyone having to remember.

Review without forcing an account

A homeowner reviewing a drawing is not going to create an account on a firm's internal tool. The path of least resistance is the path that gets used, and the path of least resistance is a link.

Praodic's review link is tokenized, time-limited, and role-aware. The homeowner opens the link and lands in a focused review surface; the contractor opens a different link and lands in a surface that does not let them approve. The same drawing, the right actions for the role, and no signup in either path.

Real-time without standing up a chat service

Two reviewers looking at the same drawing need to see each other's comments without a refresh. Standing up a dedicated real-time service for a small firm is overkill, and the cost of a real-time service that goes down silently is worse than no real-time at all.

The product takes a deliberate middle path: server-sent events driven by the same event bus that records the audit log. Every meaningful action is already an event; the real-time layer is just the part of the event bus the client subscribes to.

Revisions that cannot be quietly edited

If a revision can be edited after upload, every downstream decision is suspect. The homeowner approved the bytes they saw, and 'the bytes they saw' has to be a stable answer.

The product treats a revision as append-only. Once a PDF is uploaded, it cannot be modified — only the drawing's pointer to 'the current revision' can change. The next revision is a new object; the old one stays exactly as it was.

Decisions and notifications that cannot desync

If a comment lands but the notification does not, or a payment is marked paid but the audit log does not reflect it, the firm's record is wrong in a way that is hard to spot and expensive to fix.

The product writes the audit row, the notification row, and the real-time signal inside the same transaction. The email is decoupled from the commit so a transport failure cannot roll back the business write, but the in-product record is always consistent with the action the user took.

Results

Praodic is in active use. Production metrics — homeowner count, project count, average review cycle time, conversion from lead to project — are not recorded in the product itself. The numbers below are facts about the build, not business outcomes.

3Internal rolesOwner · Admin · Reviewer

2External rolesClient · Contractor

3Product surfacesPublic · Internal · External review

14PrimitivesProject, drawing, revision, session, comment, approval…

Outcomes

One product that runs the firm's full operating loop — from the first lead to the final homeowner sign-off.
External review without accounts, through tokenized links that respect the recipient's role.
Approvals captured against the exact revision and the exact comment thread, so decisions stay meaningful across the next revision.
Real-time updates on a drawing without a separate chat service, using the same event bus that writes the audit log.

Lessons Learned

What the build taught us. Each lesson is grounded in a real decision that shaped the product, not in advice pulled from a checklist.

Product

The hardest thing about a review tool is not the document — it is the decision.
A PDF can be opened anywhere. What makes a review useful is the moment a stakeholder says yes, and 'yes' is what the product has to capture. Once the decision is the primitive, the drawing, the comments, and the revisions arrange themselves around it.
External review has to feel like part of the product, not a different product.
A homeowner who is suddenly asked to log in, set a password, and learn a new interface is a homeowner who never reviews the drawing. The tokenized review surface is the same product the firm uses, with the actions scoped to the role — not a separate portal that has to be kept in sync.

Engineering

A revision is append-only. The pointer changes; the bytes do not.
Once a drawing revision is approved, it is approved against those exact bytes. The product enforces this at the data layer, so the question 'which version did the client agree to?' is always answerable from the record.
The audit log is not a side feature — it is part of the write path.
Every meaningful action writes the audit row, the notification row, and the real-time signal in the same transaction. Skipping the audit log to ship faster would have produced a product the firm could not trust.

Process

One codebase for the public surface and the internal tool is a feature, not a compromise.
A landing page and a review tool have more in common than they look — the same design system, the same deployment, the same lead record flowing from one to the other. Building them as one product meant the firm's first conversation with a prospective client and the firm's hundredth conversation about a drawing share the same plumbing.
Capabilities, not roles, drive the permission model.
Three roles with a defined set of capabilities each is a small, explicit contract the firm can reason about. A new reviewer does not get a new role; they get a subset of the existing capabilities. The product's permission model survives the firm's growth because it is built from the small pieces the firm already names.