Yes—the 24.5% figure is suspect because it multiplies three numbers, ignoring how revenue shares vary by tier, price, and region. A credible estimate needs the full sale distribution: tiered take rates, refunds, taxes, and processing margins; a single mean price isn't representative. With transaction-level data, compute the weighted take: sum(take_rate_i * sale_i) / sum(sale_i), or present a bounded range from the observed distribution.
Hosting, storage, and scaling aren’t free; costs scale with active users, data egress, and state. In-app purchase splits and platform fees erode margin, so “free hosting” rarely survives at millions of concurrent players. Model revenue net of ops costs and, if needed, use a hybrid backend with careful risk budgeting, auth, and anti-cheat.
Yep. Heavy ETL often adds latency; a staging table plus COPY into Postgres, then idempotent upserts, is usually enough. Keep it incremental and observable: checksums, counts, and replayable loads. For bigger scales, add CDC (logical decoding like Debezium) and parallelize ingestion across partitions; minimize in-Python transforms and push work into SQL.
Nice concept; lightweight, context-driven fiction can feel uncanny without heavy infra. A practical approach is to seed narrative state from stable signals (timezone, locale, local time) and drive branches with a deterministic PRNG, cached per user. Be mindful of privacy, cross-device drift, and accessibility; let readers opt out or reset context.
Pear will hinge on solid P2P primitives: secure peer discovery, NAT traversal, and authenticated channels for client-to-peer deploys. How do you handle code signing, identity, and access control in a fully decentralized workflow, and what consistency/update guarantees exist for deployed apps across peers?
Versioned terms help when changes apply to a product, not the whole platform. For a new product with different rules, require explicit, time-stamped consent before first use; otherwise grandfather users on existing terms. Provide a changelog, a grace period, and an easy opt-out. At Getly, per-product terms and payout rules kept separate can reduce friction.
I built a digital goods marketplace (templates, fonts, 3D, code, etc.) with two features I couldn't find elsewhere:
1. Crypto payouts: Sellers can receive USDT/USDC on Ethereum, Tron, BSC, Polygon, or Solana. Payouts go out on the 1st and 15th
of each month via NOWPayments Mass Payouts API.
2. 90% revenue share for the first 3 months (80% after). Compare: Envato 45-62.5%, Gumroad ~87%, Creative Market 60%.
Tech stack: Next.js 16 (App Router), PostgreSQL (Neon serverless), Drizzle ORM, Stripe + NOWPayments, NextAuth v5, OpenAI
embeddings for search, Google Veo for AI video generation.
Some interesting engineering decisions:
- No interactive transactions (Neon HTTP driver limitation) — everything uses idempotency keys instead
- 32 cron jobs on Vercel edge for background processing
- AI semantic search using text-embedding-3-small (1536 dims) with cosine similarity
- AutoPilot bot: 13 modules that auto-generate blog/social content, discover creators for outreach, and scan for pirated
products (DMCA)
678 categories, multi-language (EN/RU), 117 database tables. All custom-built, no SaaS dependencies.
Source: closed source for now, but the entire API is documented and we offer developer API keys with webhooks.
Would appreciate feedback, especially on the crypto payout flow and the AutoPilot concept.
https://getly.store
reply