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

Two non-negotiables, both load-bearing.

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.

A data model designed around the UI, not the other way around.

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 discovery feed and the talent directory.

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.

Resume import via n8n, with a human review gate.

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 jobs surface, paid roles for talent and companies.

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 (Standard Job at $90 per month, Featured Job at $180 per month) plus a white-glove placement service the founder runs alongside the platform for higher-touch hires (Freelancer at $1,500, Junior to Mid FTE at $5,000, Senior to Director FTE at $9,000, 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.

A Pro subscription for talent, on top of the free profile.

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.

SEO architecture, built into the page model.

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.

Workload units, optimised across every search surface.

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.

The optimisation pass ran across every surface. Page-load searches scoped to the minimum the page actually needs, not the maximum the data type allows. Repeating-group searches paginated against indexed constraints rather than fetching the full collection. Conditional-visibility searches cached into custom states at page load instead of running on every paint. Action-level searches narrowed by the constraints they were going to filter on anyway, so the database did the work instead of Bubble’s evaluator. Daisy-chain filters (one search’s result feeding into the next search’s constraint) collapsed into single queries where the chain was a join in disguise. The job-matching surface, which scores a talent against a job across the three taxonomy axes, compiled to a single ranked search rather than several filters and a sort.

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.

Account surfaces: signup, login, billing, notifications.

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.