Bag Sampling for Indiegogo: A Cross-Platform Prototype Strategy

What changes when the platform is Indiegogo

A bag is a bag regardless of where it is funded, so it is tempting to assume the sampling plan is identical across platforms. It is not, and the differences are structural rather than cosmetic. Three of them change what a creator should build and when: the funding model, the post-campaign behaviour of the platform, and the audience composition. Each affects the sample set, the specification and the re-order plan.

The funding model is the first. Kickstarter operates on a fixed model where a campaign either reaches its goal or collects nothing, which makes the production decision binary: the campaign funds, or it does not. Indiegogo offers flexible funding, where a campaign keeps whatever it raises whether or not it reaches the goal. That changes the risk profile of committing to production, and it changes what a creator needs to know before the campaign opens.

The post-campaign behaviour is the second and the most consequential for sampling. Indiegogo InDemand allows a campaign to continue taking orders after the initial period closes, which turns a campaign from an event into a channel. A bag that continues selling needs a production plan that continues, and continuous production needs a specification and a pattern file that stay stable for months rather than weeks.

The audience composition is the third. Indiegogo has historically carried a stronger international visitor mix and a stronger tech and hardware orientation than some other platforms. For a bag campaign that usually means more questions about shipping regions, voltage-free accessories, regional compliance and delivery estimates to specific markets. Each of those is answerable, and each is cheaper to answer during sampling than during fulfilment.

None of this makes one platform better than the other, and the point is not to choose. The point is that a cross-platform plan has to be built deliberately, because the prototyping programme produces artefacts that both pages then depend on, and an artefact built for one campaign model does not automatically serve another.

Flexible funding and what it means for sampling

Flexible funding is the single biggest planning difference, and it cuts both ways. The advantage is that a campaign is not all-or-nothing, so a creator can take a smaller first production run and grow. The risk is that a campaign can close below its goal with an obligation to deliver a smaller number of units than the economics were built around, at a unit cost higher than the plan assumed.

That risk lands squarely on the sampling plan, because the minimum applies regardless of how the campaign funded. At 500 pcs per style and per colourway, a campaign that raises enough for 300 units still faces the same minimum structure. The honest planning move is to know the number before the campaign opens rather than after it closes.

The row that deserves attention is the third. A flexible campaign that closes below goal has a real obligation to deliver what was sold, and the unit economics of a small quantity are worse than the plan assumed. Creators in that position often discover that the sampling investment was made against a volume that never arrived, which is why sampling decisions should be made against the minimum rather than against the stretch.

The practical implication for sampling is to spend on the artefact rather than on the units. A well-built specification, a verified pattern file and a retained approved reference hold their value regardless of how many units are eventually made. An elaborate sample set built for a volume that never arrives does not. Our campaign bag specialist steers flexible-funding creators toward the first kind of spending for exactly that reason.

There is a second implication, which is about timing. Under a fixed model the production decision happens on one date. Under a flexible model it happens over a period, and a creator may be deciding whether to produce while the campaign is still running. Having the sampling finished and the quotation valid before the campaign opens converts that from a crisis into a decision.

InDemand: the sampling case for continuous production

InDemand is the feature that most changes the shape of a bag programme, because it converts a campaign into an ongoing sales channel. A bag that continues selling after the campaign closes needs a production plan that continues, and continuous production puts a different set of demands on the sampling artefacts than a one-off run does.

The first demand is stability. A one-off run can be built against a sample and a conversation, because the people involved remember the decisions. A run that repeats over nine months cannot, because memory fades and staff change. Continuous production needs a written specification at a numbered revision, a stored pattern file, and a retained physical reference. Those three are what make run four identical to run one.

• A written specification at a numbered revision, stored and reopened for every run.
• A pattern file with the marker and the component list, versioned and archived.
• A retained physical reference unit, plus a counter sample held by the production side.
• Material references recorded, including whether each is stock or custom.
• Decoration files and position coordinates stored with the specification.
• Packing and carton data recorded, so freight planning does not restart each time.

The second demand is re-order economics. A continuing campaign produces irregular order quantities, and each re-order is a production run with its own minimum structure and its own window. Understanding the minimum before the first run, rather than discovering it at the second, is what keeps an InDemand tail profitable rather than merely busy.

The third demand is on the page itself. An InDemand page is read by people who missed the campaign and are buying as though from a store, which means their expectations are retail rather than crowdfunding. They expect the item to exist, to ship on a stated date, and to match the photograph. That expectation is met by having a physical pre-production unit photographed and a delivery estimate built on the actual 35-50 day window rather than on optimism.

There is also a marketing consequence worth planning for. A continuing page can be updated, and the updates that convert best are photographic proof: a shot of the production run, a shot of packed cartons, a shot of the inspection process. Building those into the asset plan from the start means the content exists when it is needed rather than being improvised.

One prototype, several channels

A bag campaign rarely ends at the campaign. The same bag typically goes on to a Shopify store, a marketplace listing, a retail conversation or a corporate order, and each channel wants a slightly different thing from the prototype. Building the prototype programme so it serves all of them costs little extra and saves a second development round later.

The retail row is the one creators regret most. A buyer conversation that arrives six months after a campaign needs a sample, and if the sample was shipped as a reward there is no unit to show. Retaining one unit from the programme, and keeping the specification sheet presentable, costs nothing and is the difference between a retail conversation and a missed one.

Marketplace preparation is the second. A barcode and a fulfilment SKU identity applied during packing at origin cost a fraction of the same label applied at a destination warehouse, and the carton and cube data recorded at pre-production is what the warehouse needs to plan. Both are decisions made during sampling that only become visible months later.

The lesson is to treat the prototype as a one-time asset with several audiences, and to capture everything at the moment it is cheap. One shoot, one specification, one retained unit and one recorded carton serve every channel. Re-deriving any of them later costs more than capturing them cost in the first place, and the bundles and kits guidance shows the same principle applied to accessories.

How many sample units each channel needs

Sample counts are where cross-platform plans most often go wrong, because each channel consumes units and nobody counts the consumption in advance. A prototype is not just one bag. It is a set of units with different destinations, and the set has to be planned before the first one is built or the programme will run short at the moment it needs a unit most.

1. Development prototype: one, built to test the design, usually consumed by feedback and revision.
2. Photography unit: ideally the same as the prototype, shot before it is marked up.
3. Approved pre-production unit: one, retained rather than shipped, as the physical reference.
4. Counter sample: one, retained by the production side, matched to the retained unit.
5. Salesman samples: one or more, ordered inside the lot if they will be shipped or shown.
6. Retail or buyer sample: one, retained for the conversation that arrives later.
7. Media or reviewer units: allocated deliberately, because they count toward the 500.

The counting rule that catches people out is the last one. A unit that is finished and packable counts toward the minimum, so media units, reviewer units and replacement stock are all part of the 500 rather than additions to it. Allocating them before the purchase order is written is the difference between a planned programme and a shortfall discovered in public.

A useful allocation for a cross-platform campaign, offered as an illustration rather than as a fixed ratio, might be 400 saleable reward units, 30 InDemand reserve units, 20 marketplace launch units, 12 media and reviewer units, 8 retained and counter samples, and 30 replacement and warranty units. That totals 500, and the right split depends entirely on the channel mix and the warranty promise rather than on any rule.

The second counting rule concerns colourways. Each colourway carries its own 500-pcs minimum, and each needs its own sample and its own approval. A cross-platform campaign showing three colours is three sample tracks and three commitments, not one track with three outcomes. Presenting two of them as pre-priced re-order options is usually the more fundable plan.

Two pages, one specification

Running the same bag on two platforms means two pages with two audiences, and the failure mode is drift. One page gets updated and the other does not, or one page promises a detail the other quietly dropped after a sampling revision. Six months later the two pages describe different bags and neither matches what ships.

• One numbered specification, referenced by both pages, updated only by revision.
• A single claim register: every measurable promise listed with its verified value.
• One image library, with renders and photographs clearly separated and shared between pages.
• A single owner for page accuracy, named rather than assumed.
• A change rule: any specification revision triggers a check of both pages.
• One delivery estimate, built on the same production window, stated identically.

The claim register is the tool that makes this work, and it is a ten-minute document. List every measurable promise the campaign makes: capacity in litres, laptop size, weight, dimensions, pocket count, material name, closure type, colourway names. Beside each, record the verified value from the approved unit. When a specification revision changes a value, the register shows which page claims need editing.

The change rule is what enforces it, and it is the part most often skipped. A revision agreed in an email with one person does not reach the second page unless someone is responsible for checking. Naming that person, and making the check a step in the revision rather than an afterthought, is what keeps two pages honest across a long campaign.

There is also a platform-specific reason for the discipline. Both platforms treat the campaign page as a promise to backers, and a discrepancy between two pages describing the same product is the kind of thing that attracts a complaint rather than a question. Our programme coordinator raises the register check at every revision for cross-platform campaigns, because it costs minutes and protects both pages.

Regional variants and market-specific requirements

Cross-platform campaigns frequently sell into more than one region, and regional requirements are the most common source of late, expensive changes. Three categories matter for a bag: labelling and marking, documentation, and physical variants. Each is cheaper to resolve during sampling than after production, and each is a question the creator can ask at brief stage.

Labelling is the category that costs the most when it is late, because it affects finished units. A label applied at origin is cheap; the same label applied to 500 finished bags at destination is a manual rework with a handling cost per unit. Confirming label artwork and position during sampling, against the requirement for each destination market, is one of the highest-value checks in the whole programme.

Documentation is the second and it is about timing rather than cost. Compliance documentation for a destination market should be on file before the lot ships, because a shipment held at customs costs more than the documents and delays the delivery promise made on the page. Asking what documentation each market needs during sampling is a single question with a long tail of protection.

Physical variants are the third and the most strategic. A variant is not a colourway: a different strap length for a regional preference, a different label language, a different accessory included in the bundle. Each variant is a change to the specification and potentially to the minimum, and each should be decided during sampling rather than discovered as a marketplace requirement later.

Re-order maths when a campaign never closes

A campaign with an InDemand tail, or with a store behind it, re-orders. The arithmetic of re-ordering is different from the arithmetic of a first run, and understanding it before the first run prevents the most common disappointment: a second run that is more expensive per unit than the first and takes longer than expected.

The first difference is the minimum. A re-order is a production run and carries the same structure as any other run, at 500 pcs per style and per colourway unless something different was agreed in writing. A creator re-ordering 200 units to cover a strong month is not placing a 200-unit order, they are placing an order that meets the minimum, and the surplus becomes inventory.

The second difference is material. If the first run used a stock colour, the re-order probably can too. If it used a custom dye, the mill minimum applies again, and the re-order may need to be larger than the demand to make the material purchase viable. Recording whether each material is stock or custom during sampling is what makes re-order maths predictable.

• Ask whether each material reference is stock or custom before the first run.
• Confirm the re-order minimum in writing at the same time as the first order.
• Record the pattern revision number used for run one.
• Keep the retained reference unit for comparison against run two.
• Plan the re-order window as 35-50 days, not as a fast top-up.
• Budget for the deposit structure on every run, at T/T 30/70.

The third difference is the window. A re-order is a production run, not a restock, and it takes the same 35-50 days as the first one. Creators running an InDemand tail sometimes treat a re-order as a fast top-up and promise delivery dates built on that assumption, which is how a continuing campaign acquires a delivery problem it did not have during the campaign itself.

The fourth is inspection. Each run is inspected at AQL 2.5 to ISO 2859-1 against the approved reference, and the approved reference is the retained unit from the first programme. That is the mechanism that makes run four comparable to run one, and it only works if the unit was retained and the file was kept current.

The shared pattern file as single source of truth

Everything in this article converges on one artefact: the pattern file with its specification, materials, marker and revision history. For a single-platform one-off campaign, a good sample and a clear email can carry the programme. For a cross-platform campaign with a continuing tail, only a file can, and the file is what makes every later decision cheap rather than expensive.

The file carries five things that no email chain does. The shapes and tolerances, which define fit. The material references, which define cost and re-order feasibility. The component list, which defines sourcing. The decoration files and coordinates, which define brand consistency. And the revision history, which explains why the bag is the way it is.

Keeping it current is a discipline rather than an expense. Each revision, each material substitution and each decoration adjustment should be recorded in the file with a reason. Six months later, when a re-order is being quoted and somebody asks why the pocket depth changed, the file answers in seconds. Without it, the answer is a conversation and a guess, and the quotation is built on whichever recollection is most confident rather than on what was agreed.

Our team opens every cross-platform programme by establishing the file and naming its revision, and closes every run by updating it. That habit is what allows a campaign to move from a crowdfunding page to an InDemand tail to a store without a second development round, and it is the reason the CAD development stage is worth doing properly the first time.

Timelines that span two platforms

A cross-platform plan has more dates than a single-platform one, and they interact. The sampling window feeds the launch date, the launch date feeds the production decision, the production window feeds the delivery promise, and the delivery promise feeds the InDemand tail that may trigger a re-order. Mapping them once, in one document, prevents the most common failure: a re-order promised before the first run has shipped.

The staggered second launch is worth planning deliberately. Launching on a second platform a few weeks after the first means the second page can carry photography of a physical unit rather than renders, which usually converts better. It also means the second audience is reading claims that have already been verified on a real bag, which reduces the promise risk.

The re-order row is the one that breaks plans. A campaign that launches in month one, ships in month four and sees a strong InDemand tail in month five will place a re-order that arrives in month seven. Promising month six delivery to those buyers is promising something the production window cannot deliver, and the correction is a public update rather than a private one.

Building the whole sequence into one document before launch, with each duration stated as a range rather than as a single figure, is the planning habit that prevents that. Ranges absorb variance; single figures do not, and a campaign built on single figures will miss one of them.

A cross-platform sampling plan

Putting it together, a cross-platform bag programme needs a sampling plan with six decisions made before the first unit is built. None of them is expensive, and each one that is deferred becomes a conversation later at a worse moment.

1. Decide the minimum structure in writing, at 500 pcs per style and per colourway, and which colourways are funded versus pre-priced re-orders.
2. Decide the sample set: development, photography, retained reference, counter sample, salesman, retail and media units, with the allocation counted against the lot.
3. Decide the material status of every reference: stock or custom, and what a custom choice means for re-order feasibility.
4. Decide the claim register and verify each claim against the approved unit before either page goes live.
5. Decide the regional requirements: labelling, documentation and any physical variant, resolved before bulk packing.
6. Decide the file discipline: revision numbering, storage, and who updates it after each run.

Then execute one sampling track rather than two. One prototype, reviewed properly against a written specification, photographed once, approved once as the reference, and retained. Two platforms do not need two prototypes, they need one prototype and two honest pages.

The commercial frame stays the same throughout: production 35-50 days from deposit and approved sample, deposit and balance under T/T 30/70, trade terms at FOB Xiamen, and the finished lot inspected at AQL 2.5 to ISO 2859-1. Cross-platform changes the planning, not the mechanics, and a creator who separates the two will find the whole programme easier to run.

The final point is the one that matters most for a campaign that never quite closes. A continuing campaign is a business rather than an event, and businesses run on files rather than on conversations. Build the file during sampling, keep it current through every run, and the second year is easier than the first.

Frequently Asked Questions

People Also Ask