Recently, a client came to us with a website that lived inside a chat.
That is a strange sentence, but it describes a real stage of work now. They already had something useful: a first version with a direction, a feel, and enough detail to react to.
The problem was that the site was still trapped in the form it was generated in. It was not yet a project they could own, host, edit, or maintain with confidence.
AI got them to a first version. The next step was turning that version into a website they could actually keep.
What they had was very good, and they liked it.
Our job was to take what was already working and give it structure.
What was missing
It looked like a site in the browser, but it had not yet been turned into a full project. The structure for hosting, deployment, and later changes was still being put in place.
That gap is where this kind of work really begins.
- A clearer file and folder structure
- Separate pages where needed
- Assets stored and organized properly
- A domain and a real hosting setup
- A publishing flow that could continue after launch
From output to project
We took the first version out of the chat and turned it into a real web project. That meant splitting sections into proper pages, separating assets from the main document, and organizing the code so someone could come back later and understand how it fit together.
We also helped connect the domain, host the site, and set up a GitHub-based deployment flow so the project would not depend on manually rebuilding the same setup every time something changed. Once that was in place, the client had a site they could keep working on without returning to the original chat.
Ownership matters
One of the most important parts of the job was ownership, even though it was not visible on the site at all.
We set up GitHub on the client’s machine, authenticated it properly, and made sure the project lived in a place they could return to without depending on us to recover context. We also set up a simple push-to-deploy flow so small edits would not turn into a heavy process.
That mattered because it moved the work out of a closed conversation and into a usable environment. The client could now continue from a local project with files, history, and a deploy path, instead of treating the original chat as the only source of truth.
Agency matters
We did not move the site into a more traditional CMS setup because that would have reduced the client’s agency.
The client had already started in a different way, liked the level of control they had, and wanted to keep shaping more than just text and images. They wanted authority over the look, feel, animations, structure, and flow of the site itself. A conventional CMS would have narrowed their control to a smaller editing box than the one they had already grown comfortable with.
Because this was a simple business website rather than a large application with heavy operational risk, the downside of letting them work closer to the project was low. The chance of breaking something critical was near zero, and the upside was that they could keep building with the same sense of authorship that had helped them start.
We did not want to reduce the client’s agency. We wanted to preserve it.
Our experience
It was exciting to work through. The starting point was unusual, and the problems were slightly different from the ones we are used to. We look forward to more projects like this, with new challenges and new ways to collaborate with clients as these tools become part of how they run their businesses.
Share this post