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
Curious whether one paid enterprise pilot would have changed the outcome, or if the operational gaps still would have killed it anyway.
@reid_anderson3 One paid pilot would have helped, but I think the operational gaps would have killed it anyway.
We didn't have SOC2. We didn't have a legal review process. We didn't have onboarding for large teams. A pilot would have exposed all of that faster. Maybe we would have learned earlier. But we still would have been unprepared.
The real problem wasn't the lack of a pilot. It was assuming we could figure it out as we went. Enterprise buyers don't want to figure it out with you. They want you to already have it.
What's the smallest enterprise deal you've seen expose the biggest gaps?
How early do you think a team can realistically tell whether they are actually enterprise ready versus just enterprise curious?
@miles_anthony2 Honestly? Within the first three customer conversations.
If you talk to five enterprise buyers and they all ask about SOC2, data residency, or procurement cycles, you're not ready. If they ask for custom onboarding or SLAs, you're not ready.
Enterprise curiosity is when you nod along and say "we can build that." Enterprise ready is when you already have it.
For us, we were curious for 6 months. We kept saying "we'll get SOC2 soon." We didn't. The buyers could smell it.
You're enterprise ready when the blockers are gone, not when you promise to remove them.
What's the earliest signal you've seen that a team is just curious?
@imed_radhouani The idea of "ready vs curious" is interesting because it suggests the decision point isn't really about feature completeness but about whether the product can survive the first real procurement conversations.
In a way, readiness isn't something you declare internally, it's something the buyer forces you to prove or fair quickly.
@miles_anthony2 Exactly. You don't declare yourself ready. The buyer decides. And they decide fast.
The first real procurement conversation exposes everything. If you stumble on SOC2, they're gone. If you can't explain data residency, they're gone. If you say "we're working on it" more than once, they're gone.
Readiness isn't a milestone you hit internally. It's a bar the buyer sets. You either meet it or you don't.
The curious teams keep talking about what they'll have. The ready teams just have it.
@miles_anthony2 @imed_radhouani The buyers have to discover before they decide. When they discover, and decide that your product is not______???? do they every come back and look again? put whatever you like in the blank, maybe ready, maybe needed whatever it is.
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.
@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. ;)
@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.
@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 ;)
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?
@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.
This hit hard. “We were a small SaaS with a big ego” is such an honest line. Appreciate you sharing the numbers too—most people wouldn’t.
@advin_jadis Thanks. The ego line was the hardest to write. But it's true. We thought we knew better. We didn't.
Nex
This is painfully relatable. The instinct to build enterprise features before having enterprise customers is one of the most common traps I have seen in B2B SaaS. The features themselves are not the problem. The problem is treating them as a growth strategy instead of a retention tool. Enterprise features work when existing customers are actively asking for them because they need SSO or audit logs to get through their own procurement process. Building them speculatively, before anyone is blocked on buying, is essentially a six month bet that supply creates its own demand. It almost never does. Appreciate you sharing this so openly. The lesson about talking to 50 potential buyers before writing a single line of code is one a lot of teams need to hear.
@najmuzzaman Exactly right. The features aren't the problem. The timing is.
We treated enterprise features like a growth strategy. Build it and they will come. That's not how it works. Enterprise features are retention tools for customers who are already paying you and need to check a box to keep buying.
Nobody was blocked on buying. Nobody asked for SSO. We just thought it sounded impressive.
The "supply creates demand" line is perfect. It almost never works. But we believed we were the exception. We weren't.
Thanks for putting it this clearly.
I feel like that kind of problems partially are solved in a book that is called "The Mom Test: How to talk to your customers".
From my experience I did spent 6 months building app in solo for invoicing, I thought it was useful, but I kinda burned out of it and stopped. Now working on completely different project, not event IT related
@vladyslav_yanishevskyi The Mom Test is a great call. That book should be required reading before anyone writes a line of code. The core lesson is the same: stop asking people what they want. Ask them what they actually do. The first is noise. The second is signal.
The solo invoicing app story is familiar. You build something you think is useful. You spend months on it. Then you realize nobody asked for it. Burnout hits because you were pushing a boulder uphill for no reason.
Sometimes the best thing you can do is stop and walk away. Not failure. Just redirection. What are you working on now?
@imed_radhouani I am working on a supplement morning routine shot, designed to cover basic needs of vitamins, the idea is to replace base with one drink, consistency becomes easier, delivered each month, just take a small bottle in the morning and that is it.
This time I did a lot of researches and even surveys :D
I think building for enterprise is very tempting, but much more difficult than it seems at first. It’s easy to assume a few enterprise features will unlock bigger customers, when in reality the real challenge is everything around them: trust, timing, process, and actual demand.
@aniela_oprea You're exactly right. The features are the easy part. The trust, timing, process, and demand are what actually kill you.
We built the features. We thought that was the hard part. Then we learned that enterprise buyers don't care about features until they trust you. And they don't trust you until you have SOC2, legal reviews, onboarding processes, and a track record.
The features unlocked nothing. The operational gaps killed everything.
What's the hardest non-feature thing you've had to build for enterprise?
maybe the price is still quite too expensive for even enterprise to charge for?