Codetribe - Building Marketing Independence Into a Redesign

Codetribe was turning 10. The new site had to be ready and the dev team was buried in client work.

That's the position that Codetribe - a software engineering company with a decade of work behind them - was in when they brought me on. They'd just commissioned a beautiful visual identity and website redesign to mark their 10th anniversary. The design was excellent. The problem was getting it live in short notice.

Their engineering team was committed to client projects. Marketing and growth, the people who actually needed the new site, were stuck waiting on a dev queue that wasn't going to clear before the deadline. This is the bottleneck I see constantly: the website is a marketing asset, but it's held back by engineering availability.

So the first thing we did was reject the all-or-nothing launch.

Phase the launch

Instead of waiting for a complete site, we launched in phases - got the essential pages live, made the site public, then kept adding structure in bulk behind it. Marketing got a live anniversary site on time and we continued building the depth after. Nobody waited on a single monolithic handoff.

That decision set the tone for the rest of the project: keep the marketing team unblocked, solve the hard problems quietly underneath. But that wasn't everything...

The video issue nobody expected

Codetribe's homepage needed to feature a lot of case studies, and many of those case studies led with video and animated content. Two problems collided immediately:

1. Webflow's CMS doesn't natively host video. There was no built-in way to attach these videos to the case study records.‍

2. Too much video and animation tanks page speed, which directly damages SEO rankings. Loading a homepage full of heavy media the naive way would have meant trading visibility for visual polish.

Most devs solve this by dumping everything onto a third-party video hosting provider and accepting the load cost, or by cutting the video quality. I didn't want to do either.

Instead, I created a separate, non-public page, loaded all the case study videos onto it as static assets, and published it on the dev domain.

‍

With the videos now effectively hosted on the site itself, I pulled their direct URLs in both WebM and MP4 as a fallback...

‍

...and stored those URLs in custom fields on each case study CMS item.

‍

‍

On the front end, a custom code embed in the CMS collection item reads those fields and renders the video, behaving like a background-video element, but for CMS items, otherwise not supported natively in Webflow.

‍

‍

The WebM-first approach kept load times fast; the MP4 fallback kept it universally compatible. The videos were hosted on the site's own infrastructure, the CMS stayed manageable, and the SEO didn't suffer for the sake of the design. Both problems, solved with one mechanism.

‍

‍

These are the details that don't show up in a screenshot but decide whether a site feels finished or broken.

The Our Work page needed filtering. I used the well-known Finsweet Components List Filter as the foundation. But getting both the functionality and the aesthetics right took custom work on top of it.

One bug persisted in particular: the moment a filter was applied, the remaining videos and animations froze. Filtering re-renders the list, and the autoplaying background videos didn't survive the transition. So I wrote a routine that re-initializes and restarts video playback every time the filter updates, the list paginates, or the tab regains focus, so the page stays alive no matter how the visitor slices it.

‍

‍

‍

Built to be found and cited

A site can't be a growth engine if AI can't read it. So alongside the build, I made Codetribe's pages legible to the systems that increasingly decide what gets surfaced and cited.

‍

‍

Every page got structured data (schema), AND validated too, because schema that doesn't pass validation does nothing. Structured data is what lets search engines and AI models actually understand what a page is, rather than guessing from raw text. It's the single highest-leverage technical move for AI visibility at the moment.

‍

‍

Robots.txt is the one file these AI crawlers actually honor in practice, and it's the real lever for controlling how they access the site.

‍

‍

I'll be straight about this one: as of today, the major AI engines don't meaningfully read llms.txt yet. It's a proposed convention, not an adopted standard. I added it deliberately as a forward bet. It's cheap to ship, it costs nothing, and if AI agents do start routing on it, which is the direction the ecosystem is leaning - Codetribe is already positioned for it instead of scrambling later. Place your low-cost bet early!

Handing over the keys

The technical problems were mine to solve. But the real, long-term goal, that comes after the launch was making sure Codetribe's marketing team never had to wait on engineering again.

So I built them a system of editable, drag-and-drop components: modular blocks the marketing team could assemble into a new landing page themselves, in an afternoon, without a dev ticket. New campaign page, new case study, content edits — what used to mean filing a request and waiting in the engineering queue became something they just did.

‍

‍

Then I made sure they could actually use it. I onboarded the marketing stakeholders directly and walked them through the system, so the handoff wasn't a set of files nobody understood, but rather a working capability the team owned. A component library nobody knows how to operate is just a prettier bottleneck. The point was independence, and independence only counts if the people who need it can use it without me.

‍

‍

That's the shift that mattered most: the website stopped being something the dev team maintains and became something the growth team operates.

The takeaway

The deliverable was a website. The actual job was making sure a marketing team could launch on time, rank well, and run the site themselves afterward - without a single engineering ticket.

A website should leave the marketing team more independent than it found them, not more dependent on whoever built it. That's what a growth engine is: not a brochure you file requests against, but a system the people closest to the market can operate at their own speed.

Check out the live website here.