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
Capso
This hit hard. The table of "features nobody asked for vs. the feature 47 people asked for" tells the whole story. With Capso (our macOS screenshot tool), we made the explicit choice early on to not chase enterprise at all. Free, open source, built for individual Mac users. No procurement cycles, no security reviews, no SLAs. The tradeoff is slower monetization, but the feedback loop is immediate. Someone downloads it, loves it (or doesn't), and you know within days. Thank you for sharing this honestly.
Rankfender
@lzhgus That tradeoff is real. Slower monetization. Faster learning. The feedback loop is the asset. Enterprise pays more per customer but tells you nothing for months. Individual users pay less but tell you everything within days.
The "no procurement cycles, no security reviews, no SLAs" is not a limitation. It is a feature. You spend your time building, not waiting.
The table is painful to look at because it shows your own blind spots. We thought we were solving big problems. We were solving problems nobody had.
Free and open source is a different model. The trust is built differently. People can see the code. They can compile it themselves. They do not have to believe you. They can verify you.
What is the most surprising thing you have learned from a user within 24 hours of them downloading Capso?
This hit close to home, Imed. The "no enterprise features until someone pays" rule is one I wish more founders wrote down before spending a dollar.
To answer your question: yes. We built a full "agency mode" for ad-vertly early on — multi-seat dashboards, white-label reports, client management — based on inbound interest from a handful of agencies who said they'd pay. None did. Turns out "I'd pay for this" and "I will pay for this" are very different conversations.
The lesson we took: our actual PMF is with solo founders, not agencies. Solo founders make faster decisions, feel the pain more acutely, and have fewer people to convince. We were ignoring them while chasing the more glamorous agency deal.
Your rule about not building until someone pays first is exactly right. We now require a pilot deposit before we build anything custom.
Rankfender
@gaurav_singh91 The "I'd pay for this" vs "I will pay for this" gap is where good ideas go to die. The first one is a compliment. The second one is a contract. Most founders stop at the compliment and start building.
The pilot deposit is the only filter that works. Not a letter of intent. Not a handshake. Money. Small is fine.
The glamour of the agency deal is real. It sounds bigger. It sounds more professional. It sounds like you have arrived. But solo founders pay faster, give feedback faster, and churn slower when you solve their actual problem.
The agency mode features you built were not wrong. The timing was wrong. You built for customers who were not ready to buy. The solo founders were ready. You just were not looking at them.
What happened to the agency mode features? Did you kill them or just pause?
The opposite is happening with us. We are building for the smallest possible customer, US self-employed, 31 million of them, no procurement cycles, no compliance reviews, no IT gatekeepers. Just one person with a shoebox of receipts.
The temptation to go upmarket is real. But your line stuck with me: no enterprise features until someone from enterprise pays first. Not asks. Pays.
Reading this, I am just glad we started small. You shipped, you learned, you pivoted. That already puts you ahead of most. Good luck out there. I will need some too.
Rankfender
@hellobzec The 31 million number is the kind of market you cannot ignore. No procurement cycles. No compliance reviews. No IT gatekeepers. Just one person with a shoebox of receipts trying to get their work done.
The temptation to go upmarket is real. One enterprise deal looks bigger than 100 small ones. But the small ones pay faster, complain louder, and make your product better. The enterprise deal takes a year and then leaves when the champion changes jobs.
Starting small is not settling. It is learning at the fastest possible speed.
The pivot is not failure. It is data you did not have before. You shipped, you learned, you changed direction. That is the work.
Good luck to you too. The shoebox people need better tools.
Oof. This feels very real.
A lot of us are tempted by “enterprise” because it sounds like maturity, scale, and validation. But often it’s just a very expensive way to avoid listening closely to the users already in front of us.
What makes this post strong is that it doesn’t romanticize the lesson. You’re basically saying: we built for the buyer we wanted, not the buyer we had.
We’re thinking about the same tension at SpeakUp. There’s always a pull toward bigger accounts and more advanced workflows, but the strongest growth signals still come from the real problems current users keep repeating.
“Evidence over ego” is such a good founder rule.
Rankfender
@chronicles_of_the_desert The temptation is real because it works on your ego. Enterprise sounds like you made it. The bigger the logo, the bigger the validation. But validation is not a strategy. It is a feeling.
The most expensive way to learn is to ignore the users in front of you. They are already paying. They are already telling you what is broken. They are already showing you the path. But they are not shiny. So you look past them.
The buyer you want does not exist yet. The buyer you have is right there. They have problems. They have money. They have patience if you listen. The enterprise buyer has a procurement cycle and a security questionnaire. That is not better. It is just slower.
Evidence over ego is the rule that is easy to say and hard to follow. The ego wants to build the new thing. The ego wants to announce the partnership. The ego wants the big logo on the homepage. The evidence is sitting in your support tickets, your usage logs, your churn data. It is boring. It is also true.
What is the most boring piece of evidence that saved you from a bad decision?
Hello Aria
This hits close to home. We had a similar phase with Hello Aria - we were tempted to go after teams and orgs early because the ticket size looked better. But our product is fundamentally personal (AI day manager via WhatsApp and iOS). Individual users got it immediately. Enterprises asked for SSO, admin dashboards, compliance docs - things we had no business building at our stage. The lesson: enterprise sells slow, and your product needs to be fundamentally enterprise to sustain it. If your core UX is personal, scale that first. Really appreciate you sharing this openly - too many founders only post the wins.
I’m 100% printing "Evidence over ego" and taping it to my screen.
As a new indie dev, this hit home. Your story reminded me that "likes" are cheap—it’s the actual payments that prove you've built something people need. Appreciate you sharing the hard-earned lessons!
This is one of those expensive but valuable lessons.
What stands out is how common this pattern is. Teams assume enterprise is just “more features,” but it’s actually a completely different motion: longer sales cycles, compliance, onboarding, and trust layers.
Also love the point about data vs assumptions. The 47 requests vs 0 requests example says everything.
Feels like the real takeaway is: don’t build for a market you haven’t talked to. Enterprise isn’t a feature set, it’s a business model.
Wondering why you decided to build enterprise features before an enterprise contract was ready? I am in a similar boat, but for example I'm not building SSO until they sign a contract with it included. Or is contracting not the norm for pure SaaS models?
The line “we were chasing a dream, not data” hits hard, because I think a lot of builders quietly do this. Enterprise sounds like the “serious” next step, but the boring requests from real users are often the actual roadmap.
Also love the rule at the end: no enterprise features until someone pays first. Simple, painful, but probably saves months of building the wrong thing. appreciate the post
This maps exactly to what happens with highly specialist niche products, where the buyer is always an individual practitioner — never a procurement team.
I sell financial model templates on Eloquens (www.eloquens.com/channel/samir-asadov-cfa) — project finance, M&A valuation, mortgage analysis. The temptation to go "enterprise" is real: institutional licenses, bulk downloads, corporate procurement. But the actual buyer is always a CFA or analyst with a specific deal on their desk and two days to build a model. That person doesn't want SSO. They want to know the model was built by someone who has sat in the same chair.
Your point 1 is the one that really lands: "customers don't ask for enterprise features until they're ready to pay enterprise prices." The corollary is that in practitioner markets, the enterprise buyers almost never exist. The people who actually know your tool's value are individuals making a judgment call, not committees running an RFP. Building toward a buyer type you haven't found yet — while neglecting the 89% API rate limit power users you already have — is the most expensive mistake a niche product can make.