I have been selling SaaS in Latin America for over 12 years. Enterprise deals, mid-market, SMB -- I have worked every segment across Mexico, Colombia, Brazil, and Chile. I have used every CRM you can name: Salesforce, HubSpot, Pipedrive, Copper, Close, Freshsales, and at least a dozen more I am actively trying to forget.
Every single one of them was built for someone else. Salesforce was built for enterprise ops teams with a full-time admin. HubSpot was built for marketing teams who happen to also sell. Pipedrive was built for European SMBs in 2010 and has not fundamentally changed since. None of them were built for how I actually sell: fast, scrappy, relationship-driven, deeply personal, and increasingly AI-assisted.
In late 2025, I decided to stop complaining about CRMs and build one. Not hire a team and raise money and spend 18 months in stealth mode. Just me, AI coding tools, and the 12 years of sales experience that told me exactly what a CRM should do. Five weeks later, SalesSheet had 61 features and was handling real sales data. This is what I learned.
I did not set out to prove that one person could build a CRM. I set out to build the CRM I wished existed. The fact that AI made it possible for one person to do it was a byproduct, not the goal.
I am not a traditional software engineer. I can write code, but I am primarily a salesperson who codes, not a programmer who sells. Before AI coding tools, building a CRM solo would have taken me 12-18 months of learning, building, debugging, and rebuilding. The quality would have been mediocre because I simply do not have the depth of expertise in frontend architecture, database design, and API engineering that a senior full-stack developer has.
AI changed that equation in a fundamental way. Tools like Claude and Cursor do not just autocomplete code -- they act as a senior engineering partner who is available 24/7, never gets tired, and has expertise across every technology stack I need. Here is how I actually used them:
Before writing a single line of code, I described every feature to Claude in plain English. "I need a pipeline board where users can drag deals between stages. Each deal shows the contact name, deal value, and days in stage. Clicking a deal opens a detail panel." Claude would respond with an architecture recommendation, component structure, database schema, and sometimes the actual implementation.
The key insight: I was not asking Claude to build something I could not imagine. I knew exactly what I wanted because I had used dozens of CRMs. I just needed an engineering partner to translate my product vision into code. That is a very different use case from "build me something cool."
Cursor was my daily coding environment. The AI-assisted editing was useful, but the real value was in debugging and refactoring. When something broke -- and things broke constantly -- I could describe the symptoms and Cursor would trace through the code, identify the issue, and propose a fix. Problems that would have taken me hours to debug solo took minutes with an AI pair programmer.
My workflow settled into a pattern: describe the feature to Claude, get the architecture, implement it in Cursor with AI assistance, test it, fix the bugs with Cursor's help, move to the next feature. On good days, I shipped 3-4 features. On bad days, I shipped 1. The velocity was extraordinary compared to what I could have done alone.
Here is a partial list of what I built in those first five weeks:
Was every feature production-perfect on day one? No. Some had rough edges. Some needed iteration after real user testing. But the core functionality worked, and the architecture was clean enough to iterate on without rewriting everything. That is the difference between using AI as a crutch and using AI as a multiplier -- you still need taste, judgment, and domain expertise to guide the process.
There is a narrative in the indie hacker community that AI makes product development so easy that anyone can build anything. That is dangerously wrong. Here is what AI could not do for me:
AI did not tell me which features to build, what to prioritize, or how the product should feel. Those decisions came from 12 years of selling and using CRMs. I knew that pipeline velocity matters more than pipeline value because I have seen teams obsess over total pipeline while their deals stagnate. I knew that email threading should show the full conversation because I have watched reps waste time reconstructing email context. AI can build features -- it cannot decide which features matter.
AI-generated code is functional but rarely beautiful out of the box. Every UI component needed my eye to adjust spacing, typography, color, and interaction feel. The difference between a CRM that feels professional and one that feels like a hackathon project is in the details: the animation timing on a dropdown, the padding around a deal card, the weight of a heading font. AI does not have taste. You do.
When a beta user told me "the pipeline board feels overwhelming," that was not a bug report. It was a design problem that required understanding what "overwhelming" meant to that specific user in their specific workflow. AI cannot sit with a user, watch their eyes glaze over, and intuitively understand that the issue is information density, not functionality. User empathy is irreducibly human.
Building a CRM without sales experience is like building a guitar without playing music. You might get the shape right, but the instrument will not resonate. Every design decision in SalesSheet is informed by thousands of sales calls, hundreds of lost deals, and the specific pain of using a tool that does not understand how selling actually works. AI cannot replicate that lived experience.
AI is the best engineering partner a solo founder has ever had. But a partner is not a replacement. You still need the domain expertise, product taste, and user empathy that only come from years of doing the work.
Even with AI accelerating development, building solo is hard in ways that have nothing to do with code:
When you are solo, every decision is yours. That sounds like freedom, but it is actually a trap. There is no one to challenge your assumptions, push back on your ideas, or catch your blind spots. I compensated by writing down my reasoning for every major decision and revisiting those notes weekly. Sometimes I realized I had been wrong for days and needed to backtrack.
On any given day, I am the product manager, the engineer, the designer, the support rep, the marketer, the sales rep, and the accountant. Context-switching between these roles burns energy. I found that batching similar tasks (all marketing writing on Monday, all engineering on Tuesday-Thursday, all user support on Friday) helped, but the cognitive load never fully goes away.
This one does not get talked about enough. Building alone means celebrating alone, worrying alone, and solving problems alone. When a feature ships perfectly, there is no team to high-five. When a bug takes down the demo, there is no one to debug with at 2 AM. I am fortunate to have a supportive community of other indie hackers, but there are moments when the isolation is real.
Looking at the git history now -- over 120 commits in those first five weeks -- a few lessons stand out:
SalesSheet is not finished. It will never be finished. But it is real, it is useful, and it was built by one person who got tired of using CRMs designed by people who have never sold anything. If you are a sales rep frustrated by your tools, or an indie hacker thinking about building in a "crowded" market -- the tools have never been better, and the excuses have never been fewer.