The client is a US furniture company. Customers order on its website, its warehouse prepares each order, and its in-house crews deliver and install the products in customers’ homes. As part of its AI transformation, the client is moving the tools behind this work off vendor platforms and into its operations system, the software that runs its orders, warehouse and asset tracking.
01 The Challenge
A vendor platform keeps the crews’ work outside the client’s system
Once the warehouse has prepared an order, dispatchers plan its delivery or installation into a crew’s day, and crews take the work on their phones, closing each job with a checklist. Orders, warehouse scanning and asset tracking already run in the client’s operations system, which Provectus maintains day to day, and the warehouse team works in a staff mobile app Provectus built.
The crews’ work is the exception. Since 2022 it has run on a third-party field-operations platform with no source-code access, connected to the client’s system through an integration. Every delivery and installation exists in both systems, and the two do not always agree: between 2022 and 2026, dozens of tickets named the platform, about half of them bugs, with tasks duplicated or missing and completed checklists that never reached the operations dashboard. The subscription costs an estimated tens of thousands of dollars a year, based on the vendor’s public pricing, for dozens of seats, many of them unused, and past checklists are stored only on the vendor’s servers.
The client had replaced one of its vendor platforms before. In 2025 Provectus moved its asset tracking into the client’s system, ending in an overnight cutover of more than 70,000 assets. With the asset data in its system, the client has since had inventory forecasting and AI-assisted checklist assignment, two features the vendor tool did not offer.
The client wanted field operations to follow, on one condition: dispatchers and crews, fluent in the old tools, should not have to relearn their work.
02 The Approach
Claude helped settle the requirements before any code was written
The client’s requirements document covered part of the application in detail and other parts barely at all, and it assumed the reader knew the vendor platform. Provectus’ designer started with Claude. From the client’s design system, its current dashboard designs and the requirements document, Claude built an interactive prototype of the core screens, which showed where the requirements leaned on the vendor platform without saying so, before development started.
The team then went through the client’s existing process: how dispatchers plan the day, assign crews and track the work, and which templates, forms and statuses the client actually uses. With that, the designer worked out the final screens with the client’s team. More than 80 decisions are recorded with their reasons. Dispatchers keep the map-plus-list dashboard they know, and crews get the day’s jobs, each job’s details, a map and the checklist forms they used before. The agreed design and its decision log became the input for the build.
03 The Build
AI agents across the delivery, with developers making the decisions
Once the design was agreed on, the work moved to Claude Code. The agents built by the Provectus team run through AWOS, Provectus’ open-source, spec-driven framework, and a set of Claude Code skills that carry the team’s delivery method: how a specification is written, how acceptance criteria are checked, and how documentation keeps up with the code. Developers make the product and technical decisions and approve every change.
The team has the same shape as the one that replaced the asset-tracking platform: three developers, a designer and a team lead, with the same designer and team lead on both projects. On both projects, the team lead also covers delivery management, requirements and QA. On field operations, Claude and its agents also support work across the delivery:
- Planning. Design and requirements work took about four months. From the agreed design, the agents then produced the full plan in one working day: 10 stories with subtasks by layer and the order to build them in.
- Specifications. Claude Code was used to create the documentation hub from the agreed screens, and 36 specifications written from it carry about 1,270 acceptance criteria. When design review changes a requirement during the build, the agents update the affected documents.
- Code. Agents write each specification’s code under a developer’s direction, reusing the client’s existing platform services for most of the module.
- Checks. Claude Code skills verify each specification against its acceptance criteria on the running system, and about 95% of merge requests went through an AI review before a developer merged them.
- Documentation. The agents keep the documentation current with the code, and a developer approves each change.
- Project management. Claude skills produce the sprint plans, release reports and call summaries.
On mobile, field operations becomes the third section of the staff app, so crews will use one app in the warehouse and in the customer’s home.
Every session runs under Provectus’ Claude Team plan, which follows Anthropic’s commercial terms (sessions are not used to train models). The module is built and tested on sample data only, and project rules keep production credentials out of the AI’s reach.
04 The Results
A plan in one day, half the stories in seven weeks
About seven weeks after the first code reached the test environment, 5 of 10 stories are complete, including the map-plus-list dashboard, the calendar, job templates and the crew’s mobile section. Synchronization with the operations dashboard and data migration are next.
5 of 10
Stories complete
About seven weeks after the first code reached the test environment
A five-person team got there with the agents handling planning, specifications, checks and documentation.
The finished stories come with evidence as well as code: about 90% of the acceptance criteria are checked off so far, each with what was measured, and almost every specification ships with automated tests.
The client owns the module’s code and documentation. Because the agents keep the documentation current with the code, any team could take the module over.
Once the module is live, the client expects:
- one record of every job, crew assignment and checklist, with no sync between two systems to break
- past checklists kept in the client’s storage, and the paid vendor seats gone
- templates and forms edited by the client’s team, without development work
05 What’s Next
From one system to AI on the crews’ work
The new module will run alongside the vendor platform, environment by environment, until a go/no-go in production. After that, the vendor integration will be removed and the subscription canceled.
The client’s AI transformation so far, and its next step:
- Asset tracking. In-house since 2025, it runs AI features on its data.
- Field operations. Built with AI agents in Claude Code, it joins asset tracking in one system.
- Next. Provectus is building AI room visualizations from the assets assigned to each order, and the client plans to build AI-assisted crew suggestions for each job, and search across jobs and checklists, with Provectus.
If a vendor platform is in the way of your AI plans, Provectus can plan and build its replacement with you the same way: design first, then spec-driven development with AI agents in AWOS and Claude Code. The Agentic SDLC with Claude Code program brings this way of working to your engineering team.