We spent 6 months building for enterprise. Nobody bought it.
We thought we were ready.
Bigger deals. Fewer customers. Better margins. That was the dream.
So we built enterprise features. SSO. Advanced permissions. Audit logs. A whole new pricing tier starting at $2,000/month.
We spent 6 months. Three engineers. One dedicated product manager. Endless meetings about "enterprise readiness."
We launched the tier. Sent emails to our biggest users. Ran LinkedIn ads targeting "Head of IT" and "VP of Infrastructure."
Zero.
Not one signup.
Not even a demo request from an enterprise account.
The real cost
Let me put numbers on it.
Cost category | Amount |
|---|---|
Engineering time (3 people × 6 months) | $180,000 |
Product management | $60,000 |
Marketing (ads, content, emails) | $25,000 |
Opportunity cost (features we didn't build) | ~$150,000 |
Total | $415,000 |
That's what we spent to learn we were wrong.
What we thought we knew
We assumed enterprise customers wanted the same things as our small business users, just more of it. More security. More control. More features.
We never talked to them. We read blog posts. We looked at competitor pricing pages. We guessed.
Here's what we missed:
Procurement cycles. Enterprise deals take 6-12 months. We had 30-day sales cycles. We weren't built for that.
Security reviews. We needed SOC2. We didn't have it. Customers asked. We said "coming soon." They moved on.
Implementation. Enterprise buyers don't sign up and start using it. They need onboarding, training, account managers. We had none of that.
Compliance. Data residency. GDPR. HIPAA. We had nothing. Every deal died in legal review.
We weren't an enterprise company. We were a small SaaS with a big ego.
What the data said
We went back and looked at our own analytics.
Feature | Build time | Customer requests | Actual usage after 3 months |
|---|---|---|---|
SSO | 8 weeks | 4 requests | Used by 2 accounts (both internal) |
Audit logs | 6 weeks | 2 requests | 0 accounts |
Enterprise tier | 10 weeks | 0 requests | 0 signups |
API rate limits | 4 weeks | 47 requests | Used by 89% of power users |
The features nobody asked for took 24 weeks to build. The feature 47 people asked for took 4 weeks. We built the wrong things because we were chasing a dream, not data.
What we learned
1. Customers don't ask for enterprise features until they're ready to pay enterprise prices.
The 4 requests for SSO came from users on our $89/month plan. They weren't enterprise buyers. They just thought SSO sounded cool.
2. The features you imagine are always wrong.
Every enterprise feature we built was based on assumptions. Every assumption was wrong. We should have talked to 10 real enterprise buyers before writing a line of code. We didn't.
3. Your current customers are your roadmap.
The feature 47 people asked for? API rate limits. Not sexy. Not enterprise. But it solved a real problem for our power users. We built it in 4 weeks. Adoption was 89%.
What we did instead
We killed the enterprise tier. Dropped the price back down. Spent the next 3 months fixing the things our actual users were complaining about.
Fix | Time spent | Impact |
|---|---|---|
API rate limits | 4 weeks | 89% adoption among power users |
Faster load times | 3 weeks | 22% drop in support tickets |
Simpler onboarding | 2 weeks | 34% increase in activation rate |
Churn dropped from 8.2% to 5.7%. Referrals went up 41%. Revenue grew 18% without a single enterprise deal.
What this means for you
If you're thinking about building enterprise features, ask yourself three questions:
1. Have you talked to 10 enterprise buyers who are not already your customers?
If not, stop. You're guessing.
2. Do you have the compliance, security, and procurement infrastructure to support enterprise deals?
If not, you're not enterprise. You're just expensive.
3. What does your data say about what your current users actually need?
We ignored the 47 requests for API rate limits. We built SSO instead. That was stupid.
The honest truth
We wanted to be an enterprise company because it sounded impressive. Big logos. Big checks. Big validation.
But we weren't ready. And instead of admitting that, we wasted $415,000 learning a lesson we could have learned in a week of customer calls.
Now we have a rule: no enterprise features until someone from an enterprise pays us first. Not asks. Pays.
What I'm curious about
Have you ever built something for a customer you didn't have? How much did it cost you? What did you learn?
Imed Radhouani
Founder & CTO – Rankfender
Evidence over ego. Retention over requests.
Replies
This hits close to home. We went through something similar. Built what we thought was the right feature set, then jumped on discovery calls and realized enterprise buyers cared way more about where their data lives than what the AI could actually do. Data sovereignty, not model capability, was the #1 thing. That one insight basically forced us to rethink our entire architecture. Anyone else been surprised by what enterprise buyers actually prioritize vs what you assumed?
The honest thing underneath this story is that enterprise wasn't really a revenue strategy — it was a validation strategy. Big logos feel like proof that the product is real. The mistake is treating customer aspiration as customer research. You didn't need ten enterprise deals. You needed one honest conversation with someone who actually had to get a vendor approved.
Spot on. The part that failed first was not talking to the market. We often feel that our ideas are right, and it’s okay to, but you do have to speak with the customer or client first. I’m glad you figured out the issues, and I am hoping to see another launch soon.
@ryanwmcc You're right. The "feeling that our ideas are right" is the dangerous part. Confidence feels good. It feels like progress. But it's just noise until someone pays you.
We were so sure. We had the roadmap. We had the engineering team. We had the belief. We just didn't have the conversation.
The funny thing is, talking to customers isn't hard. It's just uncomfortable. You have to hear "no." You have to hear "that's not a problem for me." You have to hear "I wouldn't pay for that." It's easier to stay in the cave and build.
But the cave is where products go to die.
Thanks for the kind words. We learned the hard way. Next launch is already in the works — smaller scope, more customer conversations, less guessing.
What's the most important conversation you almost skipped?
How do you know you’re solving an enterprise problem, not just adding features?
@beena_sharma If no one from an enterprise pays you first, you're not solving an enterprise problem. You're just adding features.
Appreciate you putting numbers on the mistake. The opportunity-cost framing is especially useful because teams usually undercount it.
After you killed the tier, what was the first smaller-customer feature you shipped that clearly moved retention or revenue?
@luca_arditoAfter we killed the enterprise tier, the first feature we shipped for our smaller customers was API rate limits.
It took 4 weeks to build.
47 customers had quietly requested it.
89% adoption among power users.
And retention stopped dropping the month after we shipped it.
Not sexy. Not a landing page feature. But it kept people around.
@imed_radhouani the best thing about this message is that "quietly".
sometimes, user aren't loudly asking for a new feature, but yet they are waiting for it
@luca_ardito Exactly. The quiet ones are the ones you should listen to. They're not posting in forums or tweeting at you. They're just using the product every day. And when something doesn't work, they don't complain. They just leave.
The 47 requests for API rate limits weren't loud. They were support tickets. Occasional DMs. A comment here and there. No one was pounding the table. But the signal was consistent.
Now we track "quiet requests" separately. Volume is low. But frequency over time tells you what actually matters.
@samir_tout Appreciate you sharing that. The app-gold-rush days were brutal. Everyone was building, nobody was asking. Same mistake, different decade.
The "we keep learning" part is the thing that saves you. The founders who stop learning are the ones who keep making the same expensive mistakes. You're not one of them.
What's the most important thing you learned from those days that you still use now?
Very helpful. Is that the lesson that one shouldn't bother with enterprise unless you have SOC2 and compliance layer in place?
@michael_zhang20 Not exactly Michael. The lesson is that you shouldn't bother with enterprise before you have SOC2 and compliance, not "unless."
Here's the difference.
"Unless" implies it's optional. Like maybe you can find a few enterprise customers who don't care. Maybe you can close deals without it. Maybe you can figure it out as you go.
You can't.
Every enterprise prospect we talked to asked about SOC2. Every single one. The ones who didn't ask upfront? They asked later. And when we said "in progress," they went silent.
"Before" is the real lesson. You need SOC2 and compliance in place before you talk to enterprise buyers, not after. Not "we're working on it." Not "coming soon." Done.
Here's what that means in practice:
SOC2 Type II takes 6-12 months. Start the process before you need it. Not when you lose a deal because you don't have it.
Legal review takes another 2-3 months. Data processing agreements. Subprocessors. GDPR compliance. Have them ready.
Procurement cycles take 6-12 months. That's the sales cycle. You can't add compliance on top of that. You need to be ready when they are.
So the real lesson is: enterprise is a timing game. You need to have the compliance layer in place before the buyer is ready to sign. If you start the compliance process when you get your first enterprise lead, you're already too late.
We started when we got the lead. We lost the deal. That's the mistake.
What's your timeline looking like for SOC2? Have you started?
@imed_radhouani Interesting. I am clearly new here. What's your definition of enterprise?
@michael_zhang20 Fair question. For us, enterprise meant companies with 500+ employees, formal procurement processes, legal reviews, and security requirements. The kind of customer who can't sign a contract without their SOC2 checkmark.
But honestly, the line is blurry. Some 50-person companies act like enterprises. Some 5,000-person companies act like startups.
The real signal isn't headcount. It's whether they ask for SOC2, data processing agreements, or a security review before they'll talk pricing. If they ask, you're in enterprise territory. If they don't, you're not.
@imed_radhouani Another thing we do - We don't create ideas to pitch to our customers. We only work on pain points that our potential customers have. In other words, we only build when there is a customer. It does sound like a dev shop. haha. But usually what we do for one customer gives us insights on what other customers also want. That's our nascent approach in trying to identify a key problem that is big enough for the whole industry. I guess then we will need to have a full SOC2 compliance team - hopefully soon (or until there is a SOC2 in a box application - which is also very possible with AI).
@imed_radhouani To answer your question - we have started SOC2 process internally. We believe starting with a small team actually creates a culture that makes compliance down the road easier. We have been working with large organizations (large enough for us), maybe they are not "enterprise" enough by definition.
This is a painful but very real lesson, especially the part about building for a customer you don’t actually have.
What stood out to me is how the real signal was already there (47 requests vs 0), but it still got ignored because it didn’t feel important enough. I think a lot of teams fall into that trap.
Curious, after this, how are you now capturing and prioritizing user feedback? Is it mostly coming from support/requests, or do you have a more structured way of seeing patterns across users?
@okiri_donald You're right. The signal was there. 47 requests. Quiet, consistent, easy to ignore because nobody was yelling. We just didn't want to see it.
Now we have a structured process. Three sources.
1. Support tickets. We use RAISA to cluster every ticket by theme automatically. No more guessing what people are actually complaining about. The largest cluster gets fixed first.
2. Usage data. We track what features power users touch every day. Not what they ask for. What they actually do. That's the real signal.
3. Churn signals. We look at the last feature someone used before they cancelled. That tells us what broke, not what they wish we had.
We don't prioritize requests anymore. We prioritize patterns. One person asking loudly means nothing. 47 people asking quietly over six months means build it.
What's your system for separating signal from noise?
@imed_radhouani That shift from “requests” → “patterns” is really interesting.
Feels like most teams get stuck at seeing what users say or do, but not when their mindset actually changes.
Like:
– when someone goes from exploring → relying on a feature
– or from “this is useful” → “I’d actually pay for this”
That moment seems way more predictive than raw usage or tickets.
Curious, have you found a way to actually capture that transition, or are you inferring it from behavior after the fact?
I’ve been experimenting with structuring flows specifically around that moment (instead of just tracking usage), and it’s been giving very different signals.
Happy to share what I’m seeing if useful.
This is one of the most honest and valuable founder posts I’ve read in a while.
The biggest lesson here is that assumptions are incredibly expensive. Building for the customer you want instead of the customer you have can drain months of focus and budget.
What really stands out is the contrast between 47 real requests for API limits vs months spent on enterprise assumptions. That’s such a powerful reminder that data and direct conversations should always beat ambition alone.
We’re seeing the same principle while building our AI learning workflows — real user needs and actual use cases always shape the roadmap better than imagined personas
@absheikh Thanks for this!! The "customer you want vs customer you have" line is the whole thing. We kept building for who we wished would buy, not who actually did. That's expensive.
The API limits vs enterprise thing still haunts me. The data was right there. Quiet, consistent, real. But it wasn't exciting. It wasn't something you put on a landing page. So we ignored it.
The imagined personas trap is real. You spend weeks building a profile of the perfect customer. Then you build for them. Then they never show up. Meanwhile, the customers you actually have are quietly telling you what they need. You just have to listen.
What's the most surprising thing real users have told you that your personas got wrong?
The part I find most useful here is naming the opportunity cost. A lot of teams can admit a feature failed, but not many quantify what they stopped learning while building it.
Did you notice any early signal, even a weak one, that in hindsight should have pushed you back toward SMB sooner?
@luca_ardito Yes. The early signal was the silence. Not a loud no. Just nothing.
We launched the enterprise tier. Sent emails. Ran ads. Zero signups. Not one. That was the signal. But we told ourselves "enterprise deals take longer." We were wrong. Silence is not a maybe. It's a no.
The other signal was our own usage. Our team didn't use the enterprise features. Not once. If your own people won't touch it, why would anyone else?
We quantified the opportunity cost later. $400k. That number hurts. But it's useful. Now every feature request gets a "what are we not building?" question attached.
What's the quietest signal you've ignored that cost you?