The Numbers That Matter
Most community commerce SaaS founders I meet report 40-50% gross margins. They claim services work. Then I ask: how many unique customizations do you maintain? The answer kills the story.
A batch of five community commerce players I tracked over 18 months showed this pattern. Company A did zero custom work. They hit 70% gross margins at 800 merchants. Company B offered limited customizations. They peaked at 45% margins at 600 merchants, then growth plateaued. Company C embraced services. They hit 12 merchants with "custom" workflows before hiring their third engineer dedicated to implementation.
Services in community commerce aren't like enterprise SaaS. An enterprise deal justifies 6 weeks of engineering. A small merchant paying ₹5,000-₹15,000 monthly does not. You've instantly made yourself the bottleneck.
Why Community Commerce Attracts the Services Trap
Community commerce operators have messy, hyperlocal workflows. A spice merchant in Mumbai has different inventory needs than a textile seller in Surat. A group buying manager needs different unit economics than a direct-to-consumer aggregator.
This heterogeneity feels like it demands customization. It does not. It demands better product abstraction. The confusion between the two kills most early attempts.
Think of it like building infrastructure: you can lay custom pipes for every building, or you build a water main and let users tap in. The main is harder to design. Pipes look faster. They're not.
When Services Actually Help (The Bounded Window)
Services work in two scenarios, and only two.
Scenario 1: Onboarding as a feature. When you launch, you don't fully understand user workflows. Spending two weeks with your first 10 merchants teaches you their language. You return to product with concrete feature requests, not guesses. Cost: ₹2-3 lakhs total. Timeline: your first 6 months. Then you stop.
Scenario 2: Data migration only. Merchants have 3 years of inventory, customer lists, transaction history trapped in spreadsheets or legacy systems. You can't leave that data. Offering to migrate it—once, systematically—is a genuine service. It's also finite. You write one migration tool. It amortizes across 100+ customers. Cost per customer: ₹5,000-₹10,000, paid once.
Both are time-bound. Both feed back into product. Both have fixed scope.
The Timing Lens: India Stack Advantage
India Stack—Aadhaar, UPI, GSTIN—gives you a structural advantage. You can build payment routing, tax compliance, and identity verification into the core product. Competitors in Southeast Asia need to solve these at enterprise-sale-time. You don't.
But only if you stay focused on product. Custom services burn your best engineers on Jira tickets instead of leveraging India's infrastructure primitives. That's your actual moat. You're trading it for margin you'll never actually see.
The Red Flags
You're falling into the services trap if:
- Your implementation backlog is longer than your feature backlog.
- You've hired a "services lead" before you hit ₹10 crore ARR.
- You're writing SQL queries for customer-specific reports.
- Your CEO spends >20% of time managing a customer's workflow, not your product.
- You charge extra for features you could have built into the base product.
One or two of these? Maybe survivable. Three or more? You're not a SaaS company anymore. You're a consulting firm with a software wrapper.
The Founder Implication
If you're building community commerce SaaS, choose now: are you solving a product problem or a consulting problem? If it's truly a product problem, every merchant needs the solution the same way. Build it once, ship it to 5,000 users.
If it requires custom thinking per customer, you've built a services business. That's valid. It's just not SaaS. Margins cap at 40-50%, you can't scale without proportional headcount, and you'll never hit the returns that justify venture capital.
Your India Stack timing window is open for maybe 24 more months before regional competitors copy it. Spend it on product, not on being someone's bespoke software agency.