How to build new logo pipeline for simulation software with a proprietary solver

The champion is a principal or staff engineer. They have deep technical credibility, no budget authority whatsoever, and one source of leverage: a programme with a date on it that is currently blocked by an analysis they cannot run fast enough or trust enough.

The signer is a simulation manager or engineering director who owns the tooling budget and, more importantly, owns the relationship with the incumbent vendor. That relationship is the terrain of the whole sale. They negotiated the enterprise agreement, they defended it internally, and buying a specialist tool is on one reading a comment on that decision.

Two functions can stop you without ever taking a meeting. Information technology has to install it, run the licence server, and make it work with the compute cluster or the cloud tenancy. Procurement has to add a supplier, which at a company of any size is a fixed cost in weeks.

And there is the incumbent's account manager, who is not in your pipeline and is absolutely in this deal. Their standard and highly effective move is to bundle their own version of your capability into the next renewal at no visible cost.

Simulation engineers are among the most rigorous buyers you will ever write to, and the beliefs below are not marketing resistance. They are what twenty years of tool evaluations taught them.

What they believe today.

• We already have a simulation platform. It covers this physics, not brilliantly, and we know its limits and work around them.
• Adding a tool means learning a tool. The real cost is not the licence, it is three months of my time and a workflow that now has two file formats in it.
• New solvers are unproven. Yours will disagree with our current results and with our test data, and I will be the person explaining that in a design review.
• Cost is not my problem and not my argument. I cannot get a director excited about saving money on software, and I would rather not open that conversation.
• The margin we carry is engineering judgement, not waste. That is how we have avoided failures.

What has to be true before they can buy.

• The unit of value is iterations per week, not dollars per seat. A fourteen hour solve means one design attempt a day and none over a weekend. A forty minute solve means the engineer tries six things before lunch and arrives at the design review with an answer rather than a schedule. Everything else on this page is downstream of that sentence.
• The expensive analysis is the one nobody runs. When a study is painful it gets skipped, and the substitute is margin: extra mass, extra copper, extra material, a bigger heatsink, a later launch. That cost is real, it is already being paid, and it has never appeared on any line item. Naming it converts your product from a tooling expense into a product cost conversation.
• You are additive, not a replacement. They keep the general purpose suite for everything it is good at and stop using it for the one problem it handles worst. This protects the manager politically and it is also simply true, so say it early and without hedging.
• Trust is built against their test data, not against your benchmarks. Every hardware company has a correlation problem somewhere, a case where the model and the physical test disagree and nobody has resolved it. That is the best pilot in this market, because it has an arbiter neither of you controls.
• Divergence gets disclosed by you, first. Your solver will produce different numbers from the incumbent's. The vendor who explains where and why before the customer discovers it is credible, and the vendor who is caught by it is finished, regardless of which answer was closer.

The reframe in one move: stop selling accuracy to an engineer and start selling design attempts per week to the person whose programme is late. Those are the same product described to two different anxieties, and only one of them has a budget attached.

• Job posts naming the tools. A req for a simulation, analysis or CAE engineer that names specific software tells you the incumbent stack, the physics they care about and that the workload has outgrown the current team. This is the single most reliable trigger in the niche and it refreshes weekly.
• Conference papers and technical presentations by their engineers. Engineers publish, name their methods, and describe the problem that gave them trouble. A paper about a correlation difficulty is an invitation written by your future champion.
• Equipment authorisation and certification filings. For anything with a radio, a battery or an emissions profile, certification records are public, dated and name the applicant and the product. A product entering certification means the current design is frozen and the next one starts now, which is exactly when tooling decisions are reconsidered.
• Funding rounds at hardware companies. New money produces new headcount and a first or second simulation hire, and a team of two has no incumbent enterprise agreement to defend.
• Recalls, field failures and warranty commentary. A company that has just had a thermal, structural or electromagnetic failure in the field has a correlation problem with a board level audience.
• Patent filings. They describe what is being designed, occasionally the analysis approach, and they are public well before the product is.
• Compute investment. Cluster expansions, cloud high performance computing announcements and posts for HPC administrators mean solve capacity is being taken seriously, which is a precondition for caring about solver efficiency.

Job posts and conference papers are the two to build on. One gives you the stack and the headcount. The other gives you the specific technical problem, in the engineer's own words, with their name on it.

• Do they simulate in house, or send it to a consultancy? An outsourcer is a much longer sale and often a different product, and it is worth knowing in the first minute rather than the third meeting.
• Is your physics on the critical path of their product, or adjacent to it? If the answer is adjacent, you are a nice to have and will lose to inertia no matter how good the solver is.
• Do they have physical test data to correlate against? With test data you have an independent arbiter and a short pilot. Without it, trust has to be built on reputation alone and the cycle roughly doubles.
• Are they inside an enterprise agreement, and when does it renew? The three months before a renewal is the worst possible time to be introduced and the best possible time to already be trusted.
• Is there compute? A faster solver with no cluster behind it and a licence bottleneck in front of it produces a disappointed customer, which is worse than no customer.

Write to the engineer about their problem, not to the company about your solver. This audience has been receiving vendor email their entire career and has an unusually fast filter for people who do not understand the physics.

The paper they presented, the certification they just filed, the failure they are living through. Then one specific technical observation, and an offer that costs them nothing to accept.

The third one is the strongest offer in this market and the one most vendors are afraid to make, because it invites a comparison you might lose. Make it anyway. An engineer who tests you and finds you honest is worth more than ten who read a claim.

• A multiple against a named competitor. Ten times faster invites a benchmark argument on their terms, insults the manager who chose the incumbent, and is almost always true only on the case you selected.
• A benchmark on a standard geometry. Nobody's product is a lid driven cavity or a plate with a hole. The only benchmark that persuades is theirs.
• A download link as the call to action. The engineer who cannot solve their own model in the first afternoon does not email you about it, they simply stop, and you will never know why.
• Licence cost savings addressed to a finance audience. It bypasses your champion, reframes you as a procurement conversation, and gives the incumbent's account manager an easy path to a discount that ends the evaluation.
• Any claim that they should replace their existing platform. It is not going to happen, everyone in the meeting knows it is not going to happen, and saying it costs you the credibility you need for the additive argument.

Our enterprise agreement already covers that module. The defining objection, and it arrives at renewal time with a zero on it. Never argue about whether the bundled module is any good. Get the comparison run on their own model before the renewal window opens, hand your champion solve times and correlation figures they can forward without you in the room, and let the numbers have the argument. Free is unbeatable in the abstract and quite beatable when the free version takes eleven hours.

I do not have time to learn another tool. Entirely fair and usually decisive, so answer it with staffing rather than reassurance. Your applications engineer sets up the first three models. Measure adoption in models run rather than licences issued, and say that in the first conversation, because it tells the engineer that you know how tools actually die.

How do I know your results are right? Publish the validation library, name the reference cases, and then move immediately to their correlation problem. Every hardware company has one case where the model and the test disagree and nobody resolved it. Solving that is worth more than any benchmark suite, because the test rig is an arbiter neither of you controls.

Information technology will not install it. Raise it before they do. Licence server or cloud, scheduler compatibility, what happens behind their firewall, whether it runs on the cluster they already have. A vendor who volunteers the deployment answer in the first meeting removes the objection that quietly kills more of these deals than any technical shortcoming.

• Named seats: commonly $10K to $60K per seat per year for a specialist solver, with solver tokens or core hours priced separately so that heavy users do not become unaffordable and light users are not overcharged.
• Departmental agreement: commonly $75K to $400K a year once a second programme adopts, which is the natural expansion point rather than a headcount increase.
• Applications engineering days bundled into year one. Not a giveaway, an insurance policy on adoption, and the single highest return line item in the contract.
• Training and model migration priced separately, because moving existing models across is real work and pretending otherwise creates an unhappy first quarter.
• Signer: the simulation manager or engineering director. Champion: the principal engineer. Blockers: information technology and procurement. Cycle: three to nine months when tied to a programme milestone, longer when tied to nothing.

The renewal risk here is specific and worth designing against. If your tool did not appear in a programme during the year, it is cut, regardless of how well the pilot went. Usage is the renewal, so instrument it from day one and review it with the champion quarterly rather than discovering it in month eleven.

• Weekly, pull simulation and analysis job posts across your target industries, reading the named tools as the incumbent stack and the physics as the qualification.
• Monthly, scan conference proceedings, technical papers and patent filings for engineers describing problems in your physics. This is slower research and it produces the best first emails you will write all year.
• Monthly, pull certification and equipment authorisation filings in your product categories, and treat each one as a window that opens for about a quarter.
• Continuously, watch hardware funding announcements and the first simulation hire that follows, because a team of two has nothing to defend.
• Twelve to eighteen accounts a week. Each one needs enough technical reading that the first email survives an engineer's filter, which is the highest bar of any niche in this collection.
• Three touches, then stop. The next paper, the next filing and the next req are all coming, and each is a legitimate reason to write again about them rather than about you.

Nobody buys a solver because it is fast. They buy it because the study they have been avoiding becomes something they can run before the design review, and the margin they were carrying becomes mass they can take out.

Everything above is about who and what. This is about how, and it is where most outbound in this niche quietly dies. Seven rules. None of them are optional.

None of this is specific to your niche. All of it is specific to whether anyone ever reads the angle you spent an hour getting right.

That is what we do. ExpertLayer runs this exact loop for firms with proprietary technology: the weekly job post pull read for the incumbent stack, the conference proceedings and patent scans that surface the engineer with the problem, the certification filings that open the window, the angle written per account in the language of that physics, the sending across warmed mailboxes, and the reply reading. You take the technical conversations and run the model.

The first step is free and it is the same research described above. Send us your website and we will come back with 10 companies that hit these triggers right now, with the paper, the filing or the req, the contact, and the opening line for each.