AI and coding Agents make it much simpler, cheaper, and faster to build targeted internal solutions to go-to-market problems. Nowhere is that clearer than in sales. There, companies can gain an edge over competitors still relying on off-the-shelf software that is often bloated, expensive, and built for the last generation of SaaS.
When Nicolas Sharp, co-founder of Attio, spoke at our Fin for Sales event recently, he put words to something I’d already been seeing: a growing need for more technical roles across GTM, not just in sales, but across marketing and customer success too. He framed it through Jevons paradox. When steam engines became more efficient, coal use didn’t fall, it surged. His view is that as AI systems become more capable, demand for the people who can build, operate, and improve them will grow, not shrink.
That resonated with me because it’s close to what we’re building at Fin. We’ve set up a new engineering team dedicated to improving GTM effectiveness and efficiency. Its mission is to bring a commercial edge to the organization by applying the latest technology and techniques. It’s still early, but we’re already seeing results against our commercial targets, with adoption of these tools well beyond what we expected. As the team grows, some interesting technical and organizational dynamics are becoming clearer, and we’ve been leaning into them eagerly.
The power of the pair #
We’ve had real success pairing an AI-forward generalist engineer with a domain expert who deeply understands the problem space and the organization. That has pushed me to think less in terms of “what can this team achieve” and more in terms of “what can one engineer achieve,” and increasingly, the answer is a lot more than before.
Taking this approach, we built an answer engine optimization (AEO) engine that dramatically increased Fin’s visibility in AI chatbot responses and grew bot-sourced revenue pipeline. We had similar results building an outbound engine, and now we’re applying the same model to optimize other sales workflows.
In conversations with peer companies, I’m seeing a broader pattern emerge. Engineers are working much more closely with frontline contributors and managers, and are embedded directly in the teams and workflows they’re trying to improve. Rather than building generic products, they’re creating bespoke solutions from the bottom up. This feels like one of the most important developments inside GTM right now.
Building bespoke #
It’s easy to hear “build your own tools” and conclude that SaaS is dead. I don’t think that’s true, though I do think SaaS is being dramatically disrupted.
Foundational platforms like your CRM, payments infrastructure, and customer communication layer are systems of record. They’re deep, broad, and embedded in the ecosystem in ways that make them genuinely hard and unwise to rebuild. You should keep buying Salesforce. You should keep buying Stripe. You should keep buying Fin. These products encode years of hard-won capability that no small internal team should be trying to replicate.
What’s different now is the layer above them: the orchestration layer. It’s the customization that connects these systems, fills the gaps between them, and makes the job easier for the rep, the marketer, or the CSM. That used to require a vendor relationship, a six-month implementation, and a dedicated admin. Now it requires a very strong data and systems foundation, a GTM engineer, and a couple of weeks focused on a clear problem to solve.
We built a cockpit to run outbound across Outreach, our data warehouse, and our own internal infrastructure. It made it possible to turn new ideas into pipeline in a way the team could actually run. Without it, the process was extremely manual and error prone. It has already generated $1.2 million in sales pipeline, and we’re tracking toward $5 million by year-end, without any migration or the need to learn a new tool. We also built another internal tool in roughly three weeks that replaced a vendor product we had been evaluating. We found the gaps, shipped something better, and tuned it to our exact needs.
We’re seeing the same logic at other companies too. Will Jones, a GTM operations associate at Attio, is in a role that barely existed a few years ago. He implemented Fin for Sales largely himself. He turned help center content, testimonials, social proof, and past call transcripts into tailored context docs, then built and tested a working Sales Agent in a matter of weeks. Now he reviews conversations, patches content gaps, and works on data pipelines that weren’t there six months ago.
What stuck with me most was how he went on to describe his job. It was less about doing the work directly, and more about directing Agents to do it well. That feels like the clearest articulation of the GTM engineer role I’ve heard so far. We’re no longer trying to find the perfect point solution in the market. We’re building the connective tissue between our foundational platforms ourselves, and for that class of problem, the advantage of building internally has been clear.
We’re seeing the same idea reshape adjacent technical functions too, though that’s a broader story in its own right.
What I’m nervous about #
I’d be dishonest if I presented this as a clean story. It isn’t.
One question I keep coming back to is whether the cockpits our teams are building are durable, or whether they’re sophisticated throwaways. I genuinely don’t know whether the orchestration layer we’re investing in now becomes a lasting foundation or scaffolding around something that hasn’t been invented yet.
I’m also thinking about the staffing implications. What happens when the tools get good enough that everyone in GTM is self-serving more of their own analysis, workflows, and automation? That may be a success story for the company, but it fundamentally reshapes what my team needs to look like, how big it is, and what roles I hire for. It will probably get smaller, and the roles will become less engineering-heavy.
Build for the flex, not the forecast #
My biggest concern isn’t any single one of these questions. It’s that, for all the ambiguity, excitement, and energy around what’s changing, the core principles of building and delivering software still apply.
The creative trial and error required for this transformation means you have to throw away half of what you try, maybe more. At the same time, there’s a sales team hungry for pipeline this quarter and for tools that work right now. I don’t know what the right balance looks like between exploring the next evolution of GTM software and delivering on near-term objectives that fuel the business.
What Nicolas said resonated with me here. He said Attio doesn’t try to perfectly predict what the future will look like in 18 months and then build an organization around that vision. Instead, they try to build one that’s so agile it won’t matter if their vision is 50% wrong. Build for the flex, not the forecast.
I think that’s right. I also think it’s hard to put into practice when near-term commercial pressure doesn’t go away.
Where this leaves us #
GTM engineering isn’t a hypothesis anymore. The pattern is clear: embed a builder next to a domain expert, give them a fast feedback loop, and get out of the way.
Exactly where this leads is still unclear. What we’re building now may prove durable, or it may simply be a bridge to whatever comes next. Demand for GTM engineers may grow as Nicolas predicts, or the tools may get good enough that the role evolves into something else entirely.
What I do know is that the old model of buying software, plugging it in, and trying to make it all hang together is no longer the only option for the orchestration and customization that makes GTM function. The foundational platforms still matter. But the layer that connects them, shapes them around the workflow, and makes them coherent for the people doing the job is increasingly where real advantage gets built. That’s the work of GTM engineers, and it’s why this role is becoming real.