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
Did your investors push you toward enterprise or was it internal?
Rankfender
@owen_simmons Internal. Investors just asked "what's your enterprise strategy?" We panicked and made one up.
@imed_radhouani That panic driven strategy shift is way more common than people admit
What did your best customers actually say during that phase?
Rankfender
@sadie_perry They asked for reliability. Faster load times. Fewer bugs. We ignored them and built SSO. Stupid.
@imed_radhouani that says everything, they told you exactly what mattered and it wasn't SSO
were you tracking demand signals or just acting on intuition
Rankfender
@levi_ross Intuition! That was the mistake. Now we track usage data, support tickets, and churn signals. No guessing.
@imed_radhouani That shift from intuition to signals is the real unlock
How do you now decide what not to build
Rankfender
@sarah_butler1 If we can't tie it to retention or churn, we don't build it. Simple rule now.
@imed_radhouani That's a strong filter, if it doesn't impact retention it's just noise
Rankfender
@sarah_butler1 Exactly. Noise is the enemy. Every feature request sounds important when someone is asking. But most of them don't move the numbers that matter.
We have a second filter now too: would anyone notice if we never built this? If the answer is no, we don't build it.
What's your filter for cutting through the noise?
This is one of the most honest post-mortems I've read on enterprise go-to-market. Your rule of "no enterprise features until someone from an enterprise pays us first" is something I wish more founders internalized early.
I'm building an enterprise AI platform right now and the single biggest lesson I've learned is that enterprise sales is fundamentally a trust-building exercise, not a feature-building exercise. The first enterprise customers we closed didn't care about SSO or audit logs — they cared that we sat with their team for two weeks understanding their workflows before writing a single line of custom code.
Your data table showing SSO (4 requests, 2 actual users) vs. API rate limits (47 requests, 89% adoption) is the clearest illustration I've seen of the gap between what sounds enterprise-ready and what actually drives retention.
One thing I'd add: the compliance gap you mention (SOC2, GDPR, data residency) is often what kills enterprise deals silently. Buyers go dark not because they lost interest — they go dark because legal killed the deal internally and nobody tells you. We learned to ask about procurement and compliance requirements in the very first discovery call, before even doing a product demo.
Really appreciate the transparency on the $415K cost. Most founders don't quantify the opportunity cost of features they didn't build, but that's often the biggest number on the sheet.
Rankfender
@vishnu_nc You're absolutely right about the silent compliance kill. That's the one that hurts the most because you never see it coming. The buyer is excited. The product is a fit. Then legal gets involved and the deal goes dark. No explanation. No feedback. Just silence. You wait for weeks, then months, then you realize it's dead.
We learned to ask about compliance on the first call too. "What does your security review look like? Who needs to sign off?" If they can't answer, it's a red flag. If they say "legal reviews everything," you ask to meet legal before the demo. If they say no, you move on.
The trust-building piece you mentioned is the thing we underestimated. Enterprise buyers don't buy features. They buy confidence that you won't break their workflow, lose their data, or disappear in a year. That confidence takes time. It takes transparency. It takes showing up to meetings where nothing gets decided.
Your point about sitting with their team for two weeks before writing code is the right approach. We did the opposite. We built first, then tried to sell. That's why we failed.
What's the most surprising compliance requirement you've run into that almost killed a deal?
That's why they write in the big books, you need to make your analysis, you need a problem. Without analysis, personas/target groups, and a specific annoying problem it is pure gamble if the product will succeed. Good analysis will stop you before you do anything big.
Unfortunately, when they teach us to become a software development, they don't teach as entrepreneurship, and a little bit of marketing, and a lot of software developers (like me), just fail. They think it is great, they are full with confidence, because they know what to do (from technical perspective), and at the end, it fails.
Most startups start like this. Building something for a customer that don't exists, hoping that somebody will come from somewhere and use it. ;)
Rankfender
@stoyan_minchev You're right. And this is the part nobody teaches.
In school, they teach you how to write code. How to architect systems. How to make things fast and scalable. They don't teach you how to figure out if anyone actually wants what you're building.
So you learn the technical side. You get good at it. You build confidence. You think "I can build anything."
Then you build something. And nobody comes.
Not because the code is bad. Because you never asked if anyone needed it. You just assumed.
The analysis piece is the part that feels like work. It's not fun. It doesn't feel like progress. Writing code feels like progress. Talking to customers feels like slowing down.
But that "slow" part is the only thing that separates a product from a science project.
Most startups fail for exactly this reason. Not because they couldn't build it. Because they built the wrong thing. And they didn't know it was wrong until after they'd spent months building it.
The gamble you're talking about is real. You roll the dice. You hope. Most of the time, you lose.
But the fix is simple. It's just not easy. You have to talk to people before you build. You have to find the specific problem that annoys them so much they'll pay to fix it. You have to know who they are, what they've tried, why it didn't work.
That's the analysis. That's the work that matters. Everything else is just implementation.
What's the most expensive "nobody asked for this" thing you've built Stoyan?
@imed_radhouani
10-15 years ago, a Car Expense Tracker. We did not ask anybody, we built it, we got 3 downloads :)
Then startups, where I was working as contractor. Great ideas, big plans, a lot of money spent, no clients, same as you. They don't exist anymore.
We also need to keep in mind the communication channels and the way we worked were different in the pass. 10 years ago, I did not know such things like Product Hunt and its alternatives existed at all. The world is more opened for new ideas now.
Rankfender
@stoyan_minchev Three downloads. That's brutal but also kind of beautiful in a sad way. You built something, put it out there, and three people found it. That's the purest form of "nobody asked for this."
The contractor experience is real too. You watch someone else make the same mistake. Big plans. Big budget. No customers. You know how it ends. But you're not the one making the call.
You're right about the world being more open now. Product Hunt didn't exist. Indie Hackers didn't exist. You couldn't just post something and have thousands of people see it. You had to find forums, buy ads, get lucky.
Now there's no excuse. You can validate an idea in a weekend. Post a landing page. Run a small ad. Talk to 10 people on a call. If nobody cares, you move on.
But most people still don't do it. Because it's uncomfortable. Because building feels safer than asking.
What would you build differently today with what you know now, just curious (and learning in the same time ;) ) ?
@imed_radhouani
I am planning to release my own project soon, in the area of monitoring elderly people living alone.
This is the path I followed:
I know that the AgeTech is a big market. I did a SWOT analysis. The first time I did it, it was not the right time for my ideas. The technologies were not giving the cutting edge I was searching for;
I waited for a few years. I was checking forums, concurrents, what they offer, why, what I can do better;
I checked and I identified my target group: Elderly people that live alone, but still believe that they don't need help, but their children are concerned. The elderly people don't like being checked in frequently, Don't like new gadgets (wearables), Find cameras too intrusive. Can't deal will technologies, and can't do a video call, write a message or start an application. Which leads to the important basis: "Install and forget" principles. Children install it fast and easy and do nothing more.
Having the idea, the basis, the technologies, the identified concurrency and persona, then came the architecture/implementation;
I learned also to be patient and slow. Being in a hurry does not give good results. IT will just move the errors in the future, but it will not save time. Serious deeds require time and patience;
You can't do everything with AI. My marketing strategies had a bad bad start. We have discussed this with you in another thread. Too early, bad suggestions by the AI. I will definitely do it differently next time;
When you do your homework, the most easy thing is the implementation;
Listen to people, try to be helpful;
It is difficult to make the difference between promotion and convince people that it is not about the money, it is about helping people, and in order to help them, they need to know that such application exists ;)
I would build differently the marketing strategy. I wasted so much time with things that did not work.
And a lot, a lot more things, many of which pure technical ;)
I relate to this a lot. For me, the lesson was simple: build for the people already paying. Every time I ignored that, I paid for it. One suggestion I’d add, maybe test “enterprise demand” with manual services first before building features. It’s slower but way cheaper than six months of engineering time.
Rankfender
@dalhat_usman That's the smarter path. Manual services first. Do the thing manually before you automate it. You learn what actually matters. You get paid to learn. And you avoid six months of building the wrong thing.
We did the opposite. We automated first. Assumed we knew what they needed. Built features nobody asked for. Spent months on it.
The manual version would have been one person, two weeks, a few customer calls. We would have learned that nobody wanted SSO yet. We would have saved $400k.
Why did you choose the manual route first?
The "listen to your users" lesson hits differently when you've built privacy-first with no accounts and no backend. I'm building SelfOS - a consumer life planner. I genuinely can't reach my paying users. No emails, no IDs, nothing. All I have is App Store reviews and the occasional email someone sends voluntarily.
So I'm stuck doing the opposite of what you describe - shipping things based on what I observe publicly and what I'd want myself. No way to validate before building.
How would you approach product decisions when you have zero direct access to your users?
Rankfender
@virtualviki Tough spot. I'd use App Store reviews like user interviews. Reach out to everyone who writes one. Track anonymous behavior inside the app. And ship small. Watch what works. You're not blind. Just different sensors.
For me, the biggest learning is about timing. Enterprise is not wrong, but it felt like you tried to jump there too early. I have seen product grow naturally into that space, and it looks very different when customers pull you instead of you pushing in.
Rankfender
@rakesh_gupta20 Exactly. Enterprise should pull you. We pushed. That's why it failed!!
That comparison between SSO vs API rate limits says everything. 47 requests vs 4 and still building the wrong thing. Happens more often than people admit.
Rankfender
@filxa_adam Happens all the time. Loud requests win over quiet votes. We learned to look at usage, not just voices.