Building for Sales as a non-engineer

Keeping any bigger picture views on AI aside, being able to create something that was previously not possible is objectively exciting. Knowing what to build and what not to build is the biggest challenge of 2026 - how to create tools of genuine value for the team, and what is worthy of operationalising, what is just a fun toy.

So I've spent many chunks of evenings and weekends this year building tools specifically to drive effectiveness in sales - that I wanted to use myself, mostly in Lovable, and some sprinkles from Claude.

Here are some reflections on a few of the tools I’ve built and quickfire learnings.

High intent lead signal tool

Of everything I've built, this may have the best ratio of "simplicity to utility".

Just go into Lovable, and describe each of the signals that represent high intent for your particular ICP. As an example, in building this tool at Foodles, that's offices offering staff benefits (ideally recurring team lunches), based in Central London. You then ask Lovable to build a tool that lets you import any form of lead list (CSV, lists on webpages, photos of buildings with company names on them, whatever you've got), and for it to check each company against the signals you've inputted. It will use firecrawl to parse through the documents (if an image or pdf), or Perplexity to scour the web or to check against specific sites. In our case the tool scoured career pages, Glassdoor, LinkedIn, Welcome to the Jungle and Indeed for staff benefits.

To add further utility (perhaps saving need for separate enrichment tools like Apollo etc), you can ask Lovable to get the tool to find the name and contact details of the relevant ICP within the leads that come back as high intent.

The most efficient combination I found was pairing this with something like Claude Cowork to continuously run the lead list searches. Cowork creates the initial curated automated lead lists, import them into your new lead enrichment tool to find highest signal leads, and then outbound with tailored, relevant messaging.

If your team is price sensitive, an in-house tool like this can lead to real cost savings versus paying for a tool like Clay.

The sprint dashboard

Competitions in sales are fun. Sprints are often necessary to align everyone, test an outbound approach and create a sense of togetherness, ideally with an incentive attached.

Building a dashboard with progress bars, podiums and a visual representation of unlocked incentives adds a layer of fun to a sprint. You can connect it to Slack for daily or weekly updates too.

Done within 30mins. I'd file this more in the "novel and fun" category rather than genuinely useful however.

CRM

I rebuilt our CRM with Lovable. I was pleased that there were no (clear) technical faults to it, it worked well, and I could iterate on it daily based on feedback and requirements. It feels feasible to broadly replicate every function of the major CRMs on the market.

However, there are major downsides:

The real value of a CRM is the legacy knowledge; Which contacts have we had relationship before in a given account? Who has spoken to them before? What have we sent them in the past? What meeting notes do we have that can provide as much context as possible? 

Almost by definition, a vibe coded CRM will be more on the MVP side, so much of the richness of context will likely not be captured, and retrospective context is lost. Other than for a short term solution, it doesn’t make sense.

Many strong sales tools integrate with CRMs. If you’ve built your own CRM, you will be less likely to connect to the broader ecosystem available, workflows not seamless, and your stack is likely to be more fragmented.

AI Sales Roleplay tool - Igi

The question I asked myself is - can I build something that can feel sophisticated enough to be a product usable for SMB or mid market - with the hygiene factors needed for it to a) feel like more than a chatgpt wrapper, and b) have functionality and depth that could provide genuine value, and c) is this possible in the space of a weekend or a couple evenings?

So I built a voice AI sales roleplay tool. You add your sales materials (website, pitch deck, ICP document, call transcripts) and it extracts the key information about your product: ICPs, USPs, likely objections, competitors etc. The user can then practice various roleplay types, including elevator pitch, cold calls, discovery, objection handling, your next meeting, or selling against a competitor. Every call is scored against your sales methodology, with dynamic feedback and a full transcript. Answers can be saved to a model answer library, shared with the team.


I was extremely excited by this concept, because it was:

a) something I could very much use myself when learning the positioning of a new product ("scratch my own itch")

b) something I could use to train new BDs and AEs

c) genuinely quick and fun to build.

However, the quicker and more fun something is to build, the lower the barriers to entry. A quick Google reveals hundreds of similar tools, and extremely well funded juggernauts like Gong and Hyperbound have built fully fledged versions of this in the name of sales enablement.

With that said, I'm proud of the functionality. All built on Lovable, and affectionately known as Igi, from the Japanese word for "to object". 

It started purely as objection handling roleplay, but then progressed to various practice types, and then I built structured training programs with the view of creating a tool that could provide tailored and structured onboarding for new team members.

A few things I learnt building it:

It is absurdly easy to get to MVP via Lovable. That includes the backend, multiple user logins, integrations like Google sign in, connecting to ElevenLabs for the voice agents, and even Stripe for free trials and paid usage by seats.

It is much harder to decide what not to build than what to build.

The more features you build, the harder it is to maintain, the messier it becomes, the harder the narrative becomes and the more difficult the bugs are to resolve. In a world where building is effortless and ubiquitous, discipline is critical.

The below is a screenshot of the Model Answer Library I built (and by "I", I very much mean: Lovable) - using a competitor objection in the AI roleplay space as an example. The thinking behind a Model Answer Library is that most sales teams have a google doc with several objections shared amongst the team and best-in-class answers. The problem is, this is representative of "moment in time" best-in-class answers, and usually gets updated extremely rarely. As any product evolves, the objections and the answers should evolve too - and sales teams often get left behind, until they lose a deal to objections they're not comfortable with yet. What if we could reframe objection handling sessions, and Model Answers could be a dynamic page, constantly evolving, and saved objections can be practiced via AI roleplay at any point? The AI can suggest better answers after the roleplay which you can choose to save instead of / alongside your team's existing best-in-class answer. Answers to objections should be constantly changing, and practicing positioning should be a daily practice for the best sales teams.

This is "nice to have", but not necessarily a game changer, internally or as an external product. This ties into the importance of user conversations. As fun as it is to build for an audience of one, if you want to build something that scales, user interviews come before committing to a solution. What problem are you really solving? Ie. Do objection handling roleplays need to be replaced by AI? Will the AI prospect simulatons be better than the human interaction? Can practicing at scale through AI lead to faster ramp times than practicing a few times with your manager or sales enablement in onboarding? Will the conversations be dynamic and realistic enough that they will genuinely prepare AEs for difficult prospect conversations?

Going from "nice project" to "highly useful" is the real challenge. It's very easy to connect voice agents via ElevenLabs. Nailing the system prompts so that each roleplay feels unique, without hallucination, with realistic latency, and with enough logic to simulate an actual prospect is the hard part. That means tinkering with the LLMs inside ElevenLabs to find the balance between speed and the ability to handle complexity, and working through the various latency settings.

The standard UI and UX of a Lovable build is fair to good, but a lot of tinkering is needed for it to stop feeling like a vibe-coded website. I don't think I've nailed it. I'm not a UX expert and I over-rely on asking Lovable to review its own UX.

Using Claude as a product manager to build the spec, then feeding that into Lovable's Plan mode, is the most efficient approach I've found.

Distribution, and specifically integrating into existing workflows, is the most important factor for a successful product in the AI world. I've been toying with Slack as the medium for Igi, to put it inside a user's workflow rather than asking them to visit another tab. I can see how this would lead to higher adoption and engagement, but the challenge would be to find the balance of simplicity (Slack apps should be very easy to use) and value. I'm still not convinced there's enough of a moat there to compete with the large players and their integrations into cold calling tools and CRMs. 

In a world where building anything is possible, making “the adoption experience" exceptional will separate the winners from the losers. This applies for an tool where the goal is internal adoption, or selling externally.

Honourable mentions to simpler tools built through Claude for enterprise deals: 

• ROI Calculator - I've found this to be quite useful for a) internal use for the team to get comfortable with the financial value of the product, and b) to share with the buyer for them to use internally. It's worth noting that buyers are typically skeptical of ROI promised to them, but it is always useful for framing the discussion away from price and towards value.

• Business Case - getting Claude to compile an artefact to be talked through in a meeting (and sent via pdf or slides after) with the information gathered through discovery needed for the Champion to sell internally, based on the main business pains they've highlighted. 

My concluding learnings

Building used to be the hard part. Understanding what to build, what to leave out, and for who to build it now is the key. 

Internal tools are great, but knowing what to operationalize is the hard part. 

External tools are great, but no prospect wants to be overwhelmed with sales assets.

Based on these learnings, I'd argue not everyone should be "a GTM engineer", but everyone should try, test, play, and search for efficiencies for your specific role, your product, your team. 

Be industrious. Have fun. Get efficient at quickly understanding the difference between a fun tool, and something that can lead to real business impact.