The prototype establishes the interface direction, sample records, and browsing flow before full development begins.
A staged first release for a directory, map, and editorial system that helps the client publish trustworthy accessibility information without turning the platform into a maintenance burden, while keeping the first approval clear enough to move through committee review.
Thank you for the opportunity to put this forward. The brief does not read like a simple website refresh. It reads like the first release of a structured travel platform: people need to browse destinations, compare accessibility details, move between map and list views, and trust what they are reading when they land on a destination page.
That means the public experience and the editorial system have to be designed together. A polished interface without a calm content workflow will not hold up. In the same way, an organized data system without a clear front-end journey will feel heavy and confusing to the people the platform is meant to serve.
My recommendation is to approve the work in stages. The interactive prototype gives the committee something concrete to review first. Once that direction is signed off, the project moves into the live build and launch path. That keeps the first contract accountable, readable, and easier to defend internally.
The prototype establishes the interface direction, sample records, and browsing flow before full development begins.
This covers the active build environment, revision handling, testing rhythm, and the practical delivery work that keeps the process visible.
I turn the approved direction into the live platform: platform structure, CMS, search and filter logic, map behaviour, deployment, and the launch systems the team can actually use after release.
The first contract is designed to deliver one coherent version of the product. That means a clear discovery journey for visitors, a structured destination record behind the scenes, and an editorial setup the client team can manage after launch without turning routine updates into a technical project.
It also means the operational layer is included from the start. Lead handling, analytics, staging, launch controls, and a clear delivery transition are part of the proposal because they are part of what makes the build usable in the real world.
I stage the proposal so the committee has clarity before it commits to the full build. If the prototype shows that the journey needs adjusting, that happens early while the scope is still easy to refine. If the direction is right, the approved work carries directly into the live platform instead of being thrown away.
The recommendation stays simple: approve the prototype to confirm the experience, then move into the build that turns that approved direction into the first live release.
I recommend approving the prototype first, then moving into a clean $5,550 first release that delivers a real platform system instead of a brochure site with extra pages.
Forwardable summary after the scope and pricing review.