Talvenor needed a sales system before it could afford one. Tools like Apollo and a full CRM stack were more than we could justify at zero clients, and our leads were already scattered across email, spreadsheets and memory. So we built our own: the Talvenor Sales OS.
This is the whole workflow, the rules behind it, and the parts that went wrong. The demo on this site uses fictional data.
The problem we were actually solving
We didn’t have a lead problem first. We had a system problem. Every morning we needed answers to five questions:
- Who should we contact today?
- What do we genuinely know about them?
- What message should we send?
- Which follow-ups are due?
- What is actually producing results?
A spreadsheet could answer some of these. None of our tools answered all of them in one place.
Five rules before a single line of code
We set these before building anything. They make the system less flashy. They also make it far more useful in a real business.
- Use free infrastructure until revenue justifies an upgrade. Free tiers are a starting constraint, not a permanent promise.
- Don’t scrape private data. Leads come from our own lists, permitted public sources and manual research.
- Never invent personalisation. If we can’t point to a source, the system doesn’t write the compliment.
- No email is sent before approval. A person approves every outbound message.
- LinkedIn and Instagram stay manual. The system prepares the draft. A person opens the profile, sends it and marks it done.
The workflow, stage by stage
Capture and deduplicate. A lead enters through a CSV import or manual entry. Before anything is saved, the importer shows every row as valid, duplicate or invalid, with a reason. Bad data creates bad outreach, so this step comes first.
Research with evidence. For each lead we save the company’s offer, who they serve, their country, one specific observation, and the source URL that proves it. No URL means no personalisation.
Qualify. The lead gets a fit score from 0 to 100. It doesn’t judge whether the person is good or bad. It judges whether the business is a strong fit for what we offer right now.
Draft. The system turns the saved research into an opening email, two follow-ups and social-message drafts. These are drafts, not messages pretending to be sent.
Approve. Every message waits in an approval queue. We can edit, approve or reject it. Approving an email only makes it eligible for sending. The daily cap, the retry limit and a duplicate-send lock still apply.
Send and follow up. Email goes out through a controlled workflow. Social actions happen by hand. Replies, tasks, calls, proposals and outcomes all return to the same database.
Report and audit. Each meaningful action gets a timestamp. The database is the source of truth. Not Gmail, not a notebook, not an AI assistant’s memory.
What it’s built with
- Next.js for the dashboard.
- Supabase (Postgres) as the single source of truth, with row-level security so every record belongs to one workspace.
- Vercel for hosting the app during validation.
- Claude and Codex as engineering collaborators. They inspected code, proposed database migrations and checked workflows.
That last point came with a lesson. We learned not to treat an AI assistant’s confident sentence as proof. If it said a migration was applied, we checked the database. If it said a build passed, we checked the build output. AI makes the work faster. It doesn’t remove responsibility.
What went wrong
The first dashboard was only a picture. It looked like a product, but nothing was connected. The first real decision was one source of truth in the database.
The app shipped in “demo mode” by accident. A wrong environment file meant the first deployment couldn’t reach the database. We fixed the connection, verified a real login and redeployed.
A small fix broke production. A change to how lead notes were cleaned up missed a second place that used the same field. The build failed, and the live app was down for about fifteen minutes. The fix was simple. The lesson was to check the actual deployment, not just the code change.
We turned off our own automation. An older background task was designed to connect, follow and message people on social platforms automatically. That creates platform risk and removes the final human judgement. We disabled it and made social outreach manual.
What it doesn’t do
It isn’t Apollo. There’s no giant contact database, and there won’t be one until we have lawful data rights and a real reason to build it. It’s intentionally smaller: it solves the daily workflow we actually need before spending money on a larger platform.
The AI can still get research wrong. That’s why every claim needs a source and every message needs a person.
What happens next
The software now has to earn its keep. We’re using it for Talvenor’s own outreach and will publish what happens (the messages we rejected, the replies, the calls and the result), whether it works or not.
If your business has a similar problem, tell us about your workflow. You can also watch the Sales OS demo or check whether your process is ready for AI.
