Skip to content
← Case Studies

What the platform looks like five months in

Construction technologyPlatform build2026–present

The best way to show what our platform is capable of is to walk through the most demanding product that we've built with it so far.

This product reads construction floor plans and produces a complete lumber takeoff: studs, plates, headers, king and jack studs, dimensions, and the rest. It includes live, localized price estimation for lumber and other building materials. The product is a live, commercial product with billing, trials, and paying-customer infrastructure. It started as a fork of the same platform we deploy for clients. Our client owns their codebase, and can do with it whatever they please.

FieldValue
StartedMarch 2026, from a platform fork
To productionFive months, one small team
StatusA live commercial product, actively developed
DeploymentFull CI/CD pipelines to automate testing and deployment of releases

None of the five month implementation time was spent on rebuilding the basics. Authentication, multi-tenancy, agent memory, skill infrastructure, deployment pipeline, and more were already built into the platform from day zero. The team spent its time implementing the product and business logic instead.

The hard part was the domain

Nearly all of the implementation effort went into the handling of domain-specific construction takeoffs.

Reading plans of all types

Plans arrive in fundamentally different forms, and treating them the same produces confident nonsense. The system detects whether a PDF is a true vector export from AutoCAD, Revit, another CAD program, a scanned raster page, or just a structure described in plain English, and routes accordingly. CAD drawings get handled one way, and less-sophisticated plans get handled another.

Underneath that sit the pieces a person does without noticing: establishing drawing scale, reading the legend, interpreting drawing style, and finding openings such as doors and windows. Each feature is its own module, and each is testable on its own. These modules come together to create a full takeoff, and that interweaving of features is testable, too.

Confirming scope before measuring anything

Before any takeoff is calculated, the system draws what it sees on the plan itself. This plan annotation allows the user to fully understand what the agent intends to estimate, and the colors pop off of the page so that the user doesn't miss a thing. A takeoff of the wrong walls is worse than no takeoff, because it looks finished. Plan annotation with a human in the loop keeps that from happening.

This is the same principle as the reconciliation work in our financial pipeline: where being wrong is expensive, the system shows its work and we ensure that human judgment takes the lead.

Rules that must not be improvised

Framing requirements are not stylistic. Climate zone 5A and above defaults to 2x6 exterior walls. A seismic flag adds hold-downs and anchors. A hurricane flag adds ties and straps. These are applied deterministically, not generated by a language model, because a model that is right most of the time is not acceptable where a building inspector is the reviewer.

Where the model is used
  • The model interprets drawings, handles conversation, and uses deterministic tools to get consistent and accurate data
  • Geometry, quantities, and code-driven framing rules are computed in code and tested
  • Anything a building inspector would check is deterministic, and reproducible from the same inputs

Inherited from the platform

Everything below came with the fork in March 2026, and that is what made the timeline possible:

  • Multi-tenant data isolation and JWT authentication
  • LangGraph agent orchestration, with long-term semantic memory on pgvector
  • The skills system, which now carries nine domain skills including takeoffs, bids, pricing, and project management
  • Sandboxed code execution for the numerical work
  • MCP tool servers for extraction and search

The implementation since March runs in three avenues.

  1. The Next.js App Router front end with streaming responses was built here. The framework has since been folded back into the platform, so a client starting today inherits it too.
  2. Stripe billing with trials and discount codes for a B2B-facing product.
  3. Product & Business Logic: Construction-centric agent skills and workflows, architectural plan-reading modules, multi-language estimate export features in English, Spanish, French, and Brazilian Portuguese, a client bid builder with public share links, and an in-app help center.

This runs in production

The infrastructure is defined as code across twelve AWS CDK stacks: network, DNS and certificates, secrets, budget, data with Aurora and Valkey and EFS, and compute running ECS Fargate services for API, worker, and scheduler behind a load balancer with queue-based autoscaling. There is also a dedicated stack for the agent's code-execution sandbox, which is far cheaper per-run than most out-of-the-box code-execution sandbox services.

Releases move through development, integration, and production branches. Production deploys are gated on a full test run that cannot be bypassed, and they authenticate through GitHub OIDC rather than long-lived AWS keys.

For your project
  • The platform carries a live commercial product in production, not a demo adapted for a pitch
  • When something in the platform layer is fragile, it shows up under production traffic before your engagement starts
  • The deployment path we hand you is the one this was built on

If you are trying to get an AI system from prototype to something the business can rely on, a 30-minute call is the fastest way to find out how much of this applies to you.