Case study · Community marketplace

Eyenbros

A marketplace for groups rather than individuals: pooling money, hiring professionals and running the work together, delivered across three MVP releases.

Delivered · Operations paused

Engagement
MVP programme partner
Platforms
Web application
Role
Product iteration, design and engineering
Outcome
Three releases delivered Verify before publishing
The Eyenbros platform: a tribe page with its members and pooled project fund, the professional bidding view on an open project, and the engagement dashboard.
Industry
Marketplace
Users
Tribes, members, professionals
Model
Pooled funding and bidding
Platforms
Web
Role
MVP programme
Status
Paused

01The business situation

Some projects belong to a group, not a person.

Marketplaces are built for one buyer hiring one seller. A great many real projects do not work that way: a group wants something done, everyone contributes, and someone has to coordinate the work and the money. The founder, Brahim Benaissa, a research scholar turned entrepreneur, was building toward that from an open-source base, and the question was whether the group-centred model would hold up with real users before more was invested in it.

Core challenge

Make a group a first-class participant in a marketplace, able to hold a project, pool money and hire against it.

Before

Marketplaces built around one buyer and one seller

  • Individual Buyers
  • Separate Fundraising
  • Off-platform Coordination
  • No Group Identity

After

A group that can hold a project, a budget and a hire

  • Tribe
  • Members
  • Professionals
  • Projects

Eyenbros Platform

02The system at a glance

One marketplace. Four connected experiences.

  • Engagement Dashboard Track projects and involvement
  • Tribe Space Membership and group projects
  • Bidding & Delivery Professionals bid and deliver
  • Connect Area Posts and community activity
Core PlatformGroup-owned projects with pooled funds
  • Tribe Creation
  • Member Contributions
  • Project Posting
  • Professional Bidding
  • Delivery Tracking
  • Community Feed

03Workflow 01

The tribe is the unit, not the user.

A member creates or joins a tribe. The tribe leader raises a project and collects contributions toward it from the membership. The group, not an individual, is what the platform organises around.

Image placeholder A tribe page: the group’s members, its active projects, and the pooled fund showing contributions collected toward the current project. assets/portfolio/eyenbros/workflow-tribe.png · 16 / 11
  • Groups hold projectsA tribe owns a project, so responsibility and funding are collective by design.
  • Contributions from membersThe leader collects toward a project from within the membership rather than from outside backers.
  • Join or createA user can start their own tribe or become part of an existing one.

04Workflow 02

Open the project. Take the bids. Run the work.

Once funded, a project opens to professionals. Bids arrive, one is chosen, and the work is carried out inside the platform rather than moving to email the moment money changes hands.

  1. 1Project opened

    Image placeholder A tribe project opened for bids: scope, pooled budget and the bidding window. assets/portfolio/eyenbros/step-project.png · 1 / 2.04

  2. 2Professionals bid

    Image placeholder Incoming bids from professionals with their proposals and pricing, ready for the tribe to compare. assets/portfolio/eyenbros/step-bids.png · 1 / 2.04

  3. 3Work delivered

    Image placeholder Project delivery view: progress against the agreed scope and the professional’s engagement record. assets/portfolio/eyenbros/step-delivery.png · 1 / 2.04

05Workflow 03

Three releases, each answering a different question.

The programme ran as genuine iteration. The first release tested whether group activity worked at all, the second added a reason to stay between projects, and the third rebuilt the experience around what those releases had shown.

  • Release one tested the coreMinimal group activity shipped first, to find out whether the model held with real users.
  • Release two added a reason to returnA non-transactional content side was introduced to drive engagement between projects.
  • Release three earned its designOnly once the feature set was settled did a dedicated designer rework the experience around it.
Image placeholder The three releases side by side: the initial group-activity build, the content-driven second release, and the redesigned third release. assets/portfolio/eyenbros/release-progression.png · 16 / 10
Image placeholder The connect area: user posts and community activity between projects. assets/portfolio/eyenbros/connect-area.png · 1 / 2.04

06Engineering behind the product

The system behind a group marketplace.

A stack that deliberately changed as the product learned, rather than being fixed at the start and defended afterwards.

  • Group-owned project model

    Tribes, memberships and projects are modelled so a group rather than an individual can hold and fund work.

  • Pooled contributions

    Members contribute toward a tribe project, and the project carries the collected total.

  • Bidding and award

    Professionals bid against an open project and the tribe selects, which required its own state machine.

  • Deliberate stack migration

    The inherited codebase was carried through the first release, then modernised for the second rather than rewritten up front.

  • Server-rendered pages retained

    Key pages stayed server-rendered for search visibility even as the rest moved to an API and client framework.

  • Community feed

    Posting and engagement run alongside the marketplace as a distinct surface.

  • Engagement dashboard

    Professionals and members track their involvement across projects in one view.

07Technical architecture

Under the hood

A stack that was deliberately migrated between releases as the product learned, rather than fixed at the outset.

Release one

  • Python 2.7
  • BackboneJS
  • Django templates

Release two onward

  • Python 3.x
  • Django REST Framework
  • VueJS

Data

  • PostgreSQL

Interface

  • Semantic UI (release two)
  • Bespoke design (release three)

08Delivery journey

How the platform was delivered.

  1. MVP programme

    Frame the questions each release answers

  2. Release one

    Minimal group activity, then feedback

  3. Release two

    Content layer and stack modernisation

  4. Design phase

    Dedicated design once scope settled

  5. Release three

    Rebuilt experience on the final feature set

  6. Sprint cycle

    Design, build, fix, repeat

  7. Support

    On hold for further phases

Three releases were delivered. The client moved beyond MVP before pausing operations during 2020–21; the product remains live and further phases are on hold pending their decision. Verify before publishing

09What the system enabled

What the delivered platform enabled

  • Groups able to form, fund and hold projects together
  • Member contributions pooled toward a shared budget
  • Professionals bidding on open group projects
  • Work carried out and tracked inside the platform
  • A community layer sustaining engagement between projects
  • Three iterations shaped by real user feedback

Related systems

EventsDF

Events · Discovery Platform · Web

A discovery platform for tech events worldwide (conferences, webinars and meetups), personalised by interest and searchable without an account.

View project overview , EventsDF

Humble

Content · Creator Platform · Web

A content platform for founders, pairing vetted entrepreneurial advice with mental-health resources and a discounted marketplace of startup tools.

View case study , Humble

Iteration means being willing to change your answer.

We run MVP programmes that test a question per release, and we change the build when the answer says so.

Discuss your system