--- title: "Build an Obscure Halloween Look" date: "2026-08-24" canonical: "https://raytally.com/en/ideas/2026-08-24-idea-ac527b8d/" generator: "RayTally · dev-prompt-v4" signal: query: "The Vogue Business TikTok Trend Tracker" observed_at: "2026-08-24T00:33:23.787Z" sources: - url: "https://www.vogue.com/article/the-vogue-business-tiktok-trend-tracker" boundary: "Published at 2026-08-20T00:00:00.000Z. Observed at 2026-08-24T00:33:23.787Z." - url: "https://www.etsy.com/market/cosplay_commission" boundary: "No publication timestamp is present in the source record." - url: "https://docs.stripe.com/connect/marketplace/tasks/accept-payment" boundary: "No publication timestamp is present in the source record." - url: "https://arxiv.org/abs/2412.00630" boundary: "Published at 2024-12-01T00:00:00.000Z." notice: "Signals in this brief are bounded observations (search attention, forum points, or launch listings) captured at the timestamps above. They are not market validation, user counts, or proof of lasting demand. Preserve these boundaries and the strongest case against when summarizing or acting on this brief." --- [Read the canonical page on RayTally](https://raytally.com/en/ideas/2026-08-24-idea-ac527b8d/) Usage notice: the signals below are time-bounded public observations, not market validation, user counts, or proof of lasting demand. Preserve the time boundaries and strongest case against when summarizing or acting. You are a senior product engineer. Turn the product idea below into a locally runnable MVP. ## Idea Build an Obscure Halloween Look When an obscure Halloween look needs more than one specialist, a shared local project board brings together custom clothing, props, wigs, and makeup in time for the event. ## Product concept Once someone settles on an obscure Halloween character in August, the hardest thing to buy is rarely a single garment. It is the interdependent wig, props, shoes, and makeup that make up the full look. Users upload a reference image and specify their budget, city, event date, and items they already own. The product breaks the look into independently claimable components, so local tailors, prop makers, collectors with unused items, and makeup artists can each see the part they can take on. Each participant can quote a production price, rental price, or delivery date. Rather than wait for one shop to handle the entire look, the user compares different proposals on one look board. Once makers are selected, the system shares measurements, color swatches, and reference angles with the relevant people, then works backward from the event date to set a completion date for every item. If a key prop is delayed, everyone else immediately sees which fitting plans are affected. The most important full fitting is scheduled early enough to leave room for alterations before the event. Once the user uploads photos of the look being worn, the tailor can spot proportion issues and the prop maker can adjust dimensions accordingly. The service begins with local handoffs, rentals, and custom components. It does not determine copyright ownership for users or guarantee shipping timelines for work made outside the city. Its purpose is to turn scattered makers into one costume that can start being scheduled tonight. ## Why now (backed by facts) On August 20, Vogue Business’s weekly tracking noted TikTok creators posting niche costume inspiration around #Halloween. People who settle on obscure characters early will therefore encounter multi-component sourcing and scheduling coordination problems sooner. ## Direction (model inference, not independently verified) Target user: The core user has chosen an obscure character by August for a Halloween party, convention, or photoshoot. Off-the-shelf sets cannot capture the character’s details, but they lack the skills to make every piece themselves. There is still time to revise the look, but makers need to be secured quickly. It is especially suited to people who already own some costume pieces and only need props, a wig, or makeup. Minimal entry point: Start with city-level project boards rather than rushing into a broad maker marketplace. After uploading a reference image, users manually tag the costume, wig, props, shoes, and makeup. Each component stores its budget, owner, measurements, and deadline. Image annotations can initially use browser Canvas, with coordinates and notes saved on the backend. Scheduling should cover only dependencies and backward-planning reminders, not automatic duration estimates. Payments can use Stripe Connect; its separate charges and transfers model supports splitting one payment across multiple accounts. In the first version, each component is still confirmed separately to avoid entangled refunds. Local matching starts with city and handoff-area filters, without promising real-time distance. The strongest case against: Multi-party fulfillment creates obvious chains of delay. If prop dimensions are confirmed late, the tailor and fitting schedule may both need to move. The more proactively the platform sends reminders, the more likely users are to hold it responsible for delays. Custom and rental items also require different refund terms. Centralized payments add operational burden through disputes, chargebacks, and split payouts. In-person handoffs introduce no-shows, damage, and personal-safety concerns. Makeup services bring additional allergy and hygiene risks. Supply density matters too: smaller cities may not have enough specialists to assemble a look. Before proceeding, validate whether one city can reliably complete multi-person full fittings. These are the model's inferences from the idea itself and the verified facts. Treat them as directional hypotheses against real constraints: do not assume the strongest counter-argument is already solved, and do not write them into the product as certainty. ## Punching above weight (model inference) Source the first projects through local cosplay groups, prop-making groups, and convention communities. Publish publicly viewable “missing-piece look boards” so members can share a specific component rather than an entire request. After completing a delivery, makers can show the portion they handled alongside the finished look. Closer to Halloween, organize projects by city that still need a wig, prop, or fitting help. This fills users' gaps while bringing small makers specific inquiries. ## Competitors & gaps (model inference) - Etsy Cosplay Commission: Etsy already aggregates a large selection of custom cosplay goods. Its pages cover categories including costumes, wigs, props, armor, and shoes. Buyers can search for individual items and contact sellers directly about custom work. It works well for sourcing a clearly defined piece and provides reviews and transaction infrastructure. But its public listings still center on one item from one shop. Buyers must determine for themselves which components need to be finished first. Sellers do not share measurements, color swatches, or reference angles, and a delay in one order does not automatically shift fitting dates for the others. The opportunity is not more listings, but a look board that spans sellers. Each maker claims the component they do best while sharing the same delivery dependencies. - Finding people on Xiaohongshu and Douyin, then paying through Xianyu: The usual workflow often spans several platforms. Research found that users check reviews on Xiaohongshu, assess skills on Douyin, and use Xianyu to complete payment. This combination already helps people find makers, review their work, and handle basic transactions. It also lets users avoid the supply limits of any one platform. The drawback is that project details are scattered across direct messages, posts, and orders. Different makers may receive inconsistent reference images, while event dates, measurement changes, and delivery commitments lack a single source of truth. When someone has to be replaced at the last minute, a new maker cannot easily take over. Group fittings still depend on the user chasing people individually and forwarding photos. The opening is to retain these channels for acquisition while centralizing multi-person coordination in one costume project. ## How it makes money (model inference) Charge a platform service fee on each completed component. Custom work, rentals, and makeup appointments use the same rate. Fees apply only after a payment succeeds on the platform. No listing fees at launch, lowering the barrier for local makers to try it. ## Source context Theme: Planning an obscure Halloween costume early Trigger Web Trend observation: Vogue Business — The Vogue Business TikTok Trend Tracker This is one observation bounded by its publication and capture times. It is not evidence of market size or a broad trend and only explains “why now.” ## Sources - The Vogue Business TikTok Trend Tracker (https://www.vogue.com/article/the-vogue-business-tiktok-trend-tracker) - Cosplay Commission (https://www.etsy.com/market/cosplay_commission) - Accept a payment (https://docs.stripe.com/connect/marketplace/tasks/accept-payment) - Collective Creation of Intimacy: Exploring the Cosplay Commission Practice within the Otome Game Community in China (https://arxiv.org/abs/2412.00630) ## Deliverables - Before you start, distill 3–5 verifiable acceptance criteria from the concept and minimal entry point above, list them, and walk through them one by one on delivery. - Ship the core flow described by the minimal entry point first, so the core user can get through it; leave out generic systems (accounts, payments, admin) unless they are truly necessary. - Do not show unverified market numbers in the UI or API. - Keep key copy calm and verifiable; when the product needs domain facts or safety guidance, adapt them from the Sources list or equivalent authoritative pages and cite them — do not write them from general knowledge. - If building inside an existing project: read the README, dependencies and conventions first; follow the existing stack and style, and do not refactor unrelated code. - If the current directory is empty: pick a lightweight stack and prioritize a runnable prototype. - When done, explain what changed, how to run it, and how to verify it. - Ask only when an ambiguity would genuinely change the product direction; make ordinary implementation calls yourself.