A client came to me with a 2K marketplace built on Blink.new. It looked decent in screenshots. Then I ran an audit and it scored a D-. Not a C-minus, not a D. A D-minus. Sixty-plus bugs, broken payment flows, zero security hardening, and a Discord integration that did nothing useful. The entire thing needed to be rebuilt from scratch.
Three phases and ten deployment rounds later, Holy Services went from that D- audit to the number one 2K marketplace in its niche. This is the build log for how it happened.
The D- Audit
When I say the MVP was a D-, I mean it systematically. I use a scoring rubric across categories: functionality, security, UX, performance, code quality, and deployment readiness. Here's what I found.
The payment flow was the worst offender. The Stripe integration was half-implemented. Charges would go through but there was no verification on the backend. A user could modify the price in the frontend, submit a lower amount, and the system would accept it. No webhook validation, no server-side price checks, no receipt generation.
The authentication was Discord OAuth in name only. It redirected to Discord, got a token, and stored it in localStorage. No session management, no token refresh, no scope validation. Anyone who grabbed the token from their browser could impersonate any user by swapping values in storage.
The database had no indexes, no foreign keys, and several tables with columns that weren't being used. Queries were N+1 patterns everywhere. The listings page made 47 database calls to load 12 items.
CSS was inline styles mixed with Tailwind classes mixed with a CSS file that overrode both. Some pages looked fine on desktop and completely broke on mobile. Buttons overlapped. Text overflowed containers. The cart page had a scrollbar inside a scrollbar.
I documented all 60+ issues, categorized them by severity, and gave the client a simple recommendation: rebuilding from scratch would be faster and cheaper than fixing this MVP. They agreed. We started the next day.
Phase 1: Foundation and Payments
The first phase was about getting the fundamentals right. A clean Next.js codebase, proper database schema, and a payment system that actually works.
For payments, I built a Stripe escrow system using separate charges and manual transfers. Here's why. The marketplace connects buyers with sellers (called grinders in the 2K community). The buyer pays for a service. The grinder delivers. Then the payment gets released. Stripe's standard destination charges seemed like the obvious choice, but they don't give you enough control over the release timing.
With separate charges, the flow works like this: the buyer's payment creates a charge on the platform's Stripe account. The funds sit there until the order is marked complete. Then a manual transfer sends the grinder's cut to their connected account. If there's a dispute, I can freeze the transfer before it goes out. With destination charges, the money moves immediately and disputes become refund nightmares.
I also added Cash App Pay through Stripe. This was a specific request from the client. The 2K community skews young, and a lot of these users don't have credit cards. They have Cash App. Stripe's Cash App Pay integration handles this natively. No separate Cash App API, no manual payment verification. It flows through the same Stripe checkout and gets the same webhook confirmations.
The previous MVP had a "manual cash" option where the buyer would send money on Cash App and then tell the seller they paid. You can imagine how many disputes that caused. Replacing that with Stripe-managed Cash App Pay eliminated an entire category of fraud.
Phase 2: Discord Integration
A 2K marketplace without Discord integration is dead on arrival. The entire community lives on Discord. Every buyer, every seller, every moderator. The website is where transactions happen, but Discord is where trust is built.
I built a full Discord bot that connects to the marketplace database. When a new order is created on the website, the bot creates a private ticket channel in Discord. The buyer and seller can communicate there. Order status updates are posted automatically. When the order is complete, the bot prompts for a review.
Discord OAuth handles authentication. But unlike the MVP's broken implementation, this one actually works. The OAuth flow uses the authorization code grant (not implicit), exchanges the code server-side, stores the access and refresh tokens in an encrypted session, and validates scopes. The user's Discord ID becomes their identity across both platforms.
I also built a verification system. New members go through a verification flow that checks their Discord account age, server join date, and whether they've completed at least one transaction. Verified members get a role that unlocks higher-value service categories. Unverified members can browse but can't buy services above a certain price threshold.
Loyalty tiers came next. Bronze, Silver, Gold, Diamond. Based on total spend and number of completed orders. Each tier unlocks perks: priority matching with top grinders, reduced platform fees, exclusive service categories. The tiers sync between the website and Discord. When a buyer hits Gold on the website, the bot automatically assigns the Gold role in Discord.
Phase 3: Security and Anti-Abuse
This is where most marketplace builders cut corners. Security isn't fun, it doesn't look impressive in a demo, and clients rarely ask for it by name. But without it, the first serious abuse incident will destroy your platform's reputation overnight.
Anti-nuke protection was the first thing I built. Discord servers get nuked (mass-deleted channels, mass-banned members, mass-role changes) more often than you'd think, usually by a compromised admin account or a rogue moderator. The bot monitors for bulk destructive actions. If it detects more than 3 channel deletions, 5 role changes, or 10 bans within a 60-second window, it locks down the server: revokes all admin permissions except the owner, posts an alert in a hardcoded emergency channel, and logs everything for review.
Rate limiting went on every API endpoint. I used a sliding window approach: 30 requests per minute for authenticated users, 10 per minute for unauthenticated. Payment endpoints get stricter limits (5 per minute) because those are the high-value targets. The rate limiter returns a Retry-After header so well-behaved clients know when to try again.
Custom slash commands handle the operational side. /order status [order-id] lets buyers check their order without opening the website. /grinder stats shows a grinder's completion rate, average delivery time, and rating. /report [user] opens a moderation ticket with pre-filled context. /payout history shows a grinder's recent transfers. Every command validates permissions before executing.
I also built an auto-moderation layer that scans messages in service channels for common scam patterns. Things like "pay me directly on Cash App" or "let's take this off the platform" or sharing external payment links. When detected, the message gets flagged (not deleted) and a mod is pinged. False positives are common enough that auto-deletion would be too aggressive. Human review is the right call here.
The Marathon Session
Phase 2 was a marathon. One session, ten deployment rounds, fixing bugs as fast as they appeared. The client was testing in real time on their phone while I was pushing fixes. We'd find a bug, I'd fix it, deploy, they'd test, find another bug, repeat.
Some highlights from the bug log:
- The mobile nav menu opened but wouldn't close. A z-index conflict between the menu overlay and the cart drawer.
- Stripe webhooks were failing silently because the endpoint was checking for the wrong event type. It was listening for
checkout.session.completedbut the Cash App Pay flow sendspayment_intent.succeeded. - Discord role sync was hitting a rate limit because it was trying to update all members at once on server startup. Batched it to 5 updates per second.
- The order confirmation email was sending the grinder's email to the buyer and vice versa. A variable swap that made it past code review.
- Image uploads for service listings were working in dev but failing in production because the upload endpoint had a 1MB limit in the production nginx config.
Sixty bugs across ten deploys. Each deploy got cleaner. By round 8, we were finding edge cases, not fundamental breaks. By round 10, the client was using the platform to process real orders.
Why Rebuilding Beat Fixing
I get asked this a lot. Why not just fix the MVP? It had some working pieces. Why throw it all away?
Because the cost of fixing bad architecture exceeds the cost of building good architecture. The MVP's database schema couldn't support the escrow flow. The authentication system couldn't be patched into something secure. The frontend code was so tangled that changing one component broke three others. Every fix would have been a workaround stacked on top of another workaround.
Rebuilding took three phases over a few weeks. Fixing the MVP would have taken longer because every fix requires understanding the existing code, figuring out what it was trying to do, and then working around its assumptions. With a rebuild, I set the assumptions myself.
The rebuild also gave us a clean codebase that the client can maintain and extend. The MVP would have been a permanent maintenance burden. Every new feature would have required archaeology to figure out where it fits. The rebuild is documented, tested, and structured for growth.
From Zero to Market Leader
Holy Services launched and immediately started processing orders. The combination of proper escrow, Cash App Pay, Discord integration, and a clean UI gave it an edge that no other 2K marketplace in the niche had. Competitors were still running manual Cash App payments and using Discord DMs for order management.
Within weeks, Holy Services was the market leader. Not because of marketing spend or influencer deals. Because the product was better. Buyers trusted the escrow system. Grinders liked getting paid through Stripe instead of chasing Cash App payments. The loyalty tiers created retention. The Discord bot made the community feel alive.
Going from a D- audit to a market-leading position validated something I believe strongly: the quality of your infrastructure is a competitive advantage, especially in niches where everyone else is hacking things together with no-code tools and manual processes.
The full case study breaks down the architecture in more detail. If you're building a marketplace or need a platform with Discord bot integration, get a free estimate.