Client engagement
Desarmadero Operations Prototype
Gave the client a clickable sales workflow before the full build, making the operating model easier to validate.
Project overview
Desarmadero Operations Prototype overview
A short overview of the problem, solution, and result.
Starting Point
A returning client had one discovery call, paper budget sheets, WhatsApp, Excel, memory, and a 301-position yard that needed to become an operating system.What Shipped
A live role-based prototype, seeded demo, discovery transcript, PRD, functional spec, and prototype screenshots.Why It Mattered
The client could validate the operating model through a working app instead of abstract requirements.One discovery call became a PRD, spec, and clickable prototype
I turned one discovery call into a PRD, functional spec, clickable operations prototype, and live demo for an auto-dismantling yard.
A returning client wanted to go beyond a searchable parts catalog and run the auto-dismantling yard itself. Building the prototype before the full product gave the client something concrete to test and made the next scope conversation clearer.
The yard ran across paper, chat, spreadsheets, and memory
The first project for this client was a searchable parts catalog. It helped customers check stock before calling.
The second idea was bigger: counter sales, cash desk payments, dismantle orders, assignments, and finding vehicles inside a 301-position yard. The existing system lived across paper budget sheets, WhatsApp, Excel, and people remembering where cars were parked.
I modeled the yard before pricing the full build
Map how a sale becomes a dismantle order.
I began with how the yard actually runs. A counter sale can happen before staff physically pull the parts, so the prototype treats the sale as the beginning of the dismantling process.
Build before quoting the full system.
Instead of jumping straight to a quote, I built a working prototype first. A clickable app is often the fastest way to confirm whether I understood the business.
The prototype follows each role through the yard
The prototype follows the yard’s daily operation: the seller records the sale, the cash desk confirms payment, the dismantle manager assigns the job, and the dismantler sees only the orders they need.
The prototype made the operating rules visible
Payment releases the dismantle order.
A dismantler cannot see the order until the cash desk records a deposit or full payment. That matched the business rule behind the real operation.
The yard map replaces memory.
The 301-position map makes a vehicle searchable by plate, so finding a car doesn’t depend on someone remembering where it is parked.
Each role sees only the actions it needs.
The administrator, seller, cash desk, dismantle manager, and dismantler each get the controls for their part of the process instead of sharing one overloaded back office.
The prototype made the next scope concrete
The public sample shows the whole arc: a spoken description spread across several tools became a structured specification and a clickable operations system.
A single call became a product model.
The workflow moved from spoken explanation, paper sheets, WhatsApp, and memory into a structured PRD and functional spec.
The client could click through the operation.
The SvelteKit prototype covered counter sales, cash desk release, dismantle assignments, the yard map, and mobile-friendly dismantler work.
Scope moved from abstract to concrete.
The client could validate whether the app matched the yard before the full quote and phase plan became the conversation.
The repo shows the full paper trail.
The open work sample includes the discovery transcript, PRD, functional spec, live demo, seeded fake data, and prototype screenshots.
The client can inspect every product decision
The prototype is public as an anonymized work sample.
Live demo: desarmadero.pages.dev. Password: asado.
Repository: github.com/HanifCarroll/desarmadero.
The repo includes the raw discovery call transcript, PRD, functional spec, screenshots, seeded fake data, and the live prototype code.
A working model made the next decision clearer
This is the kind of business-systems work I do best: enter an unfamiliar operating environment, understand how the business actually works, turn that into a practical product structure, and use software to make the next decision clearer.
The prototype made the scope conversation better because the client could react to a real workflow instead of reviewing abstract requirements.
Tell me what your team needs to ship.
Start with the feature, integration, or system that's stuck. We'll work out whether a project or a monthly contract fits.