Vallor - Development Overview

Vallor is an AI-powered contract management platform. Customers upload thousands of executed contracts; the system extracts structured fields, lets users redline new agreements against playbooks, and powers a chat / analytics layer for legal and revenue teams. The codebase is a large TypeScript monorepo with strict guardrails (no any types or typecasts, all database writes go through resource access checks, Zod at every boundary).

I joined as a Founding Full Stack Engineer when the product was still consolidating its second major surface (Redline) and stayed through the launch of the analytics product (reports + ROI dashboard). Over the 17 months that I was a part of the team, I owned features end-to-end, and was one of the primary drivers of the two biggest customer-facing surfaces shipped in that period: the Advanced Contract Table (TableCN) and the Reports / Analytics product.

TLDR;

Features I Owned

1. Reports Page & Analytics Product

The reports page was the company's bet on turning extracted contract data into something the customer's revenue and legal ops teams could actually use. I shipped it from a v0 prototype to a production analytics product that customers now run daily.

Scope I owned:

• v0 → production migration of the reports page: converted a Vercel v0 UI prototype into a typed, server-rendered, access-controlled feature.
• Saved views with custom filters: users can name, favorite, share, and re-open any combination of filters/columns as a "view."
• AI-powered chart generation: a natural-language → chart pipeline. The agent picks chart type, axes, aggregation, and color palette from a prompt and renders directly into the dashboard.
• AI-driven filter application: extended the chart generator to also infer and apply data filters from the prompt.
• Chart-level filters: every chart can carry its own filter group on top of the view-level filters.
• View-level filters for analytics views: composable filter inheritance between view, dashboard, and chart scopes.
• Org-wide and per-member view sharing: sharing model with proper access control.
• Chart export (PNG individual + bulk): client-side rendering pipeline that serializes Recharts SVG to PNG and zips them for bulk export.
• Two-sheet Excel export: Data export for the reports page. "Primary" sheet for the customer-configured key columns and "All Fields" sheet for the full table
• Reports performance pass: stripped unused fields from the contract selection used for charts, dropping query payload size by an order of magnitude.
  

Impact
I took the analytics experience from an internal prototype to a customer-facing roadmap feature, building saved and shareable in-app views that replaced a manual Excel/Sheets workflow for power users. I also developed AI-powered chart generation into a polished product capability that became a key part of customer demos and marketing.

2. Advanced Contract Table (TableCN)

The contract library table is the most-used screen in the entire product. When I started on it, it was a table with hardcoded columns and basic equality filters. By the time I handed it off, it was a fully dynamic, virtualized, AI-augmented data surface that the reports page was later built on top of.

Scope I owned:

• Query parameter type refactor: a foundational refactor of how every list-table page encoded sort, filter, and pagination state into URL params. This was the unlock for everything that followed.
• Nested fields and advanced filtering: filter on contract.parties[*].name-style JSON paths with proper SQL generation and type-safe filter conditions.
• Sortable nested fields.
• Advanced filter dropdown search input.
• Show/Hide dynamic columns with persistence.
• Sticky name column, "See all" expanders, sorted dropdowns, scrollbar, tab reordering: a long tail of UX polish.
• Natural-language → filters: the "Query to AI Filters" feature: type a sentence, get a filter group applied.
• Excel export for dynamic columns: fixed long-standing bug where dynamic fields wouldn't export.
• Array field filtering: filter on array-typed extracted fields.
• Filter responsiveness performance pass: reduced re-renders and debounced derived state.

Impact

I built the advanced table as a reusable foundation for both the contract library and reports page, centralizing URL state, filter SQL generation, and column visibility so future features could build on the same infrastructure instead of reimplementing it. I also added natural-language filtering, reducing multi-step search workflows to a single sentence.

3. AI Chat & Agent Platform

I worked across the chat surface continuously, from early extraction-chat integration through the modern agent platform with tool use.

Scope I owned:

• Chat history → extraction agent: the first version that let the extraction model reference prior conversation context.
• Chat artifacts: the artifact rendering system (citations, generated docs, charts in chat).
• AI Elements adoption on the chat interface: replaced a hand-rolled rendering layer with the AI Elements SDK.
• Code Interpreter: added a sandboxed code execution tool that ships container files back to the chat as artifacts.
• Web Search integration.
• Audio transcription in chat.
• AI tool definition optimization: restructured tool schemas, inputs, and outputs across the agent layer, which measurably improved tool-call success rate.
• Generic updateDynamicFields tool: one agent tool that can write to any dynamic field on any entity instead of N entity-specific tools.
• Organization/user context injection into agent system prompts.
• A long tail of chat reliability fixes: model switcher refresh, race conditions on send, long-prompt errors, navigation error handling, abort signals on data queries, infinite-loop fixes.

Impact:

I helped expand Chat from a single-purpose extraction Q&A experience into a multi-tool agent surface with code execution, web search, audio input, and dynamic field updates. I also improved agent reliability by optimizing tool-calling behavior and prompt instructions based on industry standards as a means to reduce token usage, reduce malformed tool calls, and make interactions more dependable for users.

4. Redline Feature

Redline is Vallor's compare-two-documents product (e.g. "redline this counterparty's MSA against our playbook"). I was on the team that shipped the original version and then came back a year later to do follow-up improvements.

Scope I owned

• Redline base UI: Responsible for implementing the original vision, particularly the flow including a view for previous redline projects and the flow from document upload to document analysis.
• Single upload and Dual upload: flows for either drafting a new redline document or comparing and analysing two versions of the same document, respectively.
• Redline PDF viewer.
• WebSocket connection layer: real-time progress for the analysis pipeline.
• Project prompt, progress indicator, access restriction, project delete
• Redline Review refactor: major cleanup of the review surface after launch.
• Perspective toggle on re-analyze dialog: Adding the potential to draft a redline from a buyer or seller perspective, rendering the most efficient output for each point of view
• External email for redline downloads with Export dropdown: productized the share/export flow in the redline pipeline.
  

Impact:
Along with my team, I helped ship Redline as a feature customers could use without engineering hand-holding, then came back to polish the rough edges based on real usage.

5. Custom Fields for Different Entities

I generalized Vallor's dynamic-field system. Originally, dynamic (customer-configured) fields existed only on contracts. I extended the json schema, the entity registry, the form components, the agent tools, and the access control to work across multiple entity types.

Impact:

Through the changes above, I unlocked the possibility for custom fields on divisions, companies, redline projects, and the dashboard analytics, all from a single shared codepath instead of duplicating the contract field system per entity. The refactor also allowed for this behavior to be easily extended to other entities across the platform.

6. ROI Dashboard

Upon request from one of our customers, I built a time-savings dashboard that quantified how much manual review time the platform was saving each customer per month. This required joining state-machine execution data with extraction timings, plus a careful definition of "AI seconds" that excluded reprocessing artifacts.

Impact:

This dashboard gave customer success and sales a concrete, in-product number to point at during renewals, through charts for easy visual analysis of time saved along with the number of hours saved across each step of the workflow, from contract analysis, to tool use, to redline drafting, all compared against the average amount of time it would take a human on the customer's team to do the equivalent job.

7. Excel Export Pipeline

Reports and the contract library both needed to export large workbooks. I rebuilt the pipeline twice:

• First pass: S3-streamed export for memory safety on large exports.
• Second pass: Converted Excel export to a background Trigger.dev job so the user's tab didn't have to stay open while the action was in progress. Tied into the existing email-when-done flow.

8. oRPC Migration

I migrated server actions over to the oRPC API layer. This was a cross-cutting refactor across the web package; changes touched basically every mutation in the app. Set the stage for typed errors at the boundary and a more consistent error-handling pattern.

Cross-cutting Wins (the part nobody asked for but everyone benefits from)

These are the things that don't appear on a roadmap but compound across every feature shipped after them.

• Query parameter type refactor: the foundation that made the reports page possible.
• Performance work: memoized chat components, extracted-data page performance, advanced filter responsiveness, PDF viewer scroll performance via prefix sums, batched export queries to dodge statement_timeout errors.
• Security / robustness: sanitized S3 keys + presigned URL fallback, escaped user values in jsonpath wildcard filters, escaped POSIX regex chars, base64-encoded chat command content to bypass WAF false positives.
• CI: added a React Best Practices review workflow so newly written components get checked against the team's React/Next.js performance guidelines.

Skills Demonstrated

Ultimately, working with the incredible team at Vallor allowed me to build myself in many different areas as a Software Engineer. Due to the small size of the engineering team (~5 people, myself included, by the time I left), I had the responsibility of owning features end-to-end across database schema → Kysely query → oRPC procedure → AWS Lambda handler → React Server Component → client mutation hook, all under a strict typing/access control/Zod regime.

As my first full-time job in this new AI space, I also gained experience building and working alongside AI agents. I had the opportunity to build tools and prompts for an in-product agent platform (LangGraph + Anthropic + custom tool runtime) and AI-driven table and chart generation/filtering. For much of the technology we developed at Vallor for the Procurement sector, we were ahead of the curve in the AI features we were building.

Along with bug bashing (I was regularly referred to as the QA guy) and tackling performance improvements on both the frontend and backend, I believe a major skill that I got to hone further was product judgement. Understanding and designing for the people actually using the data, not the engineers reading the schemas; little things like sticky columns to give the user some direction as they scroll through tables, locale-formatted number and date inputs, toast feedback wherever mutations could silently succeed (leaving the user unaware of the status of their changes). Even spending hours going through PostHog user sessions to see the little ways in which new users used the platform offered insight into and made us question design decisions that seemed like obvious choices from a developer perspective. Just because something works for you does not mean that it works for everybody; understanding this is key in having good product design.