Timeline: 8–9 weeks

Framer Development · CMS Architecture · System Design · Form Logic · Integrations · QA & Testing

When Ben reached out, the idea was clear, but the product wasn’t built yet.

CoBuildr is designed to solve a specific problem: helping founders find the right people to build with. Not through cold outreach or scattered communities, but through a more structured, intentional experience. The long-term vision was a full platform. Accounts. Dashboards. Messaging. A complete ecosystem.

But jumping straight into building that would have been the wrong move.

The real question wasn’t how to build the platform. It was whether the demand was there in the first place. So instead of overengineering early, the goal became building an MVP that could simulate the core experience, validate interest, and create a strong first impression, all within a Framer site.

On the surface, this looked like a standard marketing site. Underneath, it wasn’t.

The core of the experience relied on two things working seamlessly together:

A project submission flow, where founders could post their ideas

A browse directory, where users could filter and explore those projects

Both needed to feel dynamic, structured, and reliable — closer to a product than a typical website. The complexity came from how everything connected.

Each project page needed to be almost entirely populated by CMS data, pulled directly from the submission form. That meant structuring the CMS in a way that could handle variability without breaking layout or clarity. At the same time, the browse experience needed to feel intuitive. Users had to be able to filter projects by industry, project type, and trial possibilities without friction.

No third-party tools. No external systems. Just Framer. Getting that right was where the real work was.

Before touching the build, I mapped the entire experience from both sides.

From the founder’s perspective: How easy is it to submit a project? What information actually matters? What should be required vs optional?

From the browser’s perspective: How quickly can someone understand what’s available? How easily can they narrow down options? How clear is each project at a glance?

The structure was built around reducing ambiguity. Projects needed to be consistent enough to scan quickly, but flexible enough to handle different types of ideas. The CMS became the foundation of that balance.

Instead of thinking in pages, the system was designed around relationships:

Form → CMS → Directory → Detail Page

Everything had to connect cleanly.

The goal wasn’t just to “launch a site.” It was to create something that felt like a real product, even in its earliest version.

With the structure defined, the build moved into Framer. This is where most of the complexity lived.

The project detail pages were designed to be almost entirely CMS-driven. Content submitted through the form populated everything dynamically — from core descriptions to structured metadata. The challenge was making that flexible without sacrificing visual consistency. At the same time, the browse directory required a fully custom filter system.

Users can sort projects by:

Industry

Project type

After-trial possibilities

All handled natively, without relying on third-party tools. This wasn’t just a visual component. It required careful structuring behind the scenes to ensure filters worked reliably across all combinations, while still feeling fast and intuitive.

The result is a system that looks simple on the surface, but carries a significant amount of logic underneath. On the design side, the direction stayed consistent with the goal: clean, structured, and easy to navigate.

Clear hierarchy. Intentional spacing. Minimal friction.

Something that feels credible immediately, but doesn’t get in the way of the core action: exploring projects.

Throughout the build, Ben was kept in the loop through regular Loom updates, walking through decisions, progress, and tradeoffs as they happened.

One of the more important parts of this project isn’t immediately visible.

The entire experience is powered by how the CMS and form logic were set up.

Instead of treating the CMS as a static content layer, it was structured as the backbone of the product experience. Every field, every relationship, every piece of data had a purpose.

That’s what allows:

Projects to render consistently

Filters to work accurately

The experience to scale without needing to rebuild

It’s the difference between a site that looks dynamic and one that actually behaves like a product.

Once everything was built and tested, I put together a full handoff system for Ben.

A structured set of Loom videos covering:

How the CMS is organised

How to manage and update projects

How the filtering system works

How to extend the site as the platform evolves

Everything documented clearly.

The goal was simple: no guesswork after handoff.

The final result is an MVP that does exactly what it needs to do.

It allows real users to:

Submit projects

Browse opportunities

Interact with the core idea behind the platform

Without needing to build the full product upfront.

It creates a realistic test environment for demand, while still feeling polished and intentional.

And importantly, it sets a strong foundation for what comes next.

Most MVPs fail because they try to prove too much, too early. They overbuild. Overcomplicate. Or skip structure entirely.

CoBuildr took a different approach. Instead of building the full platform, we focused on building the right slice of it, the part that proves whether the idea works.

Clear structure. Real interactions. No unnecessary complexity. That’s what makes this project valuable.

It doesn’t just look like a product. It behaves like one.

And that’s what allows it to answer the only question that matters at this stage:

Is this worth building further?