Skip to content
← Work

Creative Crowdfunding Protocol

Rebuilding the frontend architecture behind Catarse

Architected and led the frontend for one of Brazil’s largest crowdfunding platforms, and cut the cost of shipping a new feature by roughly a third.

The problem

Catarse is one of Brazil’s largest crowdfunding platforms. Crowdfunding is an unusually demanding product surface: a campaign page is simultaneously a marketing landing page, a checkout flow, and a live financial dashboard, and all three have to stay correct while pledges are arriving. On top of that, the same core domain had to be reshaped repeatedly for different markets and different clients.

The constraint that shaped everything was that the platform could not stop shipping while being re-architected. There was no greenfield rewrite available.

What I owned

I architected and led the frontend application, and I was responsible for the structural decisions rather than only the feature work: how the codebase was organised, where domain logic was allowed to live, and what the contract between frontend and backend looked like. I also led the frontend team for Rakunew and PledgeX, a Japanese eCommerce ecosystem built on the same foundations, which meant the architecture had to survive being pointed at a second, quite different market.

Decisions and tradeoffs

The central decision was to invest in reusable domain modules rather than reusable UI components. Component libraries are the obvious first move, and they help, but they do not address the actual duplication in a product like this: the same pledge, reward, and payout rules being re-derived slightly differently in every new surface. Moving that logic into shared modules with explicit boundaries meant a new campaign surface composed existing behaviour instead of reimplementing it.

The tradeoff was real: this is slower per-feature in the first few months and it puts a tax on contributors who just want to ship a button. It only pays off if the product keeps growing new surfaces — which, given the multi-client roadmap, it clearly was going to.

I paired that with work on the backend read path, optimising API performance and adding caching layers so the campaign pages could stay live under load without the frontend having to defensively over-fetch.

Outcome

New feature development time dropped by roughly 30%, and contributor developer experience improved measurably — the architecture stopped being the thing people had to work around. The same foundation went on to carry Rakunew and PledgeX rather than being forked.