Build vs Buy: the real cost of building shoppable UGC galleries in-house

The reason this matters is that "build vs buy" is almost never lost on the build. It is lost on the maintenance. The first version ships, everyone is pleased, and then the bill arrives every quarter forever in the form of a slice of your best engineers' attention. So let me start with the picture that the phrase "just a gallery" hides.

"It's just a gallery"

Picture what you are imagining when you say it. A responsive grid of customer clips. Tap one, it expands. There is a product tag, a price, an add-to-cart. It autoplays muted, it lazy-loads, it looks good on a phone. A competent front-end engineer could build that in a sprint, and they would be right. That part is genuinely a sprint.

The grid is the tip above the waterline. It is the part you can see, which is exactly why it is the part everyone budgets for. The platform that has to exist for that grid to keep working, stay legal, stay fast and actually drive revenue, is the nine-tenths under the surface that nobody costs until they are already in the water.

None of these is optional in the way the grid implies. Skip rights and you have a legal exposure with your customers' faces on it. Skip performance and the gallery you built to lift conversion drags it down through Core Web Vitals. Skip attribution and you can never answer the only question finance will ask, which is whether the thing earned its keep. Every layer under the waterline is load-bearing.

The feature surface you would own

Here is the same iceberg written as a checklist, because a list is harder to wave away than a metaphor. This is not a wishlist of nice-to-haves. It is the surface area of a UGC platform that brands already expect, drawn from what our own product has to do to stay competitive. Read it as "things that are now your team's job, forever".

Look at where the chips cluster. The grid sits, alone, in the corner you budgeted for. Almost everything else lives in the top half, the half that changes on its own and bills you in maintenance. And the densest cluster is top-right: heavy to build and never finished. That cluster is the product. The grid is the demo.

• Multi-source ingestion. Ten source platforms at last count (Instagram, TikTok, YouTube, X, LinkedIn, Threads, Google Reviews, Trustpilot, Feefo, TripAdvisor), each with its own OAuth, rate limits, content rules and a habit of shipping breaking changes without asking you.
• Rights, consent and legal compliance. Request flows, an auditable consent record, expiry and takedown. The layer no demo shows and every lawyer asks about.
• AI moderation and tagging. Pull the irrelevant and unsafe before it is published; auto-tag the right product to the right clip. A model you train, evaluate and re-train.
• ~50 layouts. Grids, carousels, stories, sliders, mosaics, pop-ups, PDP widgets, link-in-bio, each responsive and theme-aware.
• Shoppable checkout. One-click add-to-cart from a clip, with live price, variant and stock so you never tag a sold-out SKU.
• Performance and Core Web Vitals. The reference build lazy-loads a 37 KB widget. Hitting and holding that under load is continuous work, not a one-time win.
• Analytics and attribution. Per-clip and per-source impressions, engagement, add-to-cart and attributed revenue.
• A/B testing. The machinery to prove a layout or placement actually lifts conversion, not just engagement.
• Multi-platform. Shopify, Shopify Plus, WooCommerce, Magento / Adobe Commerce, BigCommerce, and the long tail (SFCC, Hybris, PrestaShop) each integrate differently.
• Accessibility. WCAG-compliant keyboard, focus and screen-reader behaviour on an interactive media widget. Genuinely hard to retrofit.
• 13 languages. English, German, French, Danish, Spanish, Italian, Japanese, Korean, Dutch, Norwegian, Polish, Portuguese and growing.
• Schema and AEO. Structured data so the gallery is legible to AI search and answer engines, not just to human eyes.

The moving-target problem

If the feature surface were static, the build-vs-buy question would just be a one-time price comparison, and reasonable people could disagree on the number. It is not static. Every layer under the waterline is anchored to a platform you do not control, and those platforms change on a schedule that has nothing to do with your roadmap. A finished build does not stay finished. It starts decaying the day after you ship it.

Worth flagging: this is the part the build estimate almost never includes, because it is invisible at estimate time. Nobody budgets for the Instagram Graph API deprecation that has not been announced yet, or the Shopify theme architecture change two Editions away, or the privacy regime that turns a working consent flow into a liability. But those are not edge cases. They are the base rate. Here is a representative twelve months of the things that would have landed on your team's desk.

The true cost of ownership

Let me put numbers on it, with the honest caveat that the inputs are yours, not mine. The point is the shape of the maths, not a precise figure I could not defend.

A credible v1 of the platform under the waterline (not the grid, the platform) is a multi-quarter effort for a small team. Call it a conservative range of roughly 6 to 12 engineer-months to reach something you would put in front of paying customers with a straight face: ingestion for a few sources, a basic rights flow, moderation, a couple of layouts, checkout, and enough analytics to be honest. That is the build line. It is real, but it is the smaller number.

The line that dominates is maintenance. Industry research on software lifecycle cost has been consistent for decades: the majority of a system's total cost lands after the first release, not before it. Barry Boehm's foundational software-economics work and the IEEE/ISO maintenance literature put ongoing maintenance at well over half of total lifetime cost, and frequently in the 60 to 80 percent range across the life of a system. A platform anchored to ten third-party APIs and four moving external forces sits at the high end of that band, not the low end.

Translate that last figure. Half to one full engineer, forever, is not a project cost. It is a standing tax on your team's capacity, paid in the currency you have least of: senior engineering attention. And it is attention diverted from whatever your team is actually for, which for almost every merchant is not "maintaining social-media connectors".

Time to value, and the revenue you skip while building

There is a second cost that never shows up on the engineering estimate, and it is often the larger one: the revenue you do not earn while you are building. A bought gallery is live this week. A built one is live next quarter, if the estimate holds, and estimates on platform work anchored to third-party APIs do not hold.

Every week the built version is not live is a week the conversion lift it was meant to deliver does not happen. That forgone revenue compounds across the whole build window, and it is invisible because it never appears as a line item. It just shows up as a flatter curve than the one you could have had.

The risk you take on with the build

Cost and time are the measurable arguments. Risk is the one that tends to decide it, because the failure modes are the kind that do not show up in a sprint review and do show up in a board meeting.

• Legal and rights. A consent flow with a gap is not a bug, it is a liability with a customer's face attached. Getting rights wrong at scale is the expensive kind of wrong.
• Brand safety and moderation. A miss in the moderation layer puts something you would never have chosen next to your products, at the moment of purchase. The cost is trust, which does not have a refund.
• Performance regressions. A media-heavy widget is the easiest way to quietly wreck Core Web Vitals, and a slower store converts worse across every page, not just the gallery.
• Security. You would be storing customer media, handling OAuth tokens for ten platforms and processing consent data. That is a meaningful attack surface that is now yours to defend and patch.
• Key-person risk. The engineer who built it understands it. When they leave, the treadmill does not stop, but the person who knew how to run it does.

When building genuinely makes sense

Now the part a sales asset is not supposed to include, which is the reason I trust the rest of it more. There are real cases where building is the right call, and pretending otherwise is how you lose the credibility that the honest cases earn you.

Build when the gallery is your product, not a feature on it. If shoppable UGC is the wedge your whole company is built around, then it is your differentiation and your moat, and outsourcing your moat is a strategic mistake regardless of the maths. Build when you have genuinely unusual requirements that no platform serves and that are central to how you win, not merely preferences a configuration screen could meet. Build when the content and engagement data is itself the asset you are accumulating, and owning the full pipeline is the point. And build when you already have the team, the appetite and the standing capacity to carry the treadmill without starving the rest of the roadmap.

The third answer: hybrid

The build-vs-buy framing is a false binary, and the team that has thought hardest about it usually lands somewhere in between. You buy the platform, the part that is undifferentiated, expensive and never finished, and you build on top of it where you genuinely differentiate. You customise instead of starting from a blank repo.

That is why Idukki ships a REST API, an SDK and a headless mode. You let the platform carry the iceberg, ingestion, rights, moderation, performance, the ten connectors and the treadmill that comes with them, and you spend your engineering on the bespoke experience that is actually yours. You get the control that made building attractive without owning the maintenance that makes building expensive.

If you want to put numbers on your own version of this, do not take mine. Take the cost model to your own inputs. The savings calculator and the UGC ROI calculator let you model the build-vs-buy and the lift against your own traffic and team cost. And if hybrid is where you land, the developer docs are the place to start: the REST API, the SDK and headless mode are there precisely so you can build on top instead of from scratch.