Dear founder,
When you build a software business as a founder, you have a dream.
That dream is to build something that people actually need, that will make you money, and that you can keep building and make better - and make more money as you build it. Maybe there's an extension to that dream where you sell it for millions, or where you build a company that allows you to retire.
But the core of the dream is this: you have a thing that you think needs to be built, you build it, and then people come and give you money for it because they actually need it.
Right. Right!?
A quick word from our Sponsor, Paddle.com. I use Paddle as my Merchant of Record for all my software projects. They take care of all the taxes, the currencies, tracking declined transactions and updated credit cards so that I can focus on dealing with my competitors (and not banks and financial regulators). If you think you'd rather just build your product, check out Paddle.com as your payment provider.
Alright, people paying for your product, that's the general entrepreneurial idea, right? But along the way, you'll realize that this starting point isn't actually the whole story. Along the way, there are so many things that you care about that other people simply don't.
Today, we're diving into a couple of things that might be contentious, maybe polarizing in their ways, but are definitely things that you're over-indexing on that other people do not care about. This is going to be different for every project and every founder, but let me share what I've learned from my own experience building Podscan.
The User Interface Obsession
Let's start with the user interface. I thought, if I don't spend hours, days, and weeks tweaking this interface, people aren't going to use my product.
And lo and behold, people still use it, even though a lot of the things that I want to change - things I feel deserve weeks worth of refactoring - are still sitting in my feature backlog.
People are instead very much focused on using the product to serve their needs. As clunky as it might be, extremely rarely do I ever get any feedback on the user interface. This might be because it's further along, or because it's good enough, or whatever it might be, but nobody's telling me, "Hey, you should really refactor this."
I had one customer - just one - tell me: "In your product, there's a certain kind of behavior that exists in this location, and that location, and that location, and it's slightly different in the fourth location. Could you streamline this? We're getting confused whenever we use this."
That's good feedback, and it's something I still have on the pile. But here's the thing - they're using all four locations! It still works for them, even though it's slightly confusing.
So my focus isn't on rebuilding my interface components. My focus - and this has been my focus with Podscan from very early on, but more now than ever - is making the data that flows into the system as reliable and as usable as possible. Because in the end, that's all that matters: what data comes in, and what of that data is useful.
People care about accurate transcriptions. They care about accurate results for their alerts. They care about reliable API access. Nothing about what it looks like is relevant. People would probably be able to use the very first version of Podscan if the data quality was high enough.
The API Design Trap
Which brings us to API design. As founders, we have this idea that we need to have exactly the finest API. We want an API that people at Stripe would look at and say, "Wow, this is well designed." That's what we want.
People really don't care.
I have hundreds of people who use the Podscan API to power their businesses at this point. One person ever reached out and said, "Oh, I'm trying this API endpoint, and it's weirdly named." And that person? Never converted into a paying customer.
So do I care about this? No. I designed my API well - at least I think so, I hope so - but I do not go overboard in making it the most beautiful thing I've ever seen. Over-engineering is my enemy when I run a software as a service business.
Here's the reality: the first version that is deployed of anything will eventually be depended upon. There's Hyrum's Law - that with a sufficient number of users of an API, it doesn't matter what you promise in the contract. All observable behaviors of your system will be depended on by somebody. Even if I don't explicitly build something into the API, somebody will find it, use it, and then I can't change it.
So I'm not going to go overboard to make this a beautiful thing. The important part is to document it well.
Documentation: Fancy vs. Functional
And even that documentation doesn't have to be great. It doesn't have to be fancy. It doesn't have to be flashy. It needs to be text that you can copy and paste and throw into an AI. That's pretty much what it is, honestly.
If you build anything and you build documentation, just make it accessible. Make it so that people can copy it, can copy and paste it, can run it, throw it into Claude or ChatGPT to get the gist of it or a code example. Make it easily accessible. Don't make it a JavaScript single-page app that can't be scraped or parsed by OpenAI or Anthropic.
You want something that people can pull very easily into their development chain, so they can use your documentation - your source of truth - as a data foundation for their agentic or real coders.
When it comes to user-facing documentation, people don't really care what your documentation looks like either. It can be a standalone help desk software like Intercom's knowledge base, or what I use, Crisp. There's also Knowledge Owl and many different systems that allow you to set up a help desk.
But initially? My help desk was a couple of Notion pages turned public and linked from my application. And still, in some parts, I have public Notion pages. I have a section in my Notion organization that's called "Public - Do Not Delete," and links to all the individual pages in there are littered across the application.
It makes it extremely easy to update. It makes it extremely easy to write. I even have a Notion proxy running on a Cloudflare Worker that pulls this data to a specific URL so it looks like it's under my own domain. That's an additional step that's not really necessary, but it's kind of cool.
The point is: have documentation that's easy for you to write. Because people will read it if they really need a solution to their problem and they've already seen the value of the business. They'll go through the step of reading a weird website or trying to find exactly what they need in a convoluted document.
You need to have an easy time writing it as a founder, and people will bite the bullet to search. Any documentation, any knowledge base, is better than none. And the one that you create and maintain for your customers is going to beat the one that your competitor doesn't have, or that your competitor auto-generated but never updated since the last patch two years ago.
The Interoperability Illusion
Another thing - and this might be different between businesses depending on your audience's professional expectations - is interoperability.
You'd think that people really care about being able to import Excel files or files in proprietary data formats used in their industry, and export the exact same file format or something else that goes directly into the machines that produce their merchandise or whatever.
But that's really not what people expect from software as a service platforms. That's what they expect from standalone, installed, hyper-specialized, super expensive, fully-fledged software suites.
From a SaaS, people have a minimal - almost maximum - expectation: Does it handle CSV or Excel sheets? Can I import a spreadsheet, select the things that I want, and it pulls it into the program? Can it export a spreadsheet that I can then take to my next software?
That's all they want. The fancier you get, the more you have to support. But people have found ways to turn Excel files or the even simpler comma-separated value file - the CSV - and import that into anything they need and export it from anything they need. As long as you have that baseline of a CSV export in whatever is relevant to your customers, you're pretty good for input/output.
It's surprising because you think the more you support, the cooler it looks. But that's really engineering you can do at a later point. It's not required. People don't care.
Customer Support Reality Check
Customer support is something I've changed my mind on over the past few years. In the beginning, I thought, "Hey, you need to have chat. You need to be there within seconds for your customers to delight them."
And it's still true - it's really cool to see somebody go, "Wow, you responded within a minute to my customer service outreach! That's amazing! That never happens to me. Are you a bot?" That's what I get now more than ever: "Are you an AI?"
But honestly, I don't think I need the chat thing to be real-time in the first place. People are fine with email, particularly the higher you go up the corporate customer ladder. When you work with enterprise, most communication between you and your prospects and customers is going to go through email anyway.
Having a customer service system that just goes to email - and maybe live action, but only when you initiate it - works perfectly fine for most software as a service businesses.
Here's the truth: People who expect to be helped immediately for something that costs them 10 bucks a month are likely not good customers to serve anyway. But somebody who's paying 200 bucks a month and is fine with a day or two of delay between emails? That's suddenly a much easier, much less annoying, and much more gratifying customer to serve.
Consider that in the beginning, it's useful to build that initial relationship with your customers. But the moment you have some kind of repeatable process, turn off the real-time chat - only use it when you need it - and have everything else go through email. It's always good to have a paper trail anyway. You can bounce these emails up and down if you need to, delay them or have them come back to you in a couple days if it's not pressing right now, and just delete them if they don't work out.
The more professional your customers are, the more they know that you're busy and won't expect a sub-minute response time. It still delights. It's still great. But it's not a requirement.
The Bottom Line: What Actually Matters
So if you think about it, what people need is something that helps them get their jobs done without having to bend over backwards to make it happen.
Provide common and expected input/output formats. Have a reliable and well-documented system - both the user interface and any programmatic interfaces you might have. Have reliable and expectable response times with your customer service.
Do these things, and you're pretty good with most industries and most people who will gladly pay for your service over time.
The lesson here isn't to build bad software. It's to recognize that as a solo software entrepreneur, you have to do the 80/20. And the 80/20 clearly is in "works well enough and is super well documented," not in "beautiful, long-term, hyper-maintainable, hyper-scalable" perfection.
Your customers are using your product to solve their problems, not to admire your craftsmanship. They want reliability over refinement, functionality over fanciness, and results over architectural beauty.
Build something that works, document it so people can use it, be there when they need help - even if not instantly - and keep making the core value proposition better. That's what matters. That's what people pay for. Everything else? That's just founder vanity.
And recognizing this difference between what we care about and what our customers care about - that's one of the most important lessons in the journey from founder to successful entrepreneur.
We're the podcast database with the best and most real-time API out there. Check out podscan.fm — and tell your friends!
Thank you for reading this week's essay edition of The Bootstrapped Founder. Did you enjoy it? If so, please spread the word and share this issue on Twitter.
If you want to reach tens of thousands of creators, makers, and dreamers, you can apply to sponsor an episode of this newsletter. Or just reply to this email!
No comments:
Post a Comment