Building Can Be Easier Than Selling
Balancing selling and building as a founder of an SMB-focused SaaS
Kevin West
7 min read
Abstract
Building Fora pulled me in because it gave me a clean feedback loop that sales usually doesn’t. I could talk to a user, hear exactly what was broken, and turn it into a feature right away. That felt great, especially compared to cold calls, ignored emails, and the general silence that comes with selling. But once I spent more time building than selling, demos dropped, new users slowed down, and I lost touch with what customers actually needed versus what just seemed cool to build.
Where I landed is pretty simple. Building matters, and learning to do it made me better at running the product. It just can’t replace sales. If something needs to be built right now, it should either help an existing customer or bring in a new one. Everything else can wait until after the calls, emails, referrals, and outreach that keep the business alive.
Building can be easier than selling. At least for me. A bug gets fixed or it doesn’t. A cold call gets ignored ninety-nine times before somebody picks up. I’ve done both, and I know which one feels better on a Tuesday afternoon.
I didn’t always know that, though. I came up through sales.
My first real job was freight brokerage. I was on an office floor by about 6 AM with music blaring, working the phones, trying to negotiate the best rate for my clients with truck drivers who, in a lot of cases, barely spoke English. It was loud, it was a grind, and I argued about money, freight rates, gas prices and delivery times all day. I also earned my commission daily, which was a great way to learn fast what a good day and a bad day are worth.
From there I moved into software sales, and it was a completely different world. I still cold called, but now I had every tool on the market at my disposal. The setting was tame. Nobody was blasting music.
Then I went into retail leasing, which was the wild west all over again. A desk, a phone, and the expectation that you’d somehow make something happen. After that, investment sales, which was more structured and more professional on paper. In practice I was still dealing with small mom and pop New York City landlords, and that came with its own set of issues.
Four different sales jobs, and the common thread was that I was a seller and responsible for my own income. I picked up the phone, I heard what people needed, and I tried to close.
Then I learned to build
When I started Fora, I was green. I had no idea how to build anything, so I started working with an engineer who helped me bring the vision to life while I was still figuring out what I even wanted to build. I’d tried a few AI builders on my own, but I didn’t get very far, and I felt shy about trying something new.
Fora still wasn’t getting traction, and that wasn’t on him. I was learning as I went. Then I met a new engineer who encouraged me to get my feet wet with Claude Code or ChatGPT’s Codex.
So I did. I learned a lot of hard lessons, mostly that these tools aren’t perfect. But I also found something I got really into: talking to a customer, hearing exactly what they struggle with, and turning that conversation into a feature. That loop has been fascinating and, honestly, really rewarding.
Quick context on where Fora is. It’s still early and still growing. I built a premium option, and I offer white glove demos and onboarding, because I like talking to my users. I want to understand their problems and have an actual relationship with them. That part of sales never stopped being fun for me.
Why building took over
Some of this is just how I’m wired. I can be impatient. Someone once told me that to make sales work you need short term impatience with long term vision, and I’ve tried to apply that to everything. Sometimes it helps. Sometimes it’s a hindrance, and in this job it’s been both.
An advisor of mine, another founder, told me to act like the business is going to fail every single day. That’s probably healthy at a startup, but it also feeds the urge to fix everything immediately. And users go quiet on me more than I’d like. They ask for something specific, then stop replying and stop using Fora, and I have no idea why. It eats up a lot of mental time and focus.
The clearest example is a new user who uploaded about 1,000 contacts and started building projects right away. Then she asked for a way to upload screenshots of vendors she finds on Instagram or Google, or photos of business cards, so she wouldn’t have to type everything in by hand. So I built it, added AI to it, and made it something I think everyone can use. I excitedly told her it was live. She hasn’t logged in for about three weeks, and she never answered my email about the feature she asked for. Building felt like the direct answer to that kind of silence, and maybe a good distraction from it.
It also developed into a bit of a sales tactic. I’d show Fora to someone on a demo, they’d ask about a feature we didn’t have, and I’d tell them we could build it. Then I’d spend the rest of the day building it and send an email like “Hey, that feature you asked about is live. Feel like creating an account?”
Around then, the engineer I work with had moved on to bigger, more complex features, which meant all the little things started stacking up. The little things still matter, so I started picking them up myself.
What got better
A lot, honestly. I could fix things without a handoff. I could take what a customer said on a Monday and have it live by Tuesday. The product got better and I understood it better. I don’t regret learning to build for a second.
“To make sales work you need short term impatience with long term vision.”
What broke
Sales dropped. Fewer demos, fewer conversations, fewer closed deals, and usage suffered along with them. I also lost visibility into what new customers actually looked like, because I wasn’t talking to enough of them.
I leaned on ads to fill the gap, but I don’t have the budget to run them at a scale that works, and ads were never going to replace cold calling and direct outreach anyway. They’re a counterbalance, and I’d taken away the thing they were supposed to balance.
When I went back to focusing on sales, I booked about five demos in a week or so and picked up 16 new users on free or trial accounts. A lot of them haven’t converted yet, so I can’t call it a smashing success until they do. But usage went up right when selling came back, and that’s real.
The build-it-and-email-them move was effective for a while. Then some users started to give me the impression they thought I was building them custom software because I had nothing else to do, or no other users. That’s my interpretation, not something anyone told me directly. Commitment and dedication are great, but there’s a balance, and past it people get wary, because that level of attention is so uncommon in the market.
There’s a related problem. If you get sucked into building cool features, you can lose track of whether you’re building necessary ones. The distance between those two is bigger than it sounds.
Where I landed
I don’t think there’s a big lesson here so much as a balance I had to learn. The shiny, exciting thing, building the product and making users happy, can’t replace the repetitive, uncomfortable stuff. Sales is a volume game. You might get one sale for every hundred conversations, but that one sale is the thing that pays for everything else. You can build all the product you want, and without revenue it just doesn’t matter.
So I changed the schedule. I still work on the product, and I still enjoy it, but now that happens on Friday evenings and weekends. The rest of the week is cold calling, emailing, Instagram, asking for referrals, and the occasional fight with my own impatience when a feature idea comes up and I have to let it sit.
The engineer I work with gave me a rule I use constantly. If something needs to be built right now, it has to do one of two things: serve an existing customer, or exist specifically to bring in new users. Not “it would be a nice improvement.” General improvements still happen, but they happen in downtime, not during sales hours.
I came up through sales and I’m still a seller. I just had to remember that.
Questions this article answers
If a founder keeps hearing feature requests in demos, how can they tell which ones deserve immediate build time?
The article points to a simple filter: build now only if it clearly helps an existing customer succeed or removes friction for a likely new one. A good test is whether the request comes up across multiple conversations, ties to activation or retention, or unblocks a sale that is already close. A single enthusiastic request, especially from someone who then disappears, is a weak signal no matter how compelling it feels in the moment.
What does the author's experience suggest about using fast product work as a sales tactic?
Rapid shipping can be persuasive when it proves responsiveness, but it can also create the impression that the product is being shaped one prospect at a time. That is useful early if the feature has broad relevance, like importing vendor info from screenshots or business cards, because the work compounds across users. It becomes risky when the turnaround starts to look like unpaid custom development, which can lower perceived product maturity and pull time away from outreach.
Why did sales suffer even though the product was improving faster?
The article shows that better product velocity did not replace top-of-funnel activity. Demos, cold outreach, and follow-up created not just deals but also visibility into what new users actually needed, and when those conversations dropped, usage and conversions slipped with them. In practice, product quality and sales volume were not substitutes, they were linked inputs.