17 min read
One year in: building a 3-sided marketplace
Challenges, breakthroughs and lessons learned
Mario Jurić · Posted on September 30, 2026
Hundreds of Brands. Thousands of Creators. Tens of thousands of deliverables and One agency that runs the operations. That was the scale we were building towards.
What are the operations? Every campaign Crew operates is done for a Brand, has its own shortlist of creators that Crew hand picks, its own deals with each creator, products to ship, videos to review, brand notes to pass on, publishing dates to chase, statistics to collect and reports to finalise. Scenarios are written for each deliverable. Campaign Briefs must be shared with all the Creator collaborators on the campaign. Every change must be communicated through different channels. At that scale the work lives in spreadsheets, email threads, group chats and somebody's memory. Which version of the deal did this creator agree to? Did the brand approve the second cut or the first? Has the product even shipped? Nobody is careless. The work simply outgrows the tools.
That was the challenge.
Crew had a real problem to solve and genuinely robust process they already developed. The scope was pretty clear from the start, the process was already working but difficult to scale and it was genuinely difficult technical problem to solve. Finally Crew gave us complete technical freedom and entrusted us with making this a reality. Difficult problem with full technical autonomy. Can't get better than that!
What we usually do when the problem is of this magnitude is we try to split it into deliverable functional, valuable chunks that we usually ship in 6 week cadences. This was a big decision from the start. Do we start small and build or do we go all-in. There are a lot of moving pieces to this platform, but it genuinely does not work if all the pieces are not there in one form or another - we went all in.
Every influencer campaign Crew runs is a joint project between three parties: the brand that pays, the creators who make the content, and Crew, the agency that brings them together. Each needs something different from the same piece of work. A brand needs results it can stand behind. A creator needs clear terms and to know what to do next. The agency needs to deliver quality across dozens of campaigns at once.
Chopor is the three-sided marketplace all three work in, and it is a partnership: we at Upheave build the system, and Crew operates the service on top of it. One year in, all three parties work on the same campaigns in one place, each seeing the version of the work that is useful to them.
The hypothesis we wanted to prove is, can one piece of software serve three parties with different goals so well that it feels made for each of them.
Brand, creator and Crew: one campaign, three jobs, and a view of the work built for each
Each of the three parties comes to a campaign with a job to do, and Chopor is built around that job.
The brand is paying for outcomes. It wants to see its campaign moving, approve the work that carries its name, and know that what reaches it has already been checked. On Chopor, a brand drafts its campaign, suggests creators it likes, approves finished content and sees the results. Its time goes to decisions, not to first drafts.
The creator is doing the work and running a small business of their own. They want clear terms, fair treatment when things change, and a single answer to "what do I do next?". On Chopor, a creator sees their offers, what they owe and when, and feedback that arrives in one consistent voice.
Crew, the agency, is the reason the arrangement works. It picks the creators, agrees the terms, guarantees quality and keeps every campaign on schedule, across many brands at once. On Chopor, Crew sees everything, and sees it as a list of things to do: what's waiting for review, who's running late, which offers still need an answer.
| What they're there to do | What Chopor gives them | |
|---|---|---|
| Brand | Get results it can put its name to | A clear view of progress, finished work to approve, and results at the end |
| Creator | Make great content and get paid fairly | Clear terms, a clear comparison whenever terms change, and one next step at a time |
| Crew | Guarantee quality across many campaigns | The full picture of every campaign, turned into tasks |
Who needs to see what, and when? In any business with someone in the middle, that is the service
Influencer marketing is one example of a very common shape. A recruiter sits between a company and its candidates. A property agent sits between a seller and buyers. A general contractor sits between a homeowner and a dozen trades. An event planner sits between a client and every supplier on the day.
In each of these, the business in the middle earns its place by curating: deciding what reaches each side, in what form, at what moment. A recruiter doesn't forward every CV. A contractor doesn't send the homeowner every supplier quote. That judgement is the service.
The tempting way to build software for these businesses is to design it for one side, then open it up to the others with a smaller version of the same screens. We think that gets the problem backwards. When curation is the service, the software should be designed from the curation outward: decide what each party needs to see and when, then build what delivers it.
One platform or three apps?
Before a single screen existed, we had to decide what shape Chopor would take. Three parties with three different jobs point naturally at three products: a brand portal, a creator app and an agency back office, each with its own tailored layer on the server behind it. Engineers call that layer a backend-for-frontend, a small server built to serve exactly one app.
We built none of that. Chopor is one platform. Brands, creators and Crew open the same pages, and each page decides what to show based on who is looking. It was the first real bet of the project, it was taken before we knew most of what we know now, and it would have been very expensive to undo.
The case for three separate apps is strong
Intuition says split them.
Each app would be simpler. A creator app only ever thinks about creators, and nobody building it has to ask "but what does the brand see here?" on every screen.
Each audience would get a product shaped entirely for it. Brands and creators have different habits, different devices and different expectations, and one design language stretched across all three is a compromise by definition.
Separate apps keep problems contained. A change made for brands can't disturb anything creators rely on, because they don't share the screen it lives on. Teams can work in parallel and release on their own schedules.
Splitting the apps doesn't have to split the rules, either. The common version, which Sam Newman describes as backends for frontends, keeps the shared rules in services underneath and gives each audience its own thin backend and app. The rules live in one place, and each audience still gets a product of its own.
And a single platform concentrates risk. Every page has to know who is looking, every change has to be checked from every side, and a mistake in that logic shows up in front of the wrong audience.
The hard part of one platform is permissions, so we solved that first
A campaign is not three things. It's one thing that three parties act on in turn. The same video is uploaded by a creator, reviewed by Crew, approved by the brand and published, and all three need to see where it stands.
Putting all three parties on one platform has one hard problem, and it isn't the screens. It's deciding who gets to see and do what, based on each person's role and the permissions that role carries. That problem compounds. Every new role, permission and business rule multiplies the cases every page has to get right.
So that is what we tested first, before we committed to anything. We built the permission system first: one place that defines every role and what it may see and do, applied to every page, every action and every update. Once it held, the benefits of one platform came with it: one codebase, one set of rules, one way of building, and every screen reading from the same answer.
A shared system behind three apps solves half of that. The rules live in one place, but there are still three apps, three codebases and most likely three people or teams building them, and the apps drift out of step with each other even when the rules underneath don't. The trade we made is managing complexity inside one codebase instead of managing three codebases. We think the first is the easier problem to keep solved.
And we bet that the three sides wouldn't be three neat groups. They aren't. Chopor has seven roles, not three. The brand side alone has people who run the account, people who help, and people who manage specific campaigns, and the agency side has staff who work closely with creators and staff who only need the numbers. In one platform, a new role is a change to the rules, not a new product.
One year in, a rule change goes in once and every screen follows
The strongest evidence is how change behaves. When we needed to adjust what brands could see about creators during recruitment, the change went in once, on the server, and every screen that shows creators followed it. With three apps, the rule would have changed once and three sets of screens would still have needed checking and releasing.
The same page serves different people. Chopor's home screen is one address with a version for each kind of user: brands see content waiting for their approval, creators see their obligations and open invitations, and Crew sees who's running behind. A campaign page shows each role the parts that matter to it. Each of those pages was built once; with three apps, the campaign page alone would exist three times. The data behind each view is prepared for that role before it leaves the server, so what someone doesn't need never reaches their screen in the first place.
All access in Chopor is defined in one place and applied automatically every time the platform is updated. No role is ever configured by hand.
Every change is checked from every side, and some screens are more complex than they would be in a single-audience app. We'd make the same choice again, because the thing all three parties share, the campaign, is the thing we most needed to get right.
What would change our minds: a business with this shape finding that separate apps let it keep up with its clients' changing requests faster, over several years, than one shared platform. Closer to home: if most of what Crew needs changed over the next year touches one party's screens rather than the rules all three share, the case for one platform gets weaker.
Each party follows the same work from its own vantage point
Every video in a campaign travels one path, from idea to upload, through review and approval, to publication and results. What changes is where each party stands on that path.
Crew sees every step, because running the work is Crew's job. The brand sees work once it is ready for the brand: finished, reviewed, and waiting for a decision. The creator sees their content go to Crew and hears back from Crew, as one set of clear notes rather than a relay of comments from several people. One path, three views of it, and each view makes sense for the person looking.
Progress is never typed in by hand. Chopor records when each real event happened, when content was uploaded, reviewed, approved and published, and works out where things stand from those facts. The status on the screen always matches what actually happened, for all three parties, without anyone having to remember to update it. Content can go back for as many rounds of revision as it needs, and every round stays in the history.
Agreements change, and the record of what everyone agreed to never does
Plans change in every campaign. A brand wants one more video, or one fewer. A product ships late. A creator's schedule moves. Chopor had to make change easy without ever losing track of who agreed to what.
So an agreement is never edited. When terms change, Chopor creates a new version, linked to the original and carrying the reason for the change. The original stays in force until the new one is accepted. If it isn't, nothing that was agreed has moved.
The creator sees the change as a comparison: current terms next to proposed ones, every difference marked, and the reason on top. No one has to reread a contract to find out what changed. Every version, accepted or not, stays on record. For the creator that's protection. For the brand and Crew it's a clear history if a question comes up months later.
Versioned agreements are good for fairness and hard on arithmetic. When one creator can have an agreed deal and a proposed change to it at the same moment, a naive total counts them twice. Chopor counts every creator exactly once, whatever state their deal is in, so the budget a brand sees stays right while the details are still moving.
A campaign stays flexible until someone commits, and then what they committed to holds still
The rule behind a campaign's whole life is simple enough to apply to any shared project: anything is flexible until another party has agreed to it, and then it holds.
While a campaign is still a draft, the brand can change anything, and before it goes live Chopor lists every problem at once, so the brand fixes everything in one pass instead of discovering issues one at a time. Once creators have said yes, the things they said yes to stop moving. Everything that doesn't affect them stays open to change.
96 business actions in one part of the platform: what it takes for a campaign to feel simple
A campaign that feels simple to use is built out of a great many precise decisions.
The campaigns part of Chopor alone handles 96 distinct business actions, from sending an offer to removing a creator to approving a video. Each one has its own rules about who may do it, at which point in the campaign, and what else changes when they do.
Across the whole platform there are 80 separate permissions spread over 7 roles. That's 80 individual answers to questions like "may this person see this?", all written in one place and applied every time the platform is updated.
And each creator's place in a campaign moves through 7 possible statuses with 11 permitted ways of moving between them. Anything outside those eleven moves simply can't happen.
None of these numbers is visible to the people using Chopor. A brand sees a campaign with clear next steps. The 96 actions are what make those next steps correct.
Every party hears from Chopor in its own voice, and always knows who to talk to
The words change with the reader. Chopor runs in Croatian, and brands are addressed formally (vi) while creators are addressed informally (ti), the way you'd speak to each in person. The short explanation of where a campaign stands, and what comes next, is written separately for each audience. Crew, who doesn't need one, doesn't get one.
Contacting the agency works the way people actually think about it. Brands and creators don't want to choose between a list of staff; they want to reach Crew. Every "Contact Crew" message goes to one agency inbox, and the agency is part of every conversation on the platform.
Our bet: the businesses in the middle will be valued for how well their software curates
We expect each party in a campaign to be joined by AI assistants acting on their behalf: a brand's assistant following up on approvals, a creator's assistant keeping track of offers and deadlines. We tested that direction by building a whole product with no screens at all, in Building a real SaaS like application exclusively on top of MCP with no User Interface.
If that holds, the question of who sees what stops being a design detail and becomes the core of the service. An assistant reads everything it's given, every time. Businesses whose software already decides, in one place, what each party needs will be ready for that. The ones that bolted the second and third party onto a system built for one will have work to do.
Our bet is that agencies, brokers, marketplaces and every other business that earns its place in the middle will increasingly be judged by how well their software does the curating they do in person.
Scope, timelines and the secret sauce
Creators management, campaign lifecycle management, complex deliverables orchestration, asset delivery, multi-step; multi-touchpoint process orchestration, complex permission system, creator collaboration invites, in-app messaging, escalation notifications, multi tenancy, org user management and much more. Chopor truly is a complex system built from scratch to accommodate the already robust process Crew established over the years.
A team of three developed the first production version of this platform with all these features in ~6 months.
One critical aspect of this success was the process that Crew was able to define almost to perfection. They were living it for years but their scale outgrew their current tools and they needed a robust system.
The experience of people involved from our side played a huge role.
However the most critical part that enables us to deliver a platform of this scale in this timeline was fully leaning on AI assisted development from day one. This was not a spur of the moment decision but a strategic plan that made us completely re-work how we do things internally.
First several weeks of the project were spent building the initial version of the agents and rules harness around Claude Code. The tool we used prior to that was Aider but Claude Code proved to be superior for the needs that we had. This project started in fall of 2025 so this was the early days of AI assisted coding. We were faced with constant changes of the ecosystem. The process around the coding harness never stopped and it evolved along with new capabilities in Claude code and our iterative process.
The architecture, tools, frameworks and other foundational challenges were all considered carefully and deliberately. Only when we were getting consistently robust results from the coding agents were we ready to actually start working on actual features.
This foundation was later extracted to a standalone harness we call Nucleus and that's become our actual Factory we've written about previously.
Ten questions to answer before you build software for more than one side of a deal
- Who are the parties, and what is each one there to do? Write it in one line per party before listing a single feature.
- What does each party need to see to do that well? And what would only add noise for them?
- Where does your own value come from? If it's judgement, review or curation, design the product so that work is visible to you and its results are what everyone else receives.
- One platform or several apps? Decide early, and decide on the strength of what the parties share, not on how different their screens look.
- Is progress typed in or worked out from what happened? Worked out from real events is the version that stays true for everyone.
- What happens when an agreement changes? Keep the old version in force until the new one is accepted, and keep every version on record.
- How is money counted once agreements have versions? Once per person, whatever state their deal is in.
- What locks, and when? Something locks when another party has relied on it, not before.
- Who does each party talk to? Route every conversation through the role that owns the relationship.
- Does each party hear from you in their own voice? Formal where it should be, informal where it should be, and silent where nothing needs saying.
The rule: design what each party needs before you design the screens
In any business with more than one side, the value is in giving each party exactly the right view of shared work. Start with the table of who needs what, and the screens follow from it.
