Shared Chat
Tools for non-technical founders

As a non-technical founder, there are several tools and strategies you can use to help you succeed:

  1. Seek support and guidance from communities and mastermind groups . These groups can provide accountability, advice, and encouragement.

  2. Consider using no-code or low-code tools to build your product without having to write code . These tools allow you to create fully-featured mobile apps and websites through configuration. Some popular options include Bubble, Webflow, and WordPress .

  3. Outsource tasks that you are not proficient in or don't have time for. Look for freelancers or agencies who specialize in the specific skill set you need .

  4. Don't be afraid to delegate and hire help, even if it means letting go of control. Hiring experts in areas such as design, development, or customer support can free up your time to focus on other aspects of your business .

  5. Document your processes but avoid getting stuck in perfectionism . Start with simple documentation and adapt it as your business evolves.

  6. Connect with other non-technical founders and share experiences . Join online communities, attend events, or listen to podcasts dedicated to non-technical founders.

Remember that every founder's journey is unique, and it's important to find what works best for you and your specific business . Good luck!

1
(someone): And then it makes me think, well, why haven't I? What have I actually been doing? And stuff like that. So I do think it's helpful. It's kind of like a mastermind, in a way.
Arvid Kahl: Yeah, it's an interesting accountability setup, right? You kind of force yourself to show up and you force yourself to have something to provide. It kind of reminds me of, and that's one thing that I see a lot in like solopreneurs, like imitating things that they would do in a bigger team or building structures that are similar to what they would be doing if they were employed. If you have any programming environment, you have these sprint meetings and you have retrospectives where you look into what you've done, what you're going to be doing, you're going to estimate how long it will take. You don't really have that if you're a solopreneur. Or in any regard, if you run your own business, you have nobody that will tell you how long this should be taking. other than yourself. So it's really nice to have somebody to talk to about this. I've seen this work for a lot of people. That is really interesting. With Nathan being a non-technical founder as well, do you sometimes wish there would be more technical insight into your stuff?
2
(someone): And, you know, we were talking earlier about having the mastermind, which is actually a podcast. But just having someone to talk to about these things I think is really helpful because they can maybe advise you okay I think you're not hiring because XYZ and I think you should do this because reason and then yeah it kind of gives you that extra push that you need.
Arvid Kahl: I think it's, like I said, a great accountability tool and I think the wonderful thing about a podcast is that you are doing this in front of other people. So you have the potential not just to have somebody be your sounding board for ideas or your mirror if you need them to be or the feedback generator that you need at that point to get motivation to do something, but you're also building an audience. at the same time and you're building an audience from a place of authenticity and genuine vulnerability because everything you talk about where you're not sure gives people insight into your decision-making process and how you approach not just winning But how you approach building, how you approach experimenting, and that I feel makes build such connection with people. And you've been an audience builder for a while. It's not the first time you dabble in creating a bigger audience around yourself. So let's kind of talk about that, because I think audience building is on everybody's mind. Everybody and their dog is building an audience at that point, almost quite literally, if you go to Instagram. So has that been a choice that you consciously made when you went into the Non-Tech Founders Podcast with Nathan to build an audience around that particular aspect of yours?
(someone): So for me, it wasn't so much.
3
Arvid Kahl: Today, we call them no-code solutions. These tools range from fully-featured platforms with which you can create fully-featured mobile apps to integration tools that glue together other platforms. No-code means that you can build things just by configuration without having to write code, but most no-code tools allow you to extend functionality by adding code snippets, and projects with this hybrid approach are called low-code services. Really, no matter what you end up doing, you will have to deal with limitations and dependencies at some point. Building everything yourself means you have to maintain and update your product all the time, but you may be the most flexible. Using no-code tools means you can build something solid very quickly, but you'll notice that you're restricted by what the platform allows you to do. Eventually, almost every SaaS business ends up being a fully code-based project. But you can start with something less complex for sure. Learning how to code is not necessary to get the ball rolling, but you want to become or find a developer when the pre-built solutions are too limited for your entrepreneurial vision. That really depends on your product. And you need to communicate that vision. Every SaaS business has a landing page, a website, or an app store listing dedicated to convincing prospective customers to try out and eventually purchase a subscription to your product. Landing pages can be anything from a handmade HTML page to a no-code-based blog engine like WordPress or Webflow. If you want to have an easy time in the future, make sure that the landing page is deployed independently from your actual SaaS product.
4
(someone): Presumably there are other people who aren't developers that want to do what we're doing. So it would be really good to be able to talk to them. But also I feel like it's really helpful to developers because we're not going to be talking about things that typical developer podcasts are going to be talking about. We're not going to be focusing on the technology as such and all that kind of stuff. So we're going to be talking more about marketing and design and all that kind of stuff. I feel like it could speak to a lot of different people. It's really early days with it though. So it's hard to know, you know, I feel like we're still finding our feet with it. But I'm optimistic.
Arvid Kahl: Well, and I think you can be, because I listened to the podcast a couple episodes, and it's really nice. It's actually quite the breath of fresh air in a field where people quite quickly derail into these kind of tech stack conversations, where they are, oh, JavaScript, Python, whatnot, right? Where you, as a listener, if you're technical, it's not even interesting for technical people to listen to. Because it's just, you know, these kind of infights between technologists where they have their preferences and they just argue pointlessly about the benefits of a particular technology, where all the benefits of this tech are usually in how you apply it to the problem, and if it fits, right? So it's these weird kind of almost religion-style conversations that people are having. And I found none of these in the non-tech founders podcast.
5
(someone): think for themselves at any point, because they're so used to getting everything laid out for them. And so then if something crops up that is slightly out of what was written, they'll just say, ask you and you'll have to, you know, write more documentation or something like that. So it can, I found if you're too thorough with that, it can backfire. So I, what I try to do now is I try to get the person I delegate to, to create their own documentation for them. So I'll give them, I'll say, you know, you can use Trello or Google doc or whatever you want, but I have to also be able to see it. Um, and just put this in whatever format works for you. And that's part of their job. Um, I'll also do things to help, you know, like I'm, I'm really good with my email. I do a lot of saved replies. Um, so I use help scout and you can just have the little templated replies for a lot of the common questions. I, I write things down a lot. I take notes. It's nothing fancy. Honestly, it's like a Google spreadsheet and it looks hideous. It's horrible, but you can find things in it. And that's another thing that I do to help. But yeah, I'm not overly processed with it at this point.
Arvid Kahl: I guess that's also something you need to establish.
6
Arvid Kahl: Hello everyone and welcome to the bootstrap founder. Today I'm talking to Laura Elizabeth. She co-hosts the non-tech founders podcast and runs several products as a non-technical founder. We'll talk about outsourcing, building trust and building an audience around your business. Here's Laura. So you're co-hosting the non-tech founders podcast and that is something that I find amazing because in our developer-centric indie hackers community, I think there are far too few voices for the non-technical founders. And I'm glad you're doing this and I'm glad you're talking about these topics. Is it hard for a non-technical founder to even communicate to technical people? How do you find this? Has this been something that has been troubling you before that caused you to start this podcast?
(someone): Sort of yes and no. So I feel like most people I know in this space are developers and I don't know if that's just luck or if that's just how it is or if there's just more developers who are building software products, more indie kind of software products. And there wasn't really many people like me who didn't have that technical knowledge that was building something. So my friend Nathan, I think we became friends because we were like the only people that we know who aren't developers doing something like this. So we thought, Presumably there are other people who aren't developers that want to do what we're doing. So it would be really good to be able to talk to them.
7
Arvid Kahl: Hello everyone and welcome to the bootstrap founder. Today I'm talking to Laura Elizabeth. She co-hosts the non-tech founders podcast and runs several products as a non-technical founder. We'll talk about outsourcing, building trust and building an audience around your business. Here's Laura. So you're co-hosting the non-tech founders podcast and that is something that I find amazing because in our developer-centric indie hackers community, I think there are far too few voices for the non-technical founders. And I'm glad you're doing this and I'm glad you're talking about these topics. Is it hard for a non-technical founder to even communicate to technical people? How do you find this? Has this been something that has been troubling you before that caused you to start this podcast?
(someone): Sort of yes and no. So I feel like most people I know in this space are developers and I don't know if that's just luck or if that's just how it is or if there's just more developers who are building software products, more indie kind of software products. And there wasn't really many people like me who didn't have that technical knowledge that was building something. So my friend Nathan, I think we became friends because we were like the only people that we know who aren't developers doing something like this. So we thought, Presumably there are other people who aren't developers that want to do what we're doing. So it would be really good to be able to talk to them.
8
Arvid Kahl: So has that been a choice that you consciously made when you went into the Non-Tech Founders Podcast with Nathan to build an audience around that particular aspect of yours?
(someone): So for me, it wasn't so much. I think for Nathan, it was more because he's starting more from scratch. So he went away for a while and now he's building his audience again. I feel like I have a, an audience that I'm, you know, pretty okay with. It's growing steadily. Um, for me, the reason that I'm doing it is a lot of it, honestly, for fun, because I've always wanted to do a podcast and to see where it takes us. If the audience growth happens, which I hope it does, that can only be a benefit. But yeah, I basically started it more just because I wanted to and it seemed like a good idea. Finance building is something that I, that's how I got my start really because I was a freelancer before, but I didn't really like freelancing that much because I didn't like the time, exchanging time for money kind of thing. I didn't really feel like I had a lifestyle business, which is what I wanted. And I was looking at people with products and courses and all that stuff and I thought that looks more like what I want to do. But I didn't have anything to sell. And I always knew that if I, even if I did have something to sell, who would I sell it to? So to me, building an audience first was the more logical step. And you get people who disagree with that. Some people agree with it, say audience first.
9
Arvid Kahl: You just need to support them. Number two is WordPress. Developers can create themes and plugins that enhance the functionality of this popular content management system. With over 75 million websites built on that platform, WordPress is a popular choice for bloggers and businesses, even non-profits. WordPress plugins are a common Indie Hacker starting point too. They often solve very technical problems, and most new founders coming from a software background have an easy time transitioning into this particular kind of entrepreneurship. Number three is Heroku. Developers can build custom add-ons and apps that extend the functionality of this hosting and deployment platform that is owned by IBM. Many businesses choose to run their software on Heroku, and they need any kind of thing. They need logging, analytics, file uploaders, like the one offered by Colleen Schnettler, who I talked to, and all kinds of developer tools. In our chat, Colleen told me just how hard it was to actually get approved for the Heroku marketplace. And that is a good sign with marketplaces, because once you make it in there, you won't run into copycats immediately. So Heroku is a good choice. And number four is the Google Chrome ecosystem. More recently, paid Chrome extensions have seen some success when paired with a SaaS service on the backend. Tony Dinh's Twitter tool, Blackmagic, is a great example here. The browser extension itself is free, but using the service comes at a price.
10
Arvid Kahl: And it strikes me as something that I always had trouble with. that the first thing that you did was to hire somebody. Look for somebody to do work for you that you don't or were not at that point capable of doing yourself. Because in my engineering mindset, I could do everything. That's kind of what we've been taught in school and university and stuff, or even just on the job that we were doing, what I was doing when I started in the industry as a coder. You can learn everything. Just try to do everything. That is not the same for a non-technical founder, I would assume. So did you make that choice like initially from the beginning that you would hire as soon as possible or did you dabble in, I don't know, no code or trying to do some stuff for yourself to set up the thing that you wanted to build?
(someone): Yeah, so back then, I don't know if no code was really much of a thing. I feel like it's fairly new, so that wasn't an option, but I think even if it was, well, I don't know, to be honest, I think if I could have maybe got something together myself, I probably would have done it that way as well with the same mentality. Well, if I can do it, I should do it. I get to learn about it, it's my product, no one else will understand it the way I do and all that kind of stuff. In the same way, I'm a designer by trade and I don't hire designers because I can do it myself. Maybe I should hire designers, but it would be really hard.
11
(someone): And then it makes me think, well, why haven't I? What have I actually been doing? And stuff like that. So I do think it's helpful. It's kind of like a mastermind, in a way.
Arvid Kahl: Yeah, it's an interesting accountability setup, right? You kind of force yourself to show up and you force yourself to have something to provide. It kind of reminds me of, and that's one thing that I see a lot in like solopreneurs, like imitating things that they would do in a bigger team or building structures that are similar to what they would be doing if they were employed. If you have any programming environment, you have these sprint meetings and you have retrospectives where you look into what you've done, what you're going to be doing, you're going to estimate how long it will take. You don't really have that if you're a solopreneur. Or in any regard, if you run your own business, you have nobody that will tell you how long this should be taking. other than yourself. So it's really nice to have somebody to talk to about this. I've seen this work for a lot of people. That is really interesting. With Nathan being a non-technical founder as well, do you sometimes wish there would be more technical insight into your stuff?
12
(someone): Yeah, and I do speak to a lot of people actually who are trying to start their own businesses and sometimes being super organized and polished I would say is their fallback because they're putting everything together in their business as if they're running a much bigger company than they are. When, bear in mind, they haven't started yet. So, you know, all these things, you're not in a big software company, you don't need to do the, like we were talking about the standup meetings and all the things that people in those companies do, but they're documenting it as if they are. And I can see their thought process in the sense that, well, it's good to do it as you go, because when you need it, it's going to be there, which I think is definitely very true. But I think you can take it a little bit too far because as well, when you start to, when your business starts to grow, um, your processes will just naturally change because you'll realize that you had it wrong or you need to do this. You, your ticketing system is in this software and that doesn't work for you because of X, Y, Z. So you need to move it to something that will work for you that you could never have known beforehand. So I think when you start out, if you can be like as nimble as possible and open to change and maybe move a little bit faster, but then just try to somehow, don't know how, just document the things that are not going to change. And I think that's easier said than done. I'm making it sound really easy, but it's not. But I do see a lot of people get stuck trying to perfect their processes before they move forward.
Arvid Kahl: Yeah, some kind of procrastination at this point, too.
13
Arvid Kahl: I think that's kind of why I'm so reluctant here.
(someone): Yeah, that is really tough. It's, it's just, it's, it's the hardest thing because you have to, you have to, like you said about you changing the process, but you have to, you have to time it right. You have to change it before you need to change it, if that makes any sense. So if you, if you are at the point where you've hired someone, but you don't have the things in place to hire them, which I've done before, I've hired someone when I've been desperate. And I didn't have the processes in place and I thought, well, I'm going to do the processes now that I've hired that I'm going to start them and it didn't work. It was it was probably my worst hire that I've ever had because I hadn't done it before. So I needed to have done it just a little bit earlier. Um, but not too early because if I did it too early, then half the things would have changed and I'd have been redoing it. So it's just, yeah, it's definitely the hardest thing. And I think especially if you're solo, it's even harder because you've got no one to bounce those ideas off and you've got no one to give you different advice. And, you know, we were talking earlier about having the mastermind, which is actually a podcast. But just having someone to talk to about these things I think is really helpful because they can maybe advise you okay I think you're not hiring because XYZ and I think you should do this because reason and then yeah it kind of gives you that extra push that you need.
14
(someone): And you can find those people. Like, I think my developer is that person. Um, I have a support person now who I've gone through loads of support people and the one I have now is super, is just really thorough, way more thorough than actually I was. And I'm so happy with it. So I think it's worth persevering with delegating because it really is important because you can only get so far doing everything yourself. And you never know what unexpected things might crop up in your life. So you might get sick, for example, you might want to go on holiday, you might get burnt out, anything could happen. And you want to know, that's not the time that you want to be hiring. So you want to know that you've got enough in place that if any of those things should happen, everything will be okay. So I do think it's worth persevering with if possible, but it's hard. It's the hardest thing I've done.
Arvid Kahl: Do you have any kind of standard operating procedures, some kind of internal documentation that makes this kind of process easier once you have something to delegate to people?
(someone): Sort of, I've tried being super like documenting everything and sometimes that backfires on me because if you're really thorough with your documentation then sometimes the people you hire will follow that to a T but they won't think for themselves at any point, because they're so used to getting everything laid out for them. And so then if something crops up that is slightly out of what was written, they'll just say, ask you and you'll have to, you know, write more documentation or something like that.
15
(someone): But I do see a lot of people get stuck trying to perfect their processes before they move forward.
Arvid Kahl: Yeah, some kind of procrastination at this point, too. Because you're building process, but you're not building. So a little bit of a problem there. I find one approach that I've found worked for me is to think of the process of how I deal with process as a process in itself. Like, how am I going to approach documentation? Am I going to document everything? Or is just a couple of bullet points and a link enough for now? And over time, with more people involved, well, it's not enough anymore. So I have to change my meta process, and that trickles down into the rest of all the documentation that you have. As you start making things more approachable for people who you need to onboard, or for other people who you give little tiny tasks that give them the opportunity to have a step-by-step for their specific tasks. But the general thing is still nebulous, because it's more for me than for them. You change your process of how you deal with process over time. Again, sounds easy, but change, what does that mean? What is changing a process? In the end, it's a very unique thing, very specific to your unique situation that you're in. Yeah, I guess I don't have advice here either.
16
Arvid Kahl: In the end, it's a very unique thing, very specific to your unique situation that you're in. Yeah, I guess I don't have advice here either. It's just I like your nimble first approach because it just means you have more time to spend on actually doing the experiments that lead to more business success down the line instead of just wasting it documenting.
(someone): Yeah, exactly. It's a difficult balance for sure.
Arvid Kahl: Like anything in business, right? The fact that you don't know the outcome before you see the outcome with everything you do, that kind of makes it hard. And that's, I think, why people retract into this, let's do the documentation first, because that's something tangible. You know that in the end, you're going to end up with documentation and you end up with really nice looking stuff. So you don't have to face the uncertainty of doing things that you're not sure if they're going to work or not. And I think that for me, and I don't want to steal anything away from you here, but for me, that's why I don't hire, because I don't know. I'm so afraid that there might be a mistake somewhere in me hiring a person that I'm not even going to try and see if there might not be a mistake down the line. I think that's kind of why I'm so reluctant here.
(someone): Yeah, that is really tough.
17
Arvid Kahl: And I think you're a person that shows that, that with perseverance and setting up things that work for you, you can get there over time. And hey, even if you don't know right now what it is, I'm going to be following you along that journey to see where you'll end up. And I think this is a great opportunity to just ask you, where can everybody else, people who are listening to this podcast, follow you along that journey? Where would you like them to connect with you?
(someone): Yeah, so I think the best place is probably Twitter, so that's where I spend most of my time online when I'm not working. So you can find me at Laurium, which is L-A-U-R-I-U-M. And if you want to check out the Non-Tech Founders Podcast, we're still early days, but we're just about to record a bunch of new episodes. You can find it, it's the nontechfounderspodcast.com, I think. I feel like I should know that URL, but I don't. And yeah, I'm really excited about that because actually just to go back on my whole audience thing, the other new set of people that I'm really enjoying talking to are people who want to do something similar. To what I've I do which is maybe go from services to products or like build a product business I really enjoy talking about that things like audience building and seeing what people are up to and that kind of thing So yeah, you can check out the podcast there. But yeah, just say hi on Twitter. I'm pretty pretty personable
18
Arvid Kahl: There shouldn't be just the surface anyway. It's nice to see that more and more people choose to be more vulnerable and showing mistakes that they make. And the fact that they are, to a certain degree, not optimally running their business, it's just reality for everyone out there, which is kind of why I'm putting this into this conversation so much, because I feel if people notice that, oh, yeah, everyone is struggling, then their struggle becomes less of a aimless wandering and more of, OK, this is apparently how it is. Fine, let's just keep doing. what we're doing. Let's just keep going. Let's just keep trying to find a solution to this. Even if it's an ugly Google spreadsheet or just a Notion document that you kind of share back and forth and people edit and comment. If that's enough for you at this point, then that's perfectly fine. You seem to be running a business that is doing well enough and mine is doing good too. So it can't be that bad. It's kind of how I feel. It's just balances the perception out there.
(someone): Yeah, and I do speak to a lot of people actually who are trying to start their own businesses and sometimes being super organized and polished I would say is their fallback because they're putting everything together in their business as if they're running a much bigger company than they are. When, bear in mind, they haven't started yet.
19
(someone): Presumably there are other people who aren't developers that want to do what we're doing. So it would be really good to be able to talk to them. But also I feel like it's really helpful to developers because we're not going to be talking about things that typical developer podcasts are going to be talking about. We're not going to be focusing on the technology as such and all that kind of stuff. So we're going to be talking more about marketing and design and all that kind of stuff. I feel like it could speak to a lot of different people. It's really early days with it though. So it's hard to know, you know, I feel like we're still finding our feet with it. But I'm optimistic.
Arvid Kahl: Well, and I think you can be, because I listened to the podcast a couple episodes, and it's really nice. It's actually quite the breath of fresh air in a field where people quite quickly derail into these kind of tech stack conversations, where they are, oh, JavaScript, Python, whatnot, right? Where you, as a listener, if you're technical, it's not even interesting for technical people to listen to. Because it's just, you know, these kind of infights between technologists where they have their preferences and they just argue pointlessly about the benefits of a particular technology, where all the benefits of this tech are usually in how you apply it to the problem, and if it fits, right? So it's these weird kind of almost religion-style conversations that people are having. And I found none of these in the non-tech founders podcast.
20
Arvid Kahl: So what this tells me, your experience now and my experience, or I guess your experience was prior to mine, but both of them suggest to me that if you want to find the right people to hire you and you want to find the right people to hire, just be in communities where people care about the stuff that they do, right? And it sounds a lot like an audience-centric approach to finding clients, customers or employees.
(someone): Yeah, because if you're both a member of the same community, you're automatically going to have something in common, whether it's ideologies or whatever that specific community brings and why you chose it and why you participate in that one over other ones. You might not even know the reasons yourself, but you're just going to naturally prefer some to others. So there's already a bit of similarities there, which you don't get when you try marketplaces like Upwork or something like that.
Arvid Kahl: Yeah, that's true. There's this kind of pre-established, lukewarm connection. You may not have chatted much, but you know each other. You know that you're both in there. You have some sort of alignment to begin with. It's kind of like at a party when you want to talk to somebody and they're standing next to your friend. You have a prior connection. So that makes it much easier to just engage each other. Yeah, that is so cool. And it strikes me as something that I always had trouble with. that the first thing that you did was to hire somebody.
21
(someone): In the same way, I'm a designer by trade and I don't hire designers because I can do it myself. Maybe I should hire designers, but it would be really hard. It would be so difficult because I would want it done this way. And if a designer does it slightly differently, I'd think, well, why are you doing it that way? That's clearly wrong. I'm clearly right. And so I would have not hired if I could have done this myself. But I'm so looking back, I'm so glad I did. I'm so glad I had to because I think for non-technical founder, it's a lot harder to get started because you need You need a bit of investment, whether it's, you know, something like tiny seed or whether you do what I did, which is I pre-sold the product, kind of like a Kickstarter type thing. And you need, and you have the risk of having to pay someone to build it, which is kind of scary. But once you've, once you've done that, once you've got some traction and once it's going, it's really nice not having to worry about the development of the product and not have to worry about support tickets and bugs and all that kind of stuff. Because that I think would be the problem for me. If I could have cobbled something together myself, when someone had a problem, I wouldn't know how to help them. And it's really nice. I can go away and do my marketing stuff, my design stuff, or whatever else I'm doing. And I know that the product is being constantly worked on.
22
(someone): And, you know, we were talking earlier about having the mastermind, which is actually a podcast. But just having someone to talk to about these things I think is really helpful because they can maybe advise you okay I think you're not hiring because XYZ and I think you should do this because reason and then yeah it kind of gives you that extra push that you need.
Arvid Kahl: I think it's, like I said, a great accountability tool and I think the wonderful thing about a podcast is that you are doing this in front of other people. So you have the potential not just to have somebody be your sounding board for ideas or your mirror if you need them to be or the feedback generator that you need at that point to get motivation to do something, but you're also building an audience. at the same time and you're building an audience from a place of authenticity and genuine vulnerability because everything you talk about where you're not sure gives people insight into your decision-making process and how you approach not just winning But how you approach building, how you approach experimenting, and that I feel makes build such connection with people. And you've been an audience builder for a while. It's not the first time you dabble in creating a bigger audience around yourself. So let's kind of talk about that, because I think audience building is on everybody's mind. Everybody and their dog is building an audience at that point, almost quite literally, if you go to Instagram. So has that been a choice that you consciously made when you went into the Non-Tech Founders Podcast with Nathan to build an audience around that particular aspect of yours?
(someone): So for me, it wasn't so much.
Examples of no-code tools to build products without coding

Here are some examples of no-code tools that you can use to build products without coding:

  1. Bubble: Bubble is a visual web development platform that allows you to build web applications without writing code .

  2. Webflow: Webflow is a website builder that gives you the ability to design, build, and launch responsive websites without coding .

  3. WordPress: WordPress is a popular content management system that offers a wide range of plugins and themes to customize your website without coding .

  4. No-code platforms: There are several no-code platforms like Adalo, Glide, and OutSystems that allow you to build mobile apps without coding .

It's important to note that while these tools enable non-technical founders to build products without coding, having some understanding of design and user experience principles will still be helpful in creating a successful product . Additionally, hiring a designer or using design services can also complement the no-code tools and help polish the interface of your product .

1
Arvid Kahl: So that said, you can make sure you have a baseline of usability by using a UI framework from the beginning. There's frameworks, there's an abundance of frameworks, but things like Bootstrap, or Tailwind URI, or Material Design, all of these things will allow you to build all of your components, views, and pages using a coordinated and cohesive design approach. with predefined layouts and interface elements, you can be sure that you'll have a good foundation. Foundation is also a CSS framework from which to build your features. Just make sure that there's some basic unity in your interface. And whenever you can, just reduce clutter and complexity in your product with every single feature that you add. Try to reduce complexity. If configuration options can be removed from a view and put into a configuration dialog, move them over. If something isn't used most of the time, having it linger in the interface might be more of a distraction than it's actually helpful. Keep your interfaces as simple as possible. In many cases, this will go against the express wishes of your customers. In my experience, users will always go to, oh, just add a button for this as a suggested solution to their immediate problems. Well, your users are not designers or product managers. All that this suggestion should do for you is to trigger some research into the underlying problem and how you can best solve it without adding complexity to your interface.
2
Arvid Kahl: Tony Dinh's Twitter tool, Blackmagic, is a great example here. The browser extension itself is free, but using the service comes at a price. beyond the free tier, of course. The extension hooks right into Twitter, in the browser, and the user benefits from automation and insights without having to leave the social media site. I'm paying for this. Browser extensions can allow you to build incredibly valuable things that you can monetize. So as a budding software entrepreneur, what are your first steps? Well, let's go through them in order. Number one is to research different platforms and choosing the one that aligns with your business goals the most. Look into the platform's user base, the market that they're in, and the type of products that are successful on the platform, and then pick. Number two is to carefully read the platform's documentation and guidelines. You will need to be comfortable with the rules and restrictions that come with building on the platform. And you need to be able to build the thing that you actually want to build. Is that allowed? Well, it better be. Number three is to consider the costs of building and maintaining a product on the platform. So look for other developers talking about how much they give up in fees for profit-sharing arrangements. This is a good time to follow a few of them if they build in public.
3
(someone): In the same way, I'm a designer by trade and I don't hire designers because I can do it myself. Maybe I should hire designers, but it would be really hard. It would be so difficult because I would want it done this way. And if a designer does it slightly differently, I'd think, well, why are you doing it that way? That's clearly wrong. I'm clearly right. And so I would have not hired if I could have done this myself. But I'm so looking back, I'm so glad I did. I'm so glad I had to because I think for non-technical founder, it's a lot harder to get started because you need You need a bit of investment, whether it's, you know, something like tiny seed or whether you do what I did, which is I pre-sold the product, kind of like a Kickstarter type thing. And you need, and you have the risk of having to pay someone to build it, which is kind of scary. But once you've, once you've done that, once you've got some traction and once it's going, it's really nice not having to worry about the development of the product and not have to worry about support tickets and bugs and all that kind of stuff. Because that I think would be the problem for me. If I could have cobbled something together myself, when someone had a problem, I wouldn't know how to help them. And it's really nice. I can go away and do my marketing stuff, my design stuff, or whatever else I'm doing. And I know that the product is being constantly worked on.
4
Arvid Kahl: And it strikes me as something that I always had trouble with. that the first thing that you did was to hire somebody. Look for somebody to do work for you that you don't or were not at that point capable of doing yourself. Because in my engineering mindset, I could do everything. That's kind of what we've been taught in school and university and stuff, or even just on the job that we were doing, what I was doing when I started in the industry as a coder. You can learn everything. Just try to do everything. That is not the same for a non-technical founder, I would assume. So did you make that choice like initially from the beginning that you would hire as soon as possible or did you dabble in, I don't know, no code or trying to do some stuff for yourself to set up the thing that you wanted to build?
(someone): Yeah, so back then, I don't know if no code was really much of a thing. I feel like it's fairly new, so that wasn't an option, but I think even if it was, well, I don't know, to be honest, I think if I could have maybe got something together myself, I probably would have done it that way as well with the same mentality. Well, if I can do it, I should do it. I get to learn about it, it's my product, no one else will understand it the way I do and all that kind of stuff. In the same way, I'm a designer by trade and I don't hire designers because I can do it myself. Maybe I should hire designers, but it would be really hard.
5
Arvid Kahl: Tony Dinh's Twitter tool, Blackmagic, is a great example here. The browser extension itself is free, but using the service comes at a price. beyond the free tier, of course. The extension hooks right into Twitter, in the browser, and the user benefits from automation and insights without having to leave the social media site. I'm paying for this. Browser extensions can allow you to build incredibly valuable things that you can monetize. So as a budding software entrepreneur, what are your first steps? Well, let's go through them in order. Number one is to research different platforms and choosing the one that aligns with your business goals the most. Look into the platform's user base, the market that they're in, and the type of products that are successful on the platform, and then pick. Number two is to carefully read the platform's documentation and guidelines. You will need to be comfortable with the rules and restrictions that come with building on the platform. And you need to be able to build the thing that you actually want to build. Is that allowed? Well, it better be. Number three is to consider the costs of building and maintaining a product on the platform. So look for other developers talking about how much they give up in fees for profit-sharing arrangements. This is a good time to follow a few of them if they build in public.
6
Arvid Kahl: Twitter isn't just a website full of memes and funny tweets. It's a very lightweight frontend, the Twitter web interface that we use, that connects to a global network of backend services in dozens of data centers worldwide. The website is pretty snappy, as any good frontend should be, but the heavy lifting is done by tens of thousands of computers in the background. So if the front end is the sleek and elegant interface that your customers see and pay for, you can expect to spend a lot of time making it work well and look nice. And this is where user interface design and the concept of user experience come in. Just like there is a whole science to door handles and how to make them as practical and straightforward as possible, you'll find that a lot of people have a lot of opinions about the front end of your software solution. And to make things worse, those expectations vary wildly between devices. What works great on a desktop computer might be hard to use on a mobile device. Then iPad users, they expect things to work in specific ways, while your customers who access your service from their work laptops might need something else entirely. Whatever platforms you end up supporting, consider that they all come with their own expectations and limitations. Generally, I recommend using a design system to make your interface feel coherent and map onto existing expectations among your customers. There are lots of UI frameworks, such as Tailwind CSS, that come with some solid defaults and can be used right out of the box to build amazing software with pre-designed components. You'll find systems like this on every platform that you want to support.
7
(someone): They're not coders, but technical people who like that about the software, who like that they have lots of options to customize everything really the way they want to. And so the type of products I'm building are, but I'm not, I don't want to say complex, because complex sounds difficult. I want them to be super easy. Let's say they are powerful. And with that comes also options and customizations and all this kind of things. And I feel like if I would not have a really top notch documentation, I would, it wouldn't fit, right? that would feel weird in a way. And sometimes I witnessed that with products, they have a beautiful website, like really shiny, super nice, well made website, you sign up, and then it's already a little bit not so beautiful, the software, and then you realize that it's super disappointing, because there's not much functionality, or it's super complex or whatever. And I I don't like this journey. I rather prefer having a good website, a good product, and a good documentation and keep the standard high. And so I felt like for the type of product I'm building and the audience I'm having, it's my job to say, look, you can do a lot of stuff with this software. It's quite powerful. And I get it, it's maybe not obvious to you, but it's obvious to me because I built that. But it's definitely not obvious to you because you are using it for the first time. Here's the documentation, I'm trying my best that it's good for you, which then makes my life easier as well.
8
Arvid Kahl: Not to build the fanciest new technology into a complicated system that only you may understand. Maybe you don't even understand it fully and nobody can help you with that. It really limits you if you go after technology that you're not really versed in. And I've seen a lot of examples of that where people just wanted to build something with Yeah, well, Golang, for example. They were coming from a functional background, from a JavaScript background, and they wanted to use the language Go, which is super interesting. And for products that are supposed to compile to platform-independent binaries, stuff like that, it's wonderful, right? Go is great, and so is Java, and so are lots of other languages. But if you don't know them, and you have to build a system from scratch in that language, it takes you a couple months to even get to a point where you can build the thing you want to build. And a couple months is usually the time that you can pay for things from your savings. So, you know, if you want to spend all your money just staying afloat, learning a new language, I don't think it's going to bode well for your business. So keep using the things you're already using. I've written about this extensively, but I just want to make this point here again. Feedback Panda was built on Elixir and the Phoenix framework, and I didn't do this for the very first time.
9
Arvid Kahl: The input field for my link adding forms were in the wrong order, I had to reorder them at some point, I had to manually type a URL save slug, like a couple of letters that you could put into a link, into a URL. For each link that I wanted to have in the book, after pasting in the link, that should be automated, right? And even as a very technical person, I struggle to create such a text fragment. How would my not-so-technical customers, like authors who just want to write about their specific domains and not deal with HTTP-compatible text, how would they deal with that? And worst of all, after having added a link to the system, the newly created permanent link was hidden somewhere in the UI. I needed to make that immediately copy and pasteable to fit into the workflow of an author who creates a link and wants to put it into the book right away. And I built those things while I continued to add links. And after a few hours and a few dozen links, I had a pretty solid user experience around creating links. This would never have happened if I hadn't watched my customer, which is myself, use my product. And thankfully, this is something you don't need to be your own customer for. Of course, it's great to truly feel the pain points of your solution. But in many businesses, you're not necessarily capable of doing this yourself. But you can always ask your customers.
10
(someone): And that's why I'm saying, I could build all of this now, but I don't need to. This kind of infrastructure performance optimization is nice when you have paying customers that need it. Right now I have zero paying customers, so I will not need this. I use Tailwind, Tailwind CSS and Tailwind UI to quickly prototype the interface for the product. And purchasing Tableau UI has been a very good choice. I can only recommend this. It took me less than a day total to build the interface of both the product and the landing page. It took me longer to integrate sending notification emails than it took me to build a beautiful interface. It's absolutely worth it. And talking about stuff being worth something, I believe that any MVP should come with an option for the customer to spend money on your business. Purchase is the ultimate validation. It doesn't get more real than putting money where your mouth is. If a customer buys, they make very clear that there's something valuable here. So I needed them to be able to purchase something, to have the option. And as I already said, I'm using Stripe. But this time around, I'm using Stripe Checkout, which has proven to be amazing. For Feedback Panda, I used an embedded solution. And I had to deal with a lot of tokens being sent back and forth to my server. And when this PSD banking regulation hit Europe back in 2019, I had to scramble to update the system to support new features. Because all of a sudden, you needed these payment intents.
11
Arvid Kahl: Anything resembling work would be done from the computers that they'd use for teaching. clear lines in the sand and only a very select few would use their phones for work and only in emergencies or when they went on vacation or something. Never had more than 100 and some installs, which was kind of sad for me as a developer. And it was used by less than a percent of our users. So it was completely pointless to build this. And it was built on wrong assumptions. Once we understood that, we scrapped all development and focused all effort on making the desktop version of our product more responsive so that it would be usable on tablets, which we saw people migrating to for work. But small screens were never a target for optimization efforts after that. And we sometimes had people complain, or at least call in and say, write in, and say that, oh, it doesn't look too good on a phone. But these were really people that had messed up their regular workflow. So it was a really, really small minority. And it never really amounted to much more than a complaint. People really didn't need a feature there. And that was one of the learnings. And it was sad, because technically, this was really interesting. It was pretty much the first real hybrid app that I ever built with React Native. And it was really, really interesting to build it and see how it scales on different phones and everything.
12
Arvid Kahl: How do you deal with this? Because you were just saying you wouldn't hire a designer and I find this very relatable because that's how I felt for the longest time in terms of hiring a developer. Do you struggle with this right now? Are you at a point where you should be hiring somebody else but are not?
(someone): Yeah, so I what I've sort of had a little bit of a middle ground with this. And I've, I've been using one of those unlimited design services. And I think the one I use is many pixels. And basically what they do is they get so I give them if I need something, I give them the content and what I need. And they've got all my brand assets there. And they pull together something and it's never honestly that polished like it's not I wouldn't really put it out there without me doing it. But I then take that and I tweak it and I make it more polished. And that's sort of working quite well for me because it just takes a bit of the time away from me designing. It just gets me, it gets the blank canvas thing out of the way and I can tweak it, I can polish it and do all that. But that said, I do wonder if it makes sense for me to even be doing that. I don't know. I just, I can't imagine, I can't imagine hiring a designer. I think it would be really hard to do. And I love designing as well, which is probably like you, you love doing all the different things that you do.
13
(someone): every uh company startups asking for stickers they are ordering from sticker mule or doing they are going they were going to you know print shops so i thought i can do it and i created a you know wordpress and woocommerce site it was the easiest um you know stack for me to uh to do i don't i didn't want to write any code by the way because i want to try the business i don't want to i don't i didn't want to try how if i can write some e-commerce site or something yeah that's actually how it started and um how did it end how did it end tell me about that
Arvid Kahl: No, honestly, the thing that I'm excited to hear about is like, you know, where it got you. But I think it's already so cool that you stopped yourself from building yet another piece of software. Because so many people, when they think, oh, I'm going to build a business like with software, mean that they have to write everything. That's what they think, right? I have to write login software after my password reset, and I have to build like a payment system and whatever. Right. I'm glad you didn't because otherwise you probably would have wasted a year building this website for no reason and probably wouldn't have worked either.
(someone): Yeah, exactly. How did it continue? People around me criticized me to actually criticize me not to write it from the scratch. You know, people say, people were saying to me, you know, You are a developer, you can do it yourself. Why are you using WordPress, WooCommerce, etc.
14
Arvid Kahl: So that said, you can make sure you have a baseline of usability by using a UI framework from the beginning. There's frameworks, there's an abundance of frameworks, but things like Bootstrap, or Tailwind URI, or Material Design, all of these things will allow you to build all of your components, views, and pages using a coordinated and cohesive design approach. with predefined layouts and interface elements, you can be sure that you'll have a good foundation. Foundation is also a CSS framework from which to build your features. Just make sure that there's some basic unity in your interface. And whenever you can, just reduce clutter and complexity in your product with every single feature that you add. Try to reduce complexity. If configuration options can be removed from a view and put into a configuration dialog, move them over. If something isn't used most of the time, having it linger in the interface might be more of a distraction than it's actually helpful. Keep your interfaces as simple as possible. In many cases, this will go against the express wishes of your customers. In my experience, users will always go to, oh, just add a button for this as a suggested solution to their immediate problems. Well, your users are not designers or product managers. All that this suggestion should do for you is to trigger some research into the underlying problem and how you can best solve it without adding complexity to your interface.
15
(someone): So you can have like a native tab bar, native navigation, but you have all the benefits of web inside of your mobile app. What this enables is really small teams to do crazy productive things. So you think about Basecamp and Hey, the 37signals folks, they have really small, relatively dev teams for the number of requests and the number of customers that they have. Both of their apps are built on Turbonative. Their mobile website is shoved into an iPhone app with Turbonative, and that's their iOS app. And it goes a really long way because you're not building this like, trans compilation error language where you kind of have like a, what's that one called? The one by Google, but like Dart or is it called Dart? Yeah.
Arvid Kahl: Transpires, I guess. Yeah. Dart's the one from Google.
(someone): I don't know. Whatever it is. You can cut this. It's not a thing where you're writing, you know, a new language just to write your mobile apps, you're actually leveraging all of the existing logic and views and design that you already have on the website, but you're showing it on a native screen. And you have hooks into fully native screens if you wanted to. So if you wanted to integrate with the contact book or native maps or push notifications, you have hooks into doing that that drops you down into native code, Swift or Kotlin, depending on your platform.
16
(someone): Presumably there are other people who aren't developers that want to do what we're doing. So it would be really good to be able to talk to them. But also I feel like it's really helpful to developers because we're not going to be talking about things that typical developer podcasts are going to be talking about. We're not going to be focusing on the technology as such and all that kind of stuff. So we're going to be talking more about marketing and design and all that kind of stuff. I feel like it could speak to a lot of different people. It's really early days with it though. So it's hard to know, you know, I feel like we're still finding our feet with it. But I'm optimistic.
Arvid Kahl: Well, and I think you can be, because I listened to the podcast a couple episodes, and it's really nice. It's actually quite the breath of fresh air in a field where people quite quickly derail into these kind of tech stack conversations, where they are, oh, JavaScript, Python, whatnot, right? Where you, as a listener, if you're technical, it's not even interesting for technical people to listen to. Because it's just, you know, these kind of infights between technologists where they have their preferences and they just argue pointlessly about the benefits of a particular technology, where all the benefits of this tech are usually in how you apply it to the problem, and if it fits, right? So it's these weird kind of almost religion-style conversations that people are having. And I found none of these in the non-tech founders podcast.
17
Arvid Kahl: You just need to support them. Number two is WordPress. Developers can create themes and plugins that enhance the functionality of this popular content management system. With over 75 million websites built on that platform, WordPress is a popular choice for bloggers and businesses, even non-profits. WordPress plugins are a common Indie Hacker starting point too. They often solve very technical problems, and most new founders coming from a software background have an easy time transitioning into this particular kind of entrepreneurship. Number three is Heroku. Developers can build custom add-ons and apps that extend the functionality of this hosting and deployment platform that is owned by IBM. Many businesses choose to run their software on Heroku, and they need any kind of thing. They need logging, analytics, file uploaders, like the one offered by Colleen Schnettler, who I talked to, and all kinds of developer tools. In our chat, Colleen told me just how hard it was to actually get approved for the Heroku marketplace. And that is a good sign with marketplaces, because once you make it in there, you won't run into copycats immediately. So Heroku is a good choice. And number four is the Google Chrome ecosystem. More recently, paid Chrome extensions have seen some success when paired with a SaaS service on the backend. Tony Dinh's Twitter tool, Blackmagic, is a great example here. The browser extension itself is free, but using the service comes at a price.
18
Arvid Kahl: The landing page, the application itself, and all adjacent tools get integrated into this big application. And while this is initially faster to do, it will come around and hurt you later when correcting a single typo in the landing page means the full redeploy of the whole application. Instead, I recommend looking into no-code solutions for the content-heavy parts of your website. Use WordPress or Webflow or even just a static HTML page for those things instead of bundling it all up. Another idea is platform agnosticism. Your whole application should be able to be moved from platform to platform without having to spend months of migration work. The calm choice is to build everything on top of a commonly supported containerization strategy, like Docker. Then run your stack on the many cloud platforms that support it. Google Kubernetes Engine, Amazon ECS, Microsoft Azure, or services like Heroku. In case you need to move, all you have to do is to change some configuration and your software moves. And then there's integration APIs. Your servers will grow and will need to talk to other products eventually. From the start, think about how you can best and most reliably integrate and be integrated. Instead of inventing a new format to save your data, just use commonly used ways of data storage. And that way, you will increase your compatibility with other software products, and that's something that you will need for future partnerships anyway. building an internal API for your own services to talk to.
19
(someone): I can go away and do my marketing stuff, my design stuff, or whatever else I'm doing. And I know that the product is being constantly worked on. Um, and anyone who has a support ticket, I know that it's going to be taken care of and I don't have to think about it. And I don't think I'd have been able to, um, build client portal to where it is now. If I was doing all of that myself, because there's just not enough hours in the day. And the other thing is I would be at, I would have added so many more features than it has right now, which isn't a good thing.
Arvid Kahl: Yeah, oh no, that's a problem.
(someone): Yeah, there's so many things that I'm tempted to do and I'm like, well, I can't, so I don't. That's actually a blessing in disguise.
Arvid Kahl: Yeah, that is so nice that you have the separation of concerns, like even separation of capacity and capability. That is super helpful. I think that is the bane of all indie hackers, is their capacity to do everything kind of well enough. that there's no limitation really. And NoCode probably makes this even worse for people who, oh, let's just slap this Zapier integration in there as well. And then it becomes this convoluted mess of a Frankenstein kind of product. Yeah, interesting that your lack of immediate capacity to do it, kept the product straightforward and specific.
20
Arvid Kahl: expose yourself to new technology as well, even if it's competing with what you're using right now. Let me give you a personal example here. I'm a developer, and I have been for decades, and I've built many full stack applications in many different programming languages, and I never thought to check out no-code solutions. And there's this kind of chasm, this divide between coders and no coders, which in retrospect to me feels completely pointless because the goal is the same. Building things easily with the skills that you attain in using the tools necessary to build them. I've recently taken a very long good look at no-code tools because I'm involved in a project that new system, and I found out two very interesting things. The first is, you can build a lot without code. And the second is, you can't build many things without code. And the solution to this, that you can build a lot, but you also can't build many other things, is also provided by the market, and it's connectivity tooling. Zapier, If This Then That, Integromat, these tools are incredible, because they're standardized, easy to use, and easy to build for when it comes to interfaces. And they are the APIs of NoCode. And the potential of supporting such a connectivity tool with your product is insane. It gives you immediate integration ability with every other tool in the ecosystem. I would never have understood how much of an opportunity this is without jumping over my developer shadow and trying to build something meaningfully complex with no code.
21
Arvid Kahl: That's called the Lindy effect, and it's been true for many technologies. The longer something has been around, the longer it's likely to persist in the future. Ruby on Rails has been around since 2004, and it's still powering a substantial amount of profitable SaaS businesses in many industries. So choose boring technology. You find that in a world where every day represents new and unexpected challenges, having a reliable piece of technology as the foundation of your business is a tangible way to reduce stress and anxiety. And sometimes not building all the components yourself is also a really good choice. It's always a good idea to be able to program, to code, or at least to know somebody who does. In a digital world, having mastered the language of machines will make things that others struggle with, for weeks, something you can solve within minutes. But even if you want to build a SaaS business, you might not need to know how to code. At least, you probably won't need it to get started. The no-code movement is as old as digital technology. People have always wanted to be able to build programs and websites without having to learn the underlying abstractions. In the past, tools that allowed you to do this were called what-you-see-is-what-you-get. Today, we call them no-code solutions. These tools range from fully-featured platforms with which you can create fully-featured mobile apps to integration tools that glue together other platforms.
22
Arvid Kahl: You usually build your plugin on top of extremely well-designed and well-tested APIs, much better than having to figure everything out by yourself. Three, opportunities to identify niches in the marketplace. Platforms that have a marketplace of extensions, plugins, and add-ons can help developers identify underserved markets and niches. For example, Shopify's marketplace offers over 6,000 apps at this point that help online businesses manage inventory, fulfill orders, and do thousands of other things. And there's always that 1,001st thing that needs a specific solution. Number four, data mining existing reviews. You'll find an indication of these underserved niches in the negative reviews of existing plugins. By analyzing reviews, you will identify pain points and spot trends, and then be able to create better versions of existing products. This feedback can be used to create a more polished product that meets the needs of the platform's users better. The signal here is that people already pay for the solution that doesn't work perfectly for them. Your job is to make it better. Number five, established infrastructure. Building on an established platform means that developers can take advantage of the platform's existing user base, the traffic, and the trust to grow their own business faster. This existing user base can help developers grow their businesses without spending significant resources on marketing or market education. All in all, building on a platform significantly de-risks your first foray into being a software founder.
23
Arvid Kahl: Hello everyone and welcome to the bootstrap founder. Today I'm talking to Laura Elizabeth. She co-hosts the non-tech founders podcast and runs several products as a non-technical founder. We'll talk about outsourcing, building trust and building an audience around your business. Here's Laura. So you're co-hosting the non-tech founders podcast and that is something that I find amazing because in our developer-centric indie hackers community, I think there are far too few voices for the non-technical founders. And I'm glad you're doing this and I'm glad you're talking about these topics. Is it hard for a non-technical founder to even communicate to technical people? How do you find this? Has this been something that has been troubling you before that caused you to start this podcast?
(someone): Sort of yes and no. So I feel like most people I know in this space are developers and I don't know if that's just luck or if that's just how it is or if there's just more developers who are building software products, more indie kind of software products. And there wasn't really many people like me who didn't have that technical knowledge that was building something. So my friend Nathan, I think we became friends because we were like the only people that we know who aren't developers doing something like this. So we thought, Presumably there are other people who aren't developers that want to do what we're doing. So it would be really good to be able to talk to them.
Unknown error occured.