Manasa B R

Two AI-built prototypes, one real decision: hand-rolled table or Smart Grid?

Procore Document Management — Documents table refresh

The question
Refresh the Documents table by hand-rolling it, or adopt Procore's real Smart Grid component?
My role
Built both prototypes to make the trade-offs concrete before engineering had to choose
Tools used
AI-assisted prototyping against two different component foundations
Outcome
A side-by-side comparison engineering could react to, instead of a debate about hypotheticals

Background

Overview

A refresh of PDM's Documents table could go two ways: keep hand-rolling the table the way it's built today, or adopt Procore's Smart Grid — the AG-Grid-based component the platform is standardizing on. Each direction has a real cost. Hand-rolling means owning every interaction — sorting, resizing, pinned columns, row density, column configuration — indefinitely. Adopting Smart Grid means inheriting a heavier dependency and a less familiar API in exchange for a maintained, consistent foundation.

Instead of debating this in the abstract, I built both — the same visual target, twice, on two different foundations.

What I built

The same table, twice

  1. Hand-rolled iteration

    A from-scratch table matching the target design pixel-for-pixel — custom cells, a configure panel for row height and column visibility, pinned name and actions columns.

  2. Smart Grid iteration

    The same visual target, rebuilt on Procore's real Smart Grid client — AG-Grid under the hood, with custom cell renderers only where the design needed something the grid didn't provide out of the box.

  3. Side-by-side comparison

    Both prototypes live in the same sandbox app, so engineering could click between them and feel the difference in interaction quality, not just read about it.

What the comparison surfaced

Trade-offs that stayed hidden until both existed

  • 01

    Built-in versus custom

    Smart Grid gave sorting, filtering, column tool panels, and persistence for free — the hand-rolled version would have to build and maintain all of it going forward.

  • 02

    Pixel control versus platform consistency

    The hand-rolled table matched the target design exactly, with zero compromise. Smart Grid meant working within AG-Grid's column and cell APIs — occasionally trading a pixel-perfect detail for consistency with every other Smart Grid table in the product.

  • 03

    Integration cost, up front and visible

    Wiring Smart Grid's column definitions, selection model, and toolbar slots took real, visible effort inside the prototype — exactly the cost engineering needed to see before committing to it for real.

What the prototypes actually were

At a glance

2 parallel prototypes

One hand-rolled, one on Smart Grid — same visual target, same mock data, so the comparison stayed apples to apples.

6 columns modeled

Name plus five configurable columns — Description, Version, Created On, Created By, and Revision # — the real column set from the target design.

0 production lines written first

Both prototypes existed before an engineering estimate was requested, so the evaluation informed the estimate rather than following it.

Why build two to get one answer

AI-assisted prototyping made building the second version cheap enough that de-risking became the default, not a luxury. The commitment decision is still ahead — this work exists so it gets made with two working prototypes in hand instead of two slide decks arguing past each other.

Next in AI Lab

Design Orchestrator — a shared pipeline for turning Figma into working prototypes

Org-level AI tooling — Procore design system, composed once