For almost ten years, I sold application security tools into enterprises.
I sat through thousands of discovery calls, demos, POCs, procurement reviews, and security questionnaires. Some deals closed in weeks. Others took more than a year. Most followed the same pattern.
For the last two years, through AppSec Santa, I’ve mostly written from the buyer’s side about how to evaluate tools, compare vendors, and avoid expensive purchasing mistakes.
This week, let’s switch chairs. If you’re a founder selling into enterprises, this story is for you. If you’re an AppSec engineer evaluating vendors, stay with me. Every section ends with a note written specifically for you.
The deal is the same; the view is different.
Let me walk you through a typical enterprise security purchase. From first lead to signature, it takes about seven months — and that counts as fast.
Day 1 — A Lead from a Fortune 500
From the founder’s side, day one feels exciting. A Fortune 500 lead lands in the inbox, and at an early-stage company every enterprise logo matters.
The founder sees opportunity. The buyer sees curiosity. Neither side realizes yet how much work sits between those two things.
Unless you have an exceptional VC to open doors for you, the lead probably arrived the quiet way. An AppSec engineer read an article, saw a LinkedIn post, heard about your company from a peer, or increasingly these days, asked an AI for recommendations and discovered you there.
At this stage, the discovery call is everything. The demo, the POC, the proposal, and the procurement process mostly exist to validate what was learned during that first conversation.
Most founders think discovery is about presenting the product. It isn’t. The product comes later.
The real goal is understanding what is actually driving the evaluation, and whether the two sides see it the same way.
In the discovery calls that go well, the founder talks the least. When buyers pause, experienced sellers don’t rush to fill the silence. They listen.
Because the first answer is usually the obvious one. The interesting part often comes a few seconds later.
There are long pauses, more questions than answers, and very little product discussion. That’s usually a good sign — every minute spent talking about your product is a minute not spent learning about theirs.
One lesson from hundreds of discovery calls: the stated problem and the buying motivation are not always the same thing.
A buyer might ask about coverage, prioritization, or integrations. What actually drives the purchase is often buried underneath those requirements. The teams that uncover that motivation tend to have much shorter sales cycles.
A discovery call you dominated may feel productive. But it rarely teaches you much.
If the category is new to you, spend an hour learning it before the call. Walk in with questions that reveal how the tool actually works, not how the vendor markets it.
“How does your exploitability analysis work?” will usually teach you more than “what is your false-positive rate?” Every tool is apparently 99.5% accurate these days.
Week 3 — The Demo
A few weeks later, the demo arrives. The founder is showing a path they’ve walked a hundred times. The buyer is trying to determine whether that path exists outside the demo environment.
That difference matters. Because the demo is not proof. The demo is a promise.
The best demos are surprisingly narrow. Not because the product lacks capabilities, but because relevance beats completeness.
Nobody buys because a product has 200 features. They buy because five of them solve a painful problem.
Most customers eventually use only a small fraction of a product’s capabilities. Good vendors understand which fraction matters.
The demo always works. That’s what demos are designed to do. Let the vendor show their story for a few minutes, then start steering.
If there’s a workflow you need to see, ask for it. If there’s a concern you have, bring it up. It’s better to discover a mismatch in week three than in week seven.
Month 2–3 — The POC
The demo earns the real test. The product now enters the customer’s environment, codebase, workflows, and constraints. The conversation shifts from promises to evidence.
Things break. Integrations behave differently. Repositories are larger. Pipelines are stranger. IT says it is whitelisted but you get “Connection timed out”.
This is normal. Issues will appear; what matters is how both sides respond.
Successful POCs usually begin with written success criteria, because organizations are complicated and scope drifts as people learn.
I once watched an evaluation expand from five agreed requirements to more than twenty. Nobody was acting in bad faith. The organization was simply learning as it went.
Written success criteria protect both sides from that drift.
Before the POC starts, make sure the stakeholders who will influence the purchase understand the evaluation plan.
The worst outcome isn’t a failed POC. Failed evaluations create clarity. The worst outcome is uncertainty — a month later, nobody can clearly explain whether the tool solved the problem, whether the business case exists, or what should happen next.
The evaluation should reduce uncertainty. By the end of it, the team should have clear answers to two questions: did the tool solve the problem, and are we confident enough to move forward?
Month 4 — Your Champion Starts Selling
This is where many founders misunderstand enterprise buying. The POC succeeds, the team is happy, the product performed well. And yet the deal still doesn’t close.
Why? Because the evaluation is over. The internal selling has just begun, and most enterprise purchases happen when the vendor is not in the room.
The security engineer explains the recommendation to a manager. The manager explains it to a director. The director explains it to procurement, while architecture reviews the decision, finance reviews the budget, and legal reviews the contract.
The founder is no longer the primary salesperson. The internal champion is.
One lesson that took me years to understand: most deals don’t die because people dislike the product. They die because nobody is willing to spend political capital advocating for the purchase.
Vendors who close recognize this. They help their champions sell internally by creating business cases, executive summaries, and decision documents that survive being forwarded across the organization.
If you want the tool, start socializing the outcome before the POC ends.
Don’t spend three weeks proving something works and then surprise your manager with a purchase request. Enterprise buying is rarely about finding the best product. It’s about creating enough organizational confidence to make a change.
Month 5 — The Proposal
By month five, both sides usually know what they want. The remaining question is whether the organization can get there.
The best proposals are not pricing documents. They’re decision documents. Their purpose is to help the people who were never in the room understand why the purchase should happen.
A strong proposal reconnects the entire story: the original problem, the evaluation criteria, the POC results, the rollout plan, and the expected outcome. Only then does pricing enter the conversation.
One thing I’ve noticed over the years: complex pricing conversations benefit from silence. It isn’t a negotiation tactic — important decisions simply deserve a moment of thought.
At the same time, a good proposal creates urgency from reality: implementation timelines, budget windows, and go-live targets. Everyone knows that “valid until June 30” will eventually become “valid until July 15”.
When commercial discussions begin, think beyond the first-year number.
Support expectations, renewal protections, implementation commitments, reference obligations — these often create more long-term value than another percentage point of discount.
Month 7 — The Close
Month six passes mostly in waiting: redlines move between legal teams, the proposal circulates for sign-off, and the decision inches forward. By month seven, the last real gate appears.
At this stage, the founder worries about runway. The buyer worries about risk.
Both concerns are rational. Neither side usually says them out loud.
Procurement arrives, then legal, then the security review. The vendor questionnaire appears, SOC 2 reports are requested, and policies and controls are examined.
This is where many enterprise deals quietly die. Not because the product failed. Because the company wasn’t ready.
Many founders treat security reviews as administrative work. Buyers don’t.
The buyer is no longer evaluating the software. They’re evaluating whether the company belongs inside their risk model.
A Fortune 500 company is not merely buying software. They’re attaching your company to their reputation.
That requires evidence, and evidence takes time to build.
Your leverage is highest before the signature. Use it thoughtfully.
Clarify renewal expectations, support expectations, and what success looks like after deployment.
But calibrate the review to the company’s stage. A two-year-old startup won’t have the same evidence as a twenty-year-old public company. That isn’t automatically a red flag; sometimes it’s simply a consequence of being two years old.
The Deal Is Two Sides Reading Each Other
That is the whole seven months.
Discovery → Demo → POC → Internal Selling → Proposal → Procurement → Close.
From the founder’s chair, it often feels like the buyer is moving slowly. From the buyer’s chair, it often feels like the founder is pushing too hard.
Both sides spend months working through the process. The founder thinks they’re selling. The buyer thinks they’re buying. In reality, they’re evaluating each other.
And they’re both trying to answer the same question: can we trust each other enough to move forward?
If you’ve sat on either side of this table, I’d love to hear which part felt most familiar.
Founders: where do your deals usually stall? AppSec engineers: at what stage do vendors lose your trust?
See you next Tuesday.
This issue walked through a single enterprise security deal — from first lead to signature, read from both chairs.
AppSec Santa Weekly — notes from someone who sold AppSec tools for a decade, now writing for the buyers. Browse all tools or subscribe for weekly updates.