A Series A data infrastructure company came to us last year with what looked like a top-of-funnel problem that had already been solved. Twelve qualified enterprise conversations in a quarter. Four proofs of concept running in parallel. A founder who had done the hard part and built genuine demand.

None of the four closed.

The diagnosis moved around. Pricing, first. Then positioning. Then the AE. It was none of them. The POCs were being run by whichever engineer had a free afternoon, against success criteria nobody had written down, on customer data that had never been near production.

Those deals did not fail at the close. They failed in week two of an evaluation that nobody owned.

The POC Is the Deal Event, Not a Step Towards It

In classic enterprise software, the technical evaluation is a checkpoint. The buying decision is made commercially and the evaluation confirms it. Procurement and security are the genuine risks.

In AI and infrastructure, that order inverts. The commercial conversation is provisional until the thing works on the customer’s own data, in their own environment, against their own latency and cost constraints. As we wrote in Enterprise AI Sales Is Not SaaS Sales, the POC is where the deal is genuinely won or lost.

Which means the most consequential person in your sales process may not be the one carrying the number.

It is the person who scopes the evaluation, sets the success criteria, and gets the thing working in an environment they do not control.

What the Founding Solutions Engineer Actually Owns

The title is borrowed from mature sales organisations, where an SE supports an AE inside a defined process. At Seed and Series A there is no defined process, so the job is bigger and stranger than the title suggests. Four things belong to this person from day one.

• Scoping the evaluation. Deciding what will be tested, what “working” means in numbers, and what is explicitly out of scope. A POC without written success criteria is not an evaluation. It is an open-ended engineering favour.
• Owning the technical narrative. Translating architecture into consequence for the buyer, and translating buyer constraints back into something the engineering team can act on.
• Managing the customer’s engineers. The people running your evaluation on the customer side have day jobs. Someone has to keep the evaluation alive against their sprint priorities, and that someone is not your AE.
• Feeding the roadmap. After ten evaluations, the SE knows precisely which three gaps kill deals. That is the most valuable product input in the company, and it is usually trapped in a Slack thread.

None of that is sales support. It is deal ownership with a technical surface.

Why the Profile Is Different in AI Infrastructure

The default instinct is to hire an SE from a large infrastructure vendor. Strong technical grounding, polished delivery, comfortable in front of an enterprise buyer. It fails more often than founders expect, and for a specific reason.

At scale, an SE demonstrates a product that already works to a buyer who already understands the category. At Seed, an SE debugs a product that half works, for a buyer who is still deciding whether the category is real.

The first job rewards polish. The second rewards judgement under uncertainty.

So the signal to hunt for is not depth of product knowledge, which decays anyway in a field moving this fast. It is whether the person can hold a technical position they have reasoned their way to rather than been briefed on. Can they say “that will not work, and here is what will” to a customer architect, and be right often enough to earn trust?

The strongest founding SEs we place tend to come from one of three places: forward-deployed or field engineering roles, where owning outcomes in someone else’s environment is the whole job; consulting or professional services inside a technical vendor; or a backend or platform engineering background from someone who has discovered they prefer customers to sprints. That third group is consistently underrated and worth actively sourcing.

How to Evaluate One Without a Playbook to Test Against

You cannot benchmark this hire against a process you have not built yet. So evaluate against the work rather than the CV. Three exercises do most of the diagnostic lifting.

The scoping exercise. Give them a real prospect scenario from your pipeline, with the messy parts left in. Ask them to write the evaluation plan: what gets tested, what the pass criteria are, what they would refuse to include, and what they would need from your engineering team. Strong candidates narrow the scope. Weak ones agree to everything.

The failure conversation. Ask them to walk you through a POC that failed and what they would do differently. What you are listening for is whether they locate the failure in their own scoping, or entirely in the customer, the product or the AE. People who have genuinely owned evaluations know exactly where they lost control.

The pushback test. Have a technical member of your team challenge a claim they make. The question is not whether they win. It is whether they hold a defensible position, concede the part that is genuinely uncertain, and keep the conversation moving. That is the behaviour a customer architect will meet in week two.

Structured evaluation matters more here than almost anywhere else in early GTM, because the failure mode is so quiet. A weak SE does not lose deals visibly. Evaluations just take a little longer, then a little longer, and eventually the champion stops replying.

When to Make the Hire

The common sequencing is first AE, then wait for volume, then SE. That is usually a quarter or two too late.

The trigger is not headcount ratio. It is the moment your first serious technical evaluation lands and the honest answer to “who is running this?” is the CTO, or a founder, or nobody in particular.

If your founding engineers are spending more than a day a week inside customer evaluations, you already have a solutions engineer. You are just paying for it in roadmap velocity instead of salary.

At that point the maths is not close. One evaluation slipping a quarter costs more than the hire, and it costs it twice: once in the deal, once in the engineering time that went into it.

The Broader Principle

Founders sequence GTM hires by which role is loudest. Pipeline feels empty, so hire an AE. Deals feel stuck, so hire a leader.

The better question is where the deal actually turns. In AI and infrastructure, it turns in the evaluation, in front of engineers, on the customer’s own data.

Hire for that moment and the rest of the funnel starts behaving.

If you are working out whether the founding solutions engineer is your next hire or the one after, I would be happy to give a second perspective. You can see how we approach early GTM sequencing on our solutions page, or drop me a message.