The Bootstrapped Founder

Arvid: 00:00

Hey, it's Arvid, and this is the Bootstrap Founder. When you build a software business as a founder, you have this dream. Right? The dream is to build something that people actually need, something that they want and something that will make you money and that you can keep building and make better and make more money as you build it and make it better. And 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.

Arvid: 00:30

But the core of the dream, the interesting part, I mean, everything is interesting, but what is interesting right now is that you have a thing that you think needs to be built. And then you build it and then people come and give you money for it because they actually need it. Now that is a dream. Quick word from our sponsor here, paddle.com. I use them as my merchant of record for all my software projects.

Arvid: 00:55

They take care of my taxes, currencies. They track declined transactions, and they update credit cards in the background so that I can focus on dealing with my product and my competitors and my customers and not have to deal with banks and financial regulators. I don't really like interacting with them at all. So it's nice that Paddle takes care of this for me. So if you think you would rather just build your product at work on that dream, and we will see how realistic that is, the dream, not working on it, check out paddle.com as your payment provider.

Arvid: 01:27

People paying for your product is not just a dream, right? That's the general concept of entrepreneurship. But along the way, you will realize that this starting point isn't actually the whole story. Along the way, there are a lot of things that you care about personally that other people simply don't. So today, I wanna demystify this dream.

Arvid: 01:49

I think we should be diving into a couple of things that might be contentious, polarizing in their ways, but are definitely things that you as a founder are over indexing on, that other people just don't care about. It's kind of a a warning to not do certain things even though they feel like the right thing, but they're not. This is obviously going to be different for every project and every founder. But what I have learned from my own experience building Potscan and the other SaaS businesses in my life. Let's start with the visible part, the user interface of a software product.

Arvid: 02:23

I thought if I don't spend hours or days or weeks tweaking this interface, people are not gonna be using my product because they have high expectations. That's what I thought. And lo and behold, people still use it, even though a lot of the things that I wanna change, things that I feel deserve weeks of refactoring, have been sitting in my feature backlog for months, if not years at this point. People are and I perceive this through the conversations that I have with them in customer service, they're very much focused on using the product to serve their needs. And as clunky as it might be, extremely rarely do I ever get feedback on the actual user interface.

Arvid: 03:01

People just don't tell me about this kind of stuff. Might be a perception problem. They might not even understand it as something that they can complain about. But that also might be because it's further along or because it's good enough. But nobody's telling me, hey, you should really refactor this.

Arvid: 03:16

And nobody will ever tell you this unless you build a refactoring tool for people who refactor all day long. Then they're probably going to talk to you about refactoring and maybe suggest stuff for your own software. But customers don't look at it like this. Right? They see, does it work for me?

Arvid: 03:31

Does it work for me somehow? And if it does, then that's fine. If it doesn't at all, then they will come. So I had one customer, just one, tell me in your product, there's a certain kind of behavior that exists in this location and then in that location and in that location, and it's slightly different in the fourth location. Could you please streamline this?

Arvid: 03:51

We're getting confused whenever we use that. And I think this is really good feedback. It's interface feedback. And it's something that I still have on the pile. I've got to be honest.

Arvid: 04:02

But here's the thing. They're using all four locations. Right? It still works for them, even though it is slightly confusing. It's not that they really complained about it.

Arvid: 04:12

It was kind of the consequence of a longer conversation that we had when I asked them, is there anything that comes to mind that should be changed, should be different? So I was kind of pulling at it, and that is what came to mind. It was the only thing really that they had that they could give me as feedback because the other things didn't even register as potential problems. So my focus in POTScan and also in the other products that I had before is never really on rebuilding interface components. Once they're built, they tend to work.

Arvid: 04:41

They might be adjusted a little bit. They might need some sort of like redesigning or even just re rephrasing of certain things that makes things much easier. It never really is a design issue. It always is an issue of wording of the phrase that is used for buttons, for names, for features, for sections. But my focus, and this has been my focus with PodsGamp in particular from early on, but more now than ever, is making the data that flows into the system as reliable and usable as possible.

Arvid: 05:12

Because in the end, to my customer, that's all that matters. What data comes in and what of that data is useful. Because for Podscan, which is a podcast monitoring and podcast data service, people care about accurate transcriptions. They care about accurate results for their alerts. They care about reliable API access.

Arvid: 05:32

Nothing about what it looks like is relevant. Like my API docs are pretty nice, but they could be so much nicer. That's another thing I have on my backlog is I build fancy API docs, but people already are using the API as it stands and they are using it well at that. So that is not worth putting my time on, even though I see the Stripe API docs and I'm thinking, oh my, this is what I want. Or I look at some open source projects that have spent years of making this developer friendly and I'm like, oh man, I wish this was easy.

Arvid: 06:04

But it's not, and it's really not worth it. It is not relevant. People would probably be able to use the very first version of Podscan and the API and UI if the data quality was high enough. Could still be the weird thing from early twenty twenty four that didn't have all the changes I've added since and people would still find it valuable. Which brings me to not just the visual part, but the API design, the structural design of a software application that is consumable by other machines.

Arvid: 06:34

As founders, we have this idea that we need to have exactly the finest API. Right? We want the API that people at Stripe would look at and say, wow, this is well designed. That's what we want. At least that's what I want.

Arvid: 06:45

But people really don't care. I have hundreds of people who use the Podscan API to power their businesses at this point. And one person reached out and said, I'm trying this API endpoint and it's weirdly named. And that person never converted into a paying customer. And, well, I did look into this and it was a little issue of me using capitalization in an API route for some reason.

Arvid: 07:07

That was really strange. So like an API route that had like an uppercase character in it and the lowercase version of it didn't work, but the uppercase, like slightly uppercase version did. So I kind of try to adjust it a little bit. But in the end, these kind of things, super on the back burner. I don't really care about this.

Arvid: 07:26

My API is designed well, I think, but I do not go overboard in making it the most beautiful thing I've ever seen. Overengineering, I think, is my enemy when I run a software as a service business because I come from a technical background. I want things to be perfect. But the reality is that the first version that is deployed of anything will eventually be depended upon by somebody. There's something called Hiram's Law, and I think I made an episode about this in the past, that with a sufficient number of users off an API, it doesn't matter what you promise in the contract, all observable behaviors of your system will be depended on by somebody at some point.

Arvid: 08:05

So even if I don't explicitly build something into the API or if I build it and don't document it or if I just build it because I want to keep it for a little bit, then maybe change it, somebody will find it, use it, and then I can change it. So I'm not going to go overboard in making this a beautiful thing and changing things along the way. The important part is to document it well. And if I need to change it, I must change it in a new version. That's where versioning comes in.

Arvid: 08:34

And that is the moment I go from v1 to v2 is when I will do another Passat API design. Probably. Probably not in the next couple of months because it's working perfectly fine. And particularly now that you have documentation for it that is automatically generated, and let's be honest, likely automatically ingested and worked upon by things like Cloud Code or Codecs or any kind of coding tool, these agentic coding systems, it's probably more important to be accurate in describing your API than in making it perfect and, like, aesthetically pleasing. Because documentation will be consumed.

Arvid: 09:13

AI systems will try to build it. They will test it. They will try to adhere to full exports of the JSON schema of an API or something. They will figure out how to use it and get the data that they need. And for humans to interact with, you have written documentation that can also be automatically generated by these systems.

Arvid: 09:32

And this 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 a plot code or any AI system. It's pretty much what it is, honestly.

Arvid: 09:43

If you build anything and you build documentation, just make it accessible. Make it so that people can copy it, copy paste it, can run it, throw it into ClotChat GPT to get the gist of it or a code example. Make it easily accessible. Do not make it this JavaScript single page app that can't be scraped or parsed by OpenAI or Anthropic. This will be an actual drawback for adoption of your system.

Arvid: 10:05

You want something that people can pull very easily into their development chain so they can use the documentation, your source of truth, because they don't have the source code, they have to rely on the docs as a data foundation for the agentic or the real human coders. So when it comes to user facing docs, people don't really care what their documentation looks like. It can be a standalone help desk software like Intercom's Knowledge Base or what I use, Crisp. There's Knowledge Owl, which is a really cool company. I had their founder on my podcast a couple months ago, maybe a year ago at this point.

Arvid: 10:37

There are many different systems that allow you to set up a help desk and some kind of docs. That's like the user facing documentation, right, not the developer facing one. But initially, my help desk for BotScan was a couple of Notion pages turned public and linked from my application. I really just like share on the web, took this weird link with the weird prefix that's still in there and put it in my app. You clicked on it, you opened Notion.

Arvid: 11:01

Still, in some parts, I have public Notion pages for my docs. I have a section in my Notion organization that is called public do not delete. So I have this little red alert flashing light in this, so I choose not to move or delete it. And in there are all the individual pages that are littered across the application realistically. It's just honest at this point.

Arvid: 11:22

And they're linked between each other and from the app. And that makes it extremely easy to update. I can write updates in real time. I even have a Notion proxy running on a Cloudflare worker that pulls this data to a specific URL and caches it so that it can be accessed as if it was on my own domain. That's something really, really cool that you can do.

Arvid: 11:44

Just Google for like Notion proxy Cloudflare worker, and you can set up very easily a worker that would just pull the ID of a Notion page, and you can connect that to your domain. And all of a sudden, you have like docs. Your domain.xyz slash that ID, and it will pull live from the Notion page or cache it for a couple minutes until you refresh it. It's really, really fun. And you can do a lot of stuff.

Arvid: 12:10

It effectively renders Notion pages directly in HTML. You can include it somewhere. You can embed it. You can just share it. It's it's fun.

Arvid: 12:18

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 your business. So that's the kind of inspired person that will look for docs. They'll go through the step of reading some weird website or trying to find exactly what they need in a convoluted document because they're already bought in. You need to have an easy time writing that thing as a founder and people will bite the bullet to search. Any documentation, any knowledge base is better than none.

Arvid: 12:48

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. Another thing, and this might be different, really different between businesses depending on your audience's professional expectation, is interoperability. You'd think that people really care about being able to import Excel files or files in proprietary data formats used in the industry and export the exact same file format or something else that goes directly into the machines that produce 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.

Arvid: 13:32

But from a SaaS, people have this almost maximum, I guess, expectation. Like that's the ceiling. Does it handle CSV or Excel sheets? Can I import a spreadsheet, select the things that I want and pull it into the program? And can it export a spreadsheet that I can then take to my next software?

Arvid: 13:49

That's really all they want. The fancier you get in terms of the formats you support, the more you have to eventually implement and maintain. But people have found a lot of ways to turn Excel files or even simpler comma separated value files to CSV and import and export that into anything they need and export it from anything they need. As long as you have that baseline of a CSV export and import in whatever is relevant to your customers, you're pretty good for input and output. It's surprising because you would think the more you support, the cooler and better it looks, but that's really engineering you can do at a later point.

Arvid: 14:25

It's not required. People don't really care. Unless, of course, you're in an industry that creates video or something. Right? Obviously, if people expect the video to come out of this, you can't supply a CSV file.

Arvid: 14:39

But that is something really specific. For most transitional data things, these formats are absolutely sufficient. Customer support now is something that I've changed my mind on over the past few years. In the beginning, I thought, yeah, you really need to have a chat. You need to be there within seconds for your customers to delight them.

Arvid: 14:58

And I think it's still kind of true. It's nice 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?

Arvid: 15:08

Are you AI? Well, that's what you get now more than ever. Right? Like, you must be AI. This is way too fast.

Arvid: 15:15

But honestly, I don't think you need to have the chat thing to be real time in the first place. People are fine with email, particularly the higher up you go 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. So having a customer service system that just goes to email and maybe live action, but only when you initiate it with that particular customer works perfectly fine for most software as a service businesses. Because here's the truth.

Arvid: 15:42

People who expect to be helped immediately for something that costs them $10 a month are likely not fun customers to serve anyway. But somebody who's paying 200 or $2,000 a month and is fine with a day or two between emails, that's suddenly a much easier, much less annoying, and much more gratifying customer to serve. So consider that in the beginning, it's useful to build that initial relationship with your customers, be there for them. But the moment you have some kind of repeatable process, turn off that real time chat. Only use it when you need it and have everything else go through email.

Arvid: 16:15

It's always good to have a paper trail anyway. Chat tools have this internally. There is an audit trail. But you can bounce these emails up and down if you need to. And you can delay them or have them come back to you in a couple of days if it's not pressing right away or just delete them if they don't work out.

Arvid: 16:31

The more professional your customers are, the more they will know that you're busy just as they are and won't expect a sub minute response time. It still delights if you're there. It's still great, but it's not a requirement. So if you think about it, what people need is something that helps them get their job done without having to bend over backwards to make it happen. Provide these common and expected input output formats because that is what every job to be done has.

Arvid: 16:56

Right? Every job to be done has a starting point and a final point of a result that people want. They have an input and an output. If you can support this and if people have expectations, well, do that. Right?

Arvid: 17:07

That's what helps people map their process into your tool, and then they have a good reason to use it. So have this reliable and well documented system, both the user interface and any programmatic interface you might have, and have a reliable and expectable response time with your customer service. Do these things and you're pretty good with most industries, and most people will gladly pay for your service over time. So the lesson here, obviously I hope you understand this, is not to build bad software or incomplete software. It's to recognize that as a solo software entrepreneur, you have to do eighty twenty all the time.

Arvid: 17:41

And the eighty twenty clearly is in works well enough and is super well documented, not in beautiful long term hyper maintainable hyperscalable perfection. That's just not feasible. Your customers are using your product to solve a problem they have, not to admire your craftsmanship, like some do, and people will over time heighten expectations there. They want reliability initially and the refinement later. Functionality first, fanciness later.

Arvid: 18:09

Right? Results matter more than architectural beauty. So build something that works, document it so people can use it and their AIs can use it, and be there when they need help, even if not instantly, and keep making this core value proposition better, the thing that actually matters, right, the thing that people pay for. Everything else, that is founder vanity, And you have to kind of fight that. Recognizing the difference between what we care about as founders and what our customers care about, that's one of the most important lessons in the journey from founder to successful entrepreneur.

Arvid: 18:40

And that's it for today. Thank you so much for listening to the Books of Founder. You can find me on Twitter at arvid kahl, a r v I d k a h l. And if you are feeling that you're missing critical conversations about your brand on podcasts, Podscan monitors over 4,000,000 podcasts in real time. It's crazy to see the alerts and transcriptions coming flowing into system, and PodScan will alert you when anybody mentions you or your brand.

Arvid: 19:03

So you can turn this unstructured podcast chatter into competitive intelligence and actual meaningful customer insights with our API. So if you're a founder who's searching for your next venture, you're looking for ideas, ideas. Podscan.fm helps you discover validated problems right from the conversations in the market. We identify opportunities for startups from hundreds of hours of expert discussions daily so you can build what people are already asking for. So share this with anyone who needs to turn conversations into a competitive advantage.

Arvid: 19:33

Thanks so much for listening. Have