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 is such a common trap in dev tools. The enterprise pivot feels "safe" because the contracts are bigger, but the sales cycle is 6-12 months and you're competing against established vendors with existing relationships.
What worked for us: build for individual developers first, make it genuinely useful as a free/cheap tool, then let those developers become your internal champions when their company needs to buy. Bottom-up adoption > top-down enterprise sales, especially for tools where the end user is a developer.
The hardest part is patience — individual developer adoption grows slower at first, but the retention and word-of-mouth are way stronger than enterprise contracts won through sales demos.
@ethanfrostlove That's the smarter path. Bottom-up > top-down every time for dev tools. We did the opposite. We went for the big contracts first. No champions. No track record. Just hope.
The 6-12 month sales cycle killed us. We didn't have the runway to wait. And we were competing against vendors who had been in those accounts for years. They didn't have to prove themselves. We did.
The patience part is the hardest. Bottom-up feels slow. You want the big win. But the big win doesn't come without the little wins first.
How long did it take you to see real momentum from the bottom-up approach?
This one stings to read because I've been in a version of it.
When I was building ad-vertly.ai, my biggest early mistake was similar: I spent weeks building integrations nobody had actually committed to using. They "sounded interested." That's not the same thing.
Your rule — "no enterprise features until someone pays first, not asks" — is exactly right, and it applies to every feature at every tier.
The 47 API rate limit requests vs. 4 SSO requests story is the real lesson here. The loudest requests aren't always from the right customers, but 47 people asking for the same thing is almost always signal.
One thing I've found useful: when someone asks for a feature, ask them "what would you do differently tomorrow if this existed?" The vague answers reveal who's dreaming, the specific ones reveal who actually has the pain.
Painful but honest post. More founders need to share the expensive lessons.
@gaurav_singh91 That "what would you do differently tomorrow" question is gold. We're stealing that.
The vague answers are the danger. "I'd use it all the time" sounds great but means nothing. "I'd stop exporting to CSV and manually reformatting every week" means there's real pain. That's the signal.
You're right about loud vs quiet. The 47 API requests were quiet. No one was pounding the table. But the frequency was consistent. That's what we missed.
The integrations trap is real too. "Sounds interested" is not a commitment. We learned to ask for something small before building anything. A letter of intent. A paid pilot. Even a $500 deposit. If they won't put anything on the line, neither should you.
What's the most expensive "sounded interested" thing you built?
TapRefer
thats why i first talk to users, then take validation as a pre-order sales. then build.
@jiteshghanchi That's the cleanest path. Pre-orders don't lie. If someone pays before you build, you know it's real. If they won't, you just saved yourself months of work.
We didn't do that. We built first, then hoped. That's the expensive way to learn.
This hits hard. On the recruiting side, I've watched teams burn quarters chasing enterprise logos before they even nailed self-serve adoption. The painful lesson for us was that enterprise wants proof from peers, not pitch decks. Did you find a smaller wedge that actually closed, or are you reshaping the whole motion?
@ceciliatran The wedge never closed. That's the truth. We had no enterprise deals. Zero. Not one.
We kept telling ourselves "the next feature will unlock it." It didn't. We kept saying "the next conversation will go differently." It didn't.
The whole motion was wrong. We were trying to skip the step where we prove ourselves to actual users first. You can't skip that step.
Now we're focused on SMB. The people who can say yes without a committee. The people who care about the product, not the SOC2 paper. If we ever go back to enterprise, it'll be because our customers pull us there, not because we push.
What's the smallest enterprise deal you've seen actually close? What made it work?
@ceciliatran No wedge. Nothing closed. That's the honest answer.
We kept thinking the next feature would be the one. The next pitch would land. The next demo would seal it. But we never had the proof. No case studies. No references. No track record. Just a deck and a dream.
Enterprise buyers want to see that someone like them already took the risk. We couldn't show that. So we were asking them to be first. That's a hard sell.
Now we're reshaping the whole motion. Focus on SMB. Let them prove the product works. If enterprise ever comes back, it'll be because they heard about us from someone who actually uses us. Not from a cold email.
What's the smallest proof point that actually helped you move upmarket?
Did any of those API-heavy power users eventually grow into your best higher-ACV accounts?
@george_n6 Yes. The ones who hit the API limits were our most engaged users. They were using the product daily. They had integrated it into their workflows. They weren't just testing. They were depending on us.
When we finally shipped the rate limit fix, those same users became our best advocates. They upgraded. They referred others. They gave us feedback that shaped the roadmap.
The quiet ones who just used the product turned out to be our most valuable customers. We just didn't see it at first because they weren't loud.
If an enterprise prospect isn't willing to partner with you on the roadmap before you build, are you solving a universal market pain or just a theoretical one?
@je_yue_yip Theoretical. Every time.
If they won't commit before you build, it's not a real problem. Not for them. Not at the price you need.
Enterprise prospects who actually feel the pain will work with you. They'll give you feedback. They'll test early versions. They'll sign a letter of intent. They'll do something.
The ones who say "that sounds interesting, let us know when it's ready" are not buyers. They're spectators.
We spent months chasing spectators. Now we have a rule: if you won't help shape it, you won't buy it.
This hits close to home, Imed. The enterprise pull is seductive but the selling motion is completely different and most small teams underestimate that. I'm building marketing autopilots for solo founders (ad-vertly) and we almost went down the same path when agencies asked for a white-label version. We kept asking: who needs this most right now? For us it was solo builders who can't also become full-time marketers. Smaller users, faster feedback loops, and they tell you what's broken in hours not quarters. Your table comparing build time vs requests vs actual usage is the most honest breakdown I've seen. Should be a framework every early-stage team uses before committing resources.
@gaurav_singh91 The white-label trap is real. An agency asks for it. It sounds impressive. You start building. Then you realize they were the only one who wanted it.
The "who needs this most right now" question is the right filter. Not "who would use this" but "who is hurting from the lack of this today." The solo builders are hurting. They have no marketing team. They have no time. They have a product that works and no one knows about it. That is a real problem.
The faster feedback loop from smaller users is the thing people miss. Enterprise gives you feedback in quarters. Solo builders give you feedback in hours. They DM you. They leave reviews. They tell you exactly what is broken. That signal is worth more than any enterprise contract.
The table came from watching teams build features nobody used. It is painful to look at your own numbers and see that the thing you spent 6 months on has 3% adoption. But the pain is useful. It stops you from doing it again.
What is the most honest table you have had to build for your own product?
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.
@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.
@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.
@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.