How Pixelhop turns project files into a clear, client-branded portal for every engagement.
Pixelhop is a small product studio. Every client project creates a lot of useful material: plans, tasks, decisions, updates, reports and roadmaps. We keep those working files in Treehouse, the shared workspace we use to organise the work. Treehouse is an exciting new project we have built, and we will share more about it soon.
That structure makes sense to us, but a client should not have to learn our filing system. So we give every Pixelhop client a separate web page, built in HTML inside Treehouse: a branded, read-only portal that turns the relevant files into one clear view.
They can see what is happening, find the latest update and jump straight to the section they need. The structure changes with the engagement, and we design each portal mainly around the client's branding.
It looks much more polished than the setup we had before, but the reason we changed it was not only visual.
See the portal in action
Here is a quick walkthrough of why we moved away from Notion and how the Rye & Beyond portal works.
What was not working in Notion
We used Notion as the home for client projects. We could keep an overview, updates, tasks and documents together, with an internal area for us and a shared area for the client.
We liked the structure, but Notion's permissions made it clunky to share and harder to collaborate. Something as basic as giving a client access could turn into a fiddly part of the project. Even once it was shared, it still looked and felt like a Notion workspace rather than a space made for that client.
We wanted to keep the useful part, which was having everything together, without making the client work around our project-management tool.
Before: our old Notion template kept internal and client areas together, but the client-facing side still looked like a generic workspace.
One front door, built around the client
The portal sits inside the same Treehouse workspace as the project files. We share that page with the client as a clear front door, using their colours, imagery and visual identity rather than forcing every project into the same template.
The portal is currently read-only for the client. They cannot edit the page itself, and we should not pretend that it replaces a collaborative document. Its job is to give everyone a clear shared view, with links and actions that point to the work happening around it.
That means we can send the main portal link when somebody needs the full picture, or link them directly to a report, task, document or roadmap section when we are discussing something specific. The client does not have to hunt through old emails or learn how we organise everything internally.
Different work needs different sections
We use the same basic portal idea for all clients, but we do not give everybody an identical page.
For a time-limited delivery project, the portal might include:
- the project overview and team;
- the timeline and weekly updates;
- current tasks and phases of work;
- client to-dos;
- project documentation.
For an ongoing retainer, where we return regularly to review and improve a client's site or product, the useful view is often more focused:
- the latest report;
- previous reports;
- the current roadmap;
- the areas we review on each retainer day;
- completed work, queued work and what we recommend next.
Rye & Beyond is a good example. We built and maintain their holiday cottage website, and their portal brings together each retainer-day report, the current roadmap, client actions and recommendations. We designed it around Rye & Beyond's own visual identity, so it feels connected to their business rather than like a generic Pixelhop dashboard.
After: the Rye & Beyond overview uses their visual identity and makes the latest report easy to find.
The roadmap gives current priorities a separate home from the permanent record of each retainer day.
A client in the middle of a delivery project needs a different view from a client checking what happened during the latest retainer day.
I get Glitch to create it
I do not sit down and hand-code every client portal myself. I get Glitch, our AI agent, to create or update the HTML page from the project files in Treehouse.
Glitch runs on Hermes, the system that lets it work across approved files and tools rather than only generate a block of text. The project files already contain the information the portal needs, such as plans, reports, decisions, tasks and documentation. Glitch can turn that material into the client-facing page, but Zef or I still review what is there before we share it. We remain responsible for what the client sees.
Because it is HTML, we can include whatever helps the client understand the work: graphs, data visualisations, interactive elements or a layout built specifically for that engagement. Read-only does not have to mean static or generic.
On Rye & Beyond's portal, a retainer report can open with a plain-English summary of what changed, what it means and what comes next.
The report starts with the client-friendly version, before getting into the detailed delivery record.
The same report can turn analytics into a clear set of headline numbers, with the source and date range attached to each one.
The stats stay useful because the explanation, source and measurement period travel with the numbers.
We are not maintaining the same information in a separate portal product either. The client view sits alongside the files we are already using to do the work, and we can change it without rebuilding the whole system.
A clearer way to share the work
There is no complicated new platform for the client to learn. They get a clear, professional view of the engagement, and we get a straightforward way to keep updates, links and next steps together.
It does not solve every kind of collaboration. Clients cannot edit the portal itself yet, and parts of the workflow still need a human check. What it gives us is a much slicker way to present the work and a better way to direct clients to exactly what they need.
For us, that has been enough to make a client-branded HTML portal the default front door for projects and retainers in Treehouse.
