A seller holds a vintage jacket up to the camera. Viewers ask about its condition, inspect the details and place bids while the show continues. The winning buyer pays, the seller receives an order, and the marketplace tracks the shipment.
That short interaction brings together video streaming, real-time auctions, payments, inventory and customer support. If you want to understand how to build an app like Whatnot, start by planning how those parts work together.
For a startup targeting the United States, the strongest starting point is a focused marketplace: one audience, a manageable group of sellers and a purchasing experience buyers can trust. This guide explains the essential features, development costs, business model and launch decisions behind that approach.
How do you build an app like Whatnot?
To build an app like Whatnot, choose a product niche, define buyer and seller workflows, integrate live streaming, implement server-controlled bidding, connect marketplace payments and shipping, and build an admin dashboard. Launch with a controlled seller pilot before expanding. Under the assumptions in this guide, a custom MVP has an illustrative development budget of $60,000–$120,000 and a 20–28-week delivery plan.
Those figures assume cross-platform mobile development, managed video infrastructure, one launch market and a limited feature set. They exclude marketing, ongoing operating expenses and the cost of recreating an established platform’s full capabilities.
What is Whatnot, and how does a live shopping app work?
Whatnot is a marketplace built around live shopping, where sellers present products and buyers participate through viewing, conversation and purchases. Its model connects product discovery with a seller-led experience.
In its 2026 State of Live Selling Report, Whatnot reports that sellers generated $8 billion in live sales during 2025, more than double the previous year. These are company-reported platform sales, not Whatnot’s revenue or a forecast for a new marketplace.
For a new live commerce app, the core journey can be organized into six steps:
- Discover: A buyer finds a category, seller or scheduled show.
- Watch: The buyer joins a live broadcast and sees the featured product.
- Evaluate: Product details, condition and shipping information help the buyer decide.
- Purchase: The buyer places a bid or uses a fixed-price purchase option.
- Fulfill: Payment is confirmed, stock is updated and the seller ships the order.
- Resolve: Tracking, support and dispute handling remain available after checkout.
Every step needs a defined owner and a recoverable failure path. A successful bid with a failed payment should never leave the buyer, seller and support team seeing three different order states.
Choose a niche before planning the feature list
A marketplace needs enough relevant inventory and enough interested buyers at the same time. Launching dozens of categories immediately spreads seller recruitment, moderation and marketing resources thinly.
Start with a category where live demonstrations answer real purchase questions.
| Possible niche | Why live selling could help | Operational issue to validate |
|---|---|---|
| Vintage fashion | Buyers can inspect fit, fabric and condition | Consistent sizing and condition descriptions |
| Collectibles | Sellers can explain provenance and details | Authenticity and item grading |
| Home décor | Demonstrations communicate scale and finish | Fragile shipping and returns |
| Specialist hobby products | Knowledgeable sellers can answer questions | Category expertise and product restrictions |
Before development, interview prospective sellers and buyers. Ask sellers how they list products, pack orders and manage returns. Ask buyers what would persuade them to purchase from an unfamiliar seller.
Your early positioning should answer a concrete question: Why would this community buy and sell here? Exclusive inventory, specialist sellers or a better category workflow can provide a clearer answer than a longer feature list.
Essential features for a Whatnot-like app
Live shopping app development requires connected buyer, seller and administrator experiences. Define the responsibilities of each role before estimating screens or integrations.
Buyer features
Buyers need a clear path from discovery to delivery:
- Account creation, sign-in and profile settings.
- Category browsing, search and seller profiles.
- Scheduled shows, reminders and seller following.
- Live video with product details and moderated chat.
- Current bid, minimum next bid and clear auction status.
- Saved payment methods through a payment provider.
- Purchase confirmation, order history and shipment tracking.
- Reporting, blocking, support requests and refund status.
The bidding interface deserves particular attention. Display the amount the buyer is committing to and make shipping and tax treatment understandable. Show whether a bid is pending, accepted, rejected or outbid; an animation alone is not confirmation.
Seller features
Sellers need tools that support running a show and completing orders:
- Application, approval and payout onboarding.
- Product listings with photos, condition, quantity and shipping attributes.
- Show scheduling and a queue of featured products.
- Camera and microphone checks before broadcasting.
- Auction start controls and visibility into accepted bids.
- Fixed-price listings if included in the MVP scope.
- Paid-order lists, shipping labels and tracking updates.
- Commission breakdowns, payout status and support tools.
For the initial release, approve sellers manually and provide structured onboarding. A smaller group of dependable sellers makes it easier to identify problems before expanding access.
Admin features
The admin dashboard should help the operations team handle exceptions:
| Admin capability | Why it matters |
|---|---|
| Seller approval and suspension | Controls who can list and broadcast |
| Product and category moderation | Helps enforce marketplace rules |
| Live-show monitoring and termination | Gives moderators a response to reported broadcasts |
| Order, payment and payout lookup | Helps investigate missing money or failed purchases |
| Refund and dispute workflows | Makes resolution consistent and traceable |
| Commission configuration | Supports changes without manual recalculation |
| Staff permissions and audit history | Records who changed sensitive settings |
| Operational reporting | Highlights fulfillment delays and recurring failures |
These operational requirements belong in the original ecommerce development scope, because they affect the data model, payment integration and customer experience.
What should the MVP include?
A practical MVP should demonstrate that sellers can run shows, buyers can purchase reliably and the business can fulfill and support those purchases.
| Include in the initial MVP | Consider after validation |
|---|---|
| One country and currency | Multiple countries and currencies |
| One primary category | A broad category catalog |
| Single-host live shows | Co-hosting and guest broadcasts |
| One defined auction format | Multiple bidding formats and complex rules |
| Basic search and seller following | Personalized recommendation feeds |
| One marketplace payment integration | Multiple payment and payout providers |
| One shipping integration | Cross-border logistics and advanced routing |
| Basic analytics and manual moderation | Advanced automation and seller intelligence |
For this guide’s cost scenario, assume one mobile application with buyer and seller modes, a web admin dashboard, one shipping provider, basic fixed-price purchasing and a single ascending-bid auction format.
Avoid assuming that a feature described as “basic” has no edge cases. Combined shipping, partial refunds and inventory shared between live and fixed-price listings all need explicit rules.

How should live auctions work technically?
The auction service should make authoritative decisions about accepted bids, auction deadlines and winners. The phone displays those decisions and submits requests.
Suppose two buyers bid during the final second. The backend must process the competing requests consistently, accept or reject each request and produce one final result. The displayed countdown should reflect server time, and reconnecting devices should fetch the latest auction state.
An implementation plan should define:
- Whether late accepted bids extend the auction.
- How simultaneous bids are ordered.
- What happens when a bidder loses connection.
- Whether the seller can pause or cancel a lot.
- What happens if the winner cannot complete payment.
- How support retrieves the relevant event history.
Use durable records of accepted bids and auction outcomes. Design retries so that repeating a request does not create a second bid, duplicate order or additional payment.
Video latency also matters. A viewer may see a delayed product demonstration while the auction service is already processing newer events. Test the complete interaction on real mobile networks and make the authoritative bid state visible independently of the broadcast.

Recommended technology stack
The following is a proposed stack for a new product. It is not a description of Whatnot’s private infrastructure.
| Layer | Example choice | Responsibility |
|---|---|---|
| Mobile app | React Native or Flutter | Buyer and seller interfaces on iOS and Android |
| Admin dashboard | React or Next.js | Moderation, orders and marketplace management |
| Backend | Node.js with TypeScript | Accounts, listings, auctions and business rules |
| Transaction database | PostgreSQL | Orders, accepted bids and financial records |
| Cache and event delivery | Redis and WebSockets | Fast updates, transient state and live notifications |
| Video infrastructure | Amazon IVS or a comparable managed service | Live ingest and viewer playback |
| Marketplace payments | Stripe Connect or another suitable provider | Seller onboarding, payments and payouts |
| Media storage | Object storage and a CDN | Product images and permitted recordings |
| Background processing | Managed queues and workers | Notifications, reconciliation and shipping tasks |
| Monitoring | Centralized logs, metrics and alerts | Detect failures and investigate incidents |
Amazon IVS provides managed low-latency streaming capabilities. Evaluate streaming modes, device support, recording and pricing against your actual viewing pattern.
Stripe Connect provides tools for platforms and marketplaces moving money between multiple parties. Confirm business eligibility and select the charge and payout model before building financial workflows.
Cross-platform development can share a substantial portion of application code, but video SDKs and device behavior still need platform-specific testing. Appther’s React Native development services can be explored when evaluating that approach.
If you are also comparing video business models, read our guide to building an app like ReelShort. Recorded entertainment and live commerce have different playback, interaction and monetization requirements.
How much does it cost to build an app like Whatnot?
A useful Whatnot-like app development cost estimate begins with deliverables and effort. The scenarios below use an illustrative blended delivery rate of $30–$40 per hour. This is a modeling assumption, not a market average or a confirmed Appther rate.
| Product stage | Illustrative effort | Illustrative budget | What it covers |
|---|---|---|---|
| Feasibility prototype | 300–500 hours | $9,000–$20,000 | Key screens, sample streaming and simulated buying flows |
| Focused custom MVP | 2,000–3,000 hours | $60,000–$120,000 | Mobile buyer/seller experience, auctions, payments, shipping and admin |
| Expanded platform | 4,000–6,500 hours | $120,000–$260,000 | Broader workflows, integrations, analytics and scale hardening |
Each range represents total effort for that stage’s scope, not an incremental upgrade price. A prototype is not ready to process public marketplace transactions.

For an illustrative 2,400-hour MVP, effort could be allocated as follows:
| Workstream | Hours |
|---|---|
| Discovery, requirements and solution design | 160 |
| UX/UI design and interactive prototype | 220 |
| Mobile buyer and seller experiences | 620 |
| Backend, auction logic and administration | 620 |
| Streaming, payment and shipping integrations | 280 |
| QA, security checks and performance validation | 300 |
| Release preparation and delivery coordination | 200 |
| Total | 2,400 |
At the assumed hourly range, this example produces a development budget of $72,000–$96,000.
The scenarios exclude taxes, marketing, seller acquisition, legal services, third-party subscriptions, ongoing cloud usage, ongoing support staffing and post-launch feature development. Separate native apps, demanding concurrency targets, custom streaming infrastructure or complex cross-border workflows can materially increase the budget.
A detailed estimate should also name the client responsibilities: approved designs, seller rules, payment-provider accounts, shipping agreements, test products and timely acceptance feedback.
What are the ongoing costs of a live shopping platform?
Monthly active users alone are not enough to estimate operating costs. Ten thousand users who watch briefly create a different video bill from ten thousand users watching daily.
Build the operating model around measurable usage:
| Cost category | Main drivers |
|---|---|
| Live video | Broadcast hours, viewer-hours, quality, geography and recording |
| Application infrastructure | Concurrent activity, database load and availability targets |
| Payments | Transaction volume, payment methods, payouts and disputes |
| Storage | Product images, recording retention and backups |
| Messaging | Verification messages, email and notification usage |
| Support and moderation | Live coverage hours, case volume and response targets |
| Maintenance | Monitoring, fixes, SDK updates and release frequency |
| Acquisition | Seller recruitment, promotions and buyer acquisition |
For example, 40 shows × 1.5 hours × 100 average concurrent viewers = 6,000 viewer-hours. Separately, the same shows create 60 broadcast hours. Apply the selected provider’s current rates to the appropriate usage categories, then add recording and related services.
This calculation is a workload example, not a vendor quote. Model an expected case and a higher-usage case before selecting your pricing and commission structure.
Whatnot’s business model and monetization options
A marketplace business model must explain who pays, what the fee covers and when the platform earns it.
Whatnot charges selling commissions and separate payment processing fees. Its current seller fee documentationdescribes rates that vary by market, category and sales tier. A universal flat-rate claim would therefore be misleading. Review the live rate card when comparing seller economics.
For your own platform, consider the following options. These are proposed business models, not a list of features currently sold by Whatnot.
Commission on completed sales
Charge a percentage of eligible merchandise sales. Define the commission base, refund treatment and whether payment processing is deducted separately.
A transparent fee statement should show the item amount, applicable platform fee, other deductions and expected seller payout.
Seller subscriptions
Offer optional tools such as advanced reporting, bulk listing or team access through a paid plan. Introduce subscriptions when sellers can see repeatable value; early sellers may resist paying before the marketplace produces orders.
Promoted shows and listings
Allow sellers to pay for clearly labeled visibility. Build relevance and quality checks into placement decisions so that promotion does not undermine product discovery.
Optional business services
Operational services such as photography or specialist onboarding may create additional revenue where the business can deliver them economically. Validate demand before building them into the product roadmap.
Understand revenue versus profit
Consider an illustrative month:
| Metric | Example |
|---|---|
| Completed orders | 8,000 |
| Average merchandise value per order | $45 |
| Merchandise sales volume | $360,000 |
| Assumed platform commission | 8% |
| Gross commission revenue | $28,800 |
This is hypothetical arithmetic, not a forecast or Whatnot’s actual economics. The commission revenue still needs to cover any platform-paid processing, streaming, support, refunds, fraud losses, incentives and operating expenses.
Monitor contribution margin alongside gross merchandise value. High sales volume does not automatically produce a sustainable marketplace.
Trust, payments and launch requirements
A buyer’s willingness to purchase depends on more than a smooth broadcast. Clear product information, seller accountability and dependable support should be part of the launch plan.
Require consistent condition descriptions and prohibit misleading listings. Give users reporting and blocking tools, and ensure moderators can act on a live show. Define cancellation, refund and seller enforcement procedures before the first public transaction.
For a US launch, obtain appropriate review of privacy, tax, seller verification, consumer protection and any category-specific auction obligations. The requirements depend on the business model and jurisdictions involved. A payment integration does not resolve every marketplace obligation.
Use payment-provider components to handle sensitive card information, restrict staff access and retain an audit history of financial actions. Reconcile payment and payout events with internal order records rather than relying on the user’s checkout screen alone.
Apple’s App Review Guidelines distinguish physical goods consumed outside the app from digital purchases and include requirements for user-generated content. Map each monetization flow to applicable store rules, especially if the platform also sells digital seller tools. Prepare working review accounts and keep production services available during review.
How long does development take?
For the focused MVP described above, use 20–28 weeks as an illustrative delivery plan, assuming a small multidisciplinary team, parallel workstreams and timely decisions.
| Phase | Planning window | Main outcome |
|---|---|---|
| Discovery and feasibility | Weeks 1–3 | Scope, rules, integrations and risk decisions |
| UX and technical validation | Weeks 3–6 | Tested user flows and integration prototypes |
| Development | Weeks 6–18 | Mobile app, backend, admin and integrations |
| Integration and hardening | Weeks 16–23 | Payment, auction, recovery and load validation |
| Seller pilot and release | Weeks 22–28 | Operational feedback and launch readiness |
The windows overlap and should not be added together. Store review, provider approval, scope changes and client feedback can affect the launch date. Validate streaming and payment feasibility early because they influence the rest of the system.
How to launch and measure the MVP
Recruit a small group of approved sellers before opening to a broad audience. Run scheduled shows in one category and keep support available during each session.
The pilot should test normal purchases and difficult cases: an interrupted broadcast, a rejected bid, a failed payment, a refund and a delayed shipment. Confirm what each participant sees and how the operations team resolves the issue.
Track a compact set of metrics:
- Percentage of approved sellers who complete a first show.
- Viewers who become first-time buyers.
- Repeat purchases within a defined period.
- Successful payment completion after an auction win.
- On-time shipment rate and support cases per order.
- Contribution margin per order and per show.
Expand after the team understands the causes behind those numbers. Seller attendance, inventory quality and fulfillment reliability deserve as much attention as application downloads.
Where can AI add value?
AI can assist with product descriptions, category suggestions, support summaries and flagging content for review. Add these capabilities when they solve a measured operational problem.
Keep pricing commitments, auction winners and payment states deterministic and auditable. Product authenticity should not be presented as established merely because an AI model assigned a favorable score.
If AI fits the roadmap, Appther’s AI development services provide a relevant starting point for discussing data requirements, evaluation and human review.
Frequently asked questions
How much does it cost to build a live shopping app like Whatnot?
In this guide’s scenario, a focused custom MVP costs $60,000–$120,000, based on 2,000–3,000 hours at an assumed $30–$40 hourly rate. Actual pricing depends on scope, team rates and integrations. Ongoing operation and customer acquisition are separate expenses.
Can I start with a smaller budget?
Yes. A prototype or managed-platform pilot can validate seller interest and buying behavior before custom development. Reducing categories, integrations and auction formats also reduces scope. Payment reliability, basic moderation and clear order handling still need to work before a public transactional launch.
What is the difference between a live shopping app and a regular marketplace?
A live shopping app adds broadcasts, real-time conversation and potentially live auctions to marketplace functions. It still needs product listings, checkout, fulfillment, payouts and support, with additional attention to synchronization and live moderation.
Should I build native apps or use React Native?
React Native can support a shared iOS and Android codebase. Separate native apps may suit requirements needing deeper platform control. Validate your streaming SDK, broadcasting experience and device performance before making the decision.
Do I need custom video streaming infrastructure?
Not necessarily. A managed streaming provider can reduce the initial infrastructure scope. You still need to integrate access control, playback, broadcast recovery, moderation and usage monitoring with the marketplace application.
How does an app like Whatnot make money?
A live shopping marketplace can earn commission on eligible sales and potentially charge for optional seller tools or promoted placements. Whatnot’s published commission rules vary by market, category and sales tier, so use its current documentation for exact comparisons.
Can I build a marketplace inspired by Whatnot?
You can plan an original product around live commerce workflows, with distinct branding and implementation. Have qualified advisers review intellectual property and relevant marketplace obligations. This guide does not imply an affiliation between Appther and Whatnot.
Build your live shopping app with a clear plan
Start with the marketplace you can operate well: a defined audience, reliable sellers, understandable auction rules and a complete path from purchase to delivery.
Appther offers mobile app development for businesses targeting the USA. Bring your target category, seller model and launch goals to a planning discussion so the development scope can reflect your actual business needs.






