ShareTalent: a portfolio and discovery network for mission-driven creative work, on Bubble.io.

After the seventeen-month engagement on ShareTalent’s first product wound down, the founder came back with a new brief. He was building a different product on the same brand. The trust earned on the first engagement had already settled the question of who would lead the build. “We are building this new product, based on our experience with you, we want you to lead this. We will design Figma and create tasks for you. You implement them on time with pixel perfection. Performance is non-negotiable, even on Bubble.io.” Two non-negotiables, on a platform that usually trades one for the other.

The new product is a portfolio and discovery network for mission-driven creative work. Talent post work samples (case studies, design pieces, videos, blog posts) under tagged categories. Nonprofits and mission-driven organisations browse the discovery feed, click into a talent profile, and click “Work with [Name]” to start a conversation. The transaction is intro-first, not contract-first. A jobs surface sits alongside the directory, where both talent and companies can post paid roles. Agentic AI resume import does the heavy lifting on talent onboarding. The product is live at sharetalent.co.

The brief paired pixel-perfect Figma implementation with workload-units performance. On Bubble.io those usually trade against each other. A pixel-faithful design means dense container trees, conditional visibility for every state, repeating groups stacked inside repeating groups, and on-page workflows that recompute as the user touches anything. All of those land in the workload-units bill. The cheap way to keep WU low is to simplify the UI; the cheap way to ship the Figma is to ignore WU and ship the heavy version. The brief refused both shortcuts.

The work was holding both lines from the first page. Every layout was a faithful read of the Figma. Every workflow that touched the database was scoped, paginated, and server-side. Conditional visibility ran off pre-computed state instead of live searches. Repeating groups paginated against indexed constraints instead of loading the full collection. The pattern repeated across every surface the user could touch.

The Figma led. The data model followed. That inverts the textbook advice (model first, UI second) but it was the right call for a UI-first product. The discovery feed needed to render work-sample cards with author, category, and save state in one repeating-group pass. The talent directory needed to render a talent’s profile with their work samples embedded, in one pass. The job-matching surface needed to score talent against jobs across three taxonomy axes, in one query. If the data model had been normalised the textbook way, every one of those surfaces would have paid for the joins on every render.

The schema was designed in the other direction. Denormalise where the feed needs to be fast. Keep the relations where the admin operations need them clean. Three taxonomy lists (Causes, Categories, Skills) sit at the centre of matching, search, and filter. Each is implemented as an Option Set for the label and a Data Type for the cross-relations between lists, which keeps the static labels cheap to read and the relations queryable.

The homepage is the discovery feed. Search bar at the top. Suggestion chips beneath it rotate through real categories pulled from the live data. A horizontal tab bar of nine high-level categories sits below that, with a filter button on the right for the finer cuts. Then the grid. Each card is a work sample, with the talent’s avatar, name, and a category tag on the meta row. The card layout is the same on every surface, and that consistency is doing work; a search result, a category filter, and an “explore” view all return cards the user has already learned how to read.

The talent directory is the second front door. A grid of talent cards, each one showing the person’s avatar, headline, location, a row of their work samples inline, a row of their skill tags, and a “Work with [Name]” button. The directory answers “who could I commission?” the way the discovery feed answers “what work is being shared?” The “Work with [Name]” CTA is the conversion event on the directory side. Pressing it captures the nonprofit’s brief and routes the message into the talent’s inbox. The intro is the first product action; the contract relationship, where it happens at all, comes downstream of a conversation that has already gone well.

Talent onboarding is the surface where most of the AI work sits. A user uploads a resume. The file goes into an n8n workflow where an AI agent extracts the structured fields and matches them against the live database (the three taxonomy lists, the option sets, the related records). Before any backend workflow writes anything, the user sees a popup that shows the AI’s proposals field by field and lets them choose which to keep. The write only happens after the user signs off.

Two calls in that flow are worth naming. The first is that Bubble.io’s Data API stays closed. The naive integration would open the Data API to make the n8n workflow easier, but that exposes a write surface broader than the workflow actually needs. The closed-Data-API decision is a security one I will not trade away. Every write is server-side through backend workflows that respect Privacy Rules.

The second is that the user reviews the AI’s proposals before they land. AI extraction is good but not perfect; a wrong job title or a misclassified category in the search index degrades discovery for every nonprofit browsing for that talent. The popup is the seam where AI gets to be useful without being trusted.

The third surface in the top navigation is Jobs. The model is simple. Both talent and companies can post paid roles; nonprofits browse the listings; applicants bring their work-sample portfolios with them by default. The pricing has two self-serve tiers plus a white-glove placement service the founder runs alongside the platform for higher-touch hires, each with a 90-day satisfaction guarantee.

Job posting does not require onboarding. A company creates an account, adds the role, and the post is live. The work-sample model gave the jobs surface a credentialing layer the marketplace did not need to build from scratch, because anyone applying brings a portfolio with them by default.

Talent get the platform free. The Pro subscription, Share Talent Pro at $6 per month, adds two things on top: a Search Boost that lifts the Pro profile in the discovery and directory rankings, and access to the Share Services Shortlist, a curated talent list the recruitment side draws from when matching against client briefs. The price is deliberate. It is low enough that an early-career talent will subscribe to be visible; it is also low enough that it is not the platform’s primary revenue model. The job-posting business and the white-glove recruitment service carry that.

The product has SEO baked into the data model in a way most Bubble.io builds do not. Every image alt on the public surface follows the same pattern: a descriptive primary line, then a separator, then the platform marker. Every talent avatar carries an alt of the form “[Name] - Find Nonprofit Freelancers and Talent | Share Talent”. Those alts are not hand-typed per page; they are generated from a template that pulls the relevant fields off each record. Page titles, meta descriptions, and Open Graph tags follow the same pattern.

The payoff is that adding new work samples and new talent profiles ships with their SEO already correct, rather than requiring a follow-up audit pass. The product team can publish new content without the question “did we remember to set the alts?” coming up.

The brief said performance is non-negotiable. On a workload-units billed platform, that lives or dies on the search layer. Every list a user sees is backed by a search. Every conditional visibility that depends on the database is a search. Every action that branches on a record state is a search. The default Bubble pattern (load all rows, filter client-side) is the cheapest path to ship and the most expensive path to run. The whole product was built away from that default.

None of these are exotic tricks. They are the discipline of writing the search as if you are paying for every row read, which on Bubble’s workload-units pricing, you are.

The account layer is the part of the product that has to feel boring and reliable. Signup is Google, LinkedIn, or email + password, in that order, because the audience already lives on the first two. Login mirrors signup. The settings panel splits into Login & Security, Notifications, Membership & Billing, and Help & Support. Notifications are individually toggleable, split into app alerts and marketing alerts. Membership & Billing reads off Stripe directly; the same panel manages billing and cancels the subscription.

Nothing on these screens is novel. The point is that they are not the part of the product that fails under load, because the data they read is small and the workflows they run are simple. The hard performance work lives upstream on the discovery feed.

The new product shipped publicly on a Bubble.io codebase that holds both the brief’s lines at the same time. The Figma lands faithfully on every surface. The workload-units bill holds at the UI-first scale. The discovery feed, the talent directory, and the jobs surface read off a data model that was designed around the UI rather than against it. The Agentic AI resume import does the work without being trusted; the popup is the seam. The SEO is in the page model, not in a follow-up audit. The relationship that started with the first ShareTalent engagement, and that earned the brief on this one, continues as the senior Bubble.io developer on the platform.

The pattern of the engagement is the part I would do again.