Latest / The Life-First Solopreneur / 01. How to Turn Your App Idea Into a Reality With Josh Jordan

Transcript

01. How to Turn Your App Idea Into a Reality With Josh Jordan · The Life-First Solopreneur

• 0:00
  Carly Ries: Just have to say I am the least technical person on the planet. I don't understand it at all. And and Josh, you have so thoroughly, put the whole process into into something that I can understand. So if you're listening right now and you don't have the tech background, keep listening. This is so important.
• 0:19
  Joe Rando: Bigger doesn't always mean better. Welcome to the 1 person business podcast where people who are flying solo in business come for specific tips and advice to find success as a company of 1. Here are your hosts, Joe Rando and Carly Rees.
• 0:37
  Joe Rando: Hello, and welcome to the 1 Person Business podcast. I'm one of your hosts, Joe Rando.
• 0:42
  Carly Ries: And I'm Carly Rees.
• 0:44
  Joe Rando: And today, we're gonna be talking with Josh Jordan. And Josh has been building software applications for over a decade, and he's gonna talk about what you need to know before hiring a software developer for your app or your website. Josh has worked at massive corporations like Amazon and Vistaprint. And in fact, when you talk to, to Alexa, you're really talking to Josh's code. And he's done some startups as well where he's only been one of a couple of software engineers, and he got bitten by the startup bug when he did that.
• 1:16
  And he since founded a couple of businesses helping startups and small businesses build their tech products from ideas to scale. He's worked on lots of different things from web apps to mobile apps. And he lives in upstate New York. He's got a wife, kids, and a dog. Josh splits his free time between typical geek activities, like serious board gaming and writing code for fun, and atypicalgeek activities like hiking and camping, which involve moving away from the keyboard.
• 1:42
  Plus, I've worked with Josh on the Lifestar app, and he's really amazing. I've worked with a lot of software people over the years, and he's an amazing guy. And he's gonna have a lot of great insights for you. So, Josh, does that sound about right? Did I sum you up?
• 1:55
  Josh Jordan: Yeah. Thank you for that.
• 1:57
  Joe Rando: Also, I know that you have a book coming out that we're gonna talk about today. Maybe you could tell us just a tad about that book.
• 2:04
  Josh Jordan: Yeah. So it's called, Starting Your Startup, 7 Steps to Launching Your App on Web or Mobile. And I really wanted to help entrepreneurs come through the process of starting with a single idea and figuring out how they're going to turn it into a real software product that you build a business on top of. I think there's a lot of guidance on the out in the ether about how to work with developers and how to turn your idea into a spec, but nobody's really bringing that together. And what I wanna really talk about is how you build a business on top of technology.
• 2:33
  Joe Rando: And this would apply to solopreneurs too. Right? So somebody that was trying to do a one person business but needed an app?
• 2:38
  Josh Jordan: Absolutely. I think it applies especially to solopreneurs because they aren't going to have a technical co who can manage that process for them, and there's a lot of gotchas working with developers, especially if they're not going to be full time permanent employees in your company. Really wanna be efficient about how you use them. There's a lot to know about the software development process.
• 2:57
  Carly Ries: I just have to say, I am the least technical person on the planet. I don't understand it at all. And and, Josh, you have so thoroughly put the whole process into something that I can understand. So if you're listening right now and you don't have the tech background, keep listening. This is so important.
• 3:14
  Joe Rando: So let's talk a little bit, Josh, about what are the kind of
• 3:17
  Joe Rando: the important things that solopreneurs would need specifically when they're thinking about creating their own app, whether it's a web app or
• 3:24
  Joe Rando: a mobile app or both. What what do they need to
• 3:27
  Joe Rando: think about? What do they need to do to have a outcome?
• 3:31
  Josh Jordan: Yeah. So putting together a team of developers is obviously a big part of the process, and I don't want people to jump right into that because there are a couple things that you'll miss if you do so. One of the key bits, in my mind is making sure that you're engaging with a team who can get excited and invested with the idea that you're bringing to them. I also want the entrepreneur to have a really good understanding of the high level technology pieces that are gonna play a big role in the business for years to come. You don't have to become a software engineer, but you do need to have a basic understanding, especially, again, if those people aren't gonna be a part of your company on a full time permanent basis.
• 4:07
  You need to be able to find and vet the right people, make sure the process is going right for you. So before I get into describing how to build the right team, I wanna talk about 2 steps that I want an entrepreneur to complete before they get there. 1 is writing a good product brief that succinctly describes the business idea and how technology fits into it. That way, the folks on the other side of the table can really understand every part of the business, not just the technology, but the business as well. And without that, I find that people kinda start rambling about the exciting parts of the idea and leave off the important technical bits that the technical folks are going to need in order to kinda anchor it to reality.
• 4:45
  And then after that, I wanna provide, like, a little bit of education about the basics that you should know as you go into that conversation so that you know the folks on the other side of the table are the real deal. Does that make sense?
• 4:57
  Joe Rando: Definitely makes sense. So what you're saying is Carly's gonna have to learn a little bit about technology if she wants to build an app?
• 5:04
  Josh Jordan: Just a little bit, and I'll give you enough information, that I I think you can have that conversation without
• 5:10
  Carly Ries: the phone or phone.
• 5:12
  Josh Jordan: That I can't help you with.
• 5:14
  Carly Ries: You're gonna
• 5:14
  Josh Jordan: have to Google that one. Okay. So let's start talking about the the product brief then. What I really like to tell entrepreneurs, when they come up with a great idea and they're super excited about it, and you should be because you're the one who's gonna need to push this idea right from the idea stage all the way out to, building a great business on top of it. First thing you need to do is get that product brief written.
• 5:35
  I see that as kind of a 1 to 5 page document. There are some key pieces that I'll I'll take you through. The first one is tell us what the problem statement is. There are so many great ideas that I hear entrepreneurs come up with, but they haven't fully defined what problem they're trying to solve. As you go out to real users and you try to convince them to give you money for your product.
• 5:57
  We need to have a good idea of what problem we're trying to solve so we can stay focused on that throughout the process. Number 2, give me a detailed solution to the problem. This is probably the piece you're really excited about. This is probably the piece that will flow most easily for you. But tell us exactly how you intend to solve that problem.
• 6:14
  And then, this is where I start to ask for more detail, and and sometimes people start to stumble. But they're really important things to think through. Give me 1 to 3 important use cases, for your product. If you can get to the point of drawing a sketch on how somebody goes from having a problem that's causing them real pain, time, money, productivity loss, to having their problem solved and feeling that pain relief, that's perfect. That's what we wanna see.
• 6:43
  Tell us who the user is, why they feel that pain, and what makes it go away for them in excruciating detail. Then I ask folks to tell us how the user experience should feel. In other words, what parts of your brand are gonna come through in your product? If it's a financial product, you're probably talking a lot about trust. If it's a task management application, we're probably talking a lot about organization, and feeling like the software is doing things for you.
• 7:10
  If your problem is productivity loss, you probably wanna do some reporting and tell the user how much time they've saved. You don't have to, have all the all those questions answered in this step, but you need to be thinking about them and have some explanation for it. That's gonna help the other side of the table, the developers, stay focused on exactly what the user, should feel and not just not just the exact problem they're trying to solve. But that experience all along the way to having your problem solved is actually really critical to, building trust and engagement so the users come back. Then from user experience, we wanna talk a little bit about what the visual design is, how should it look, and this has some overlap with what I just talked about.
• 7:52
  Then we should talk about what the go to market strategy is. This is not a situation of if you build it, they will come. The fact is that the technology markets are so saturated with products that, we can no longer put out a product and just expect that people will organically come to it, we need to develop a really good strategy around how we intend to get people on it. This might be going from a beta group of users to inviting all their friends and providing some incentive, to that beta group and then running ads beyond that to get people in the door. But we really do need to have a strategy down on paper.
• 8:25
  Even if it's not the one that we're ultimately going to stick to, let's start with some strategies because we're gonna think about it throughout the app. If the application needs to have invitation features so that one user can bring another one on, that's something that we should know in advance. It's a feature we're gonna have to build. No matter what that mechanism is, it's going to impact the technology. And then finally, I wanna see people talk about what the business model is.
• 8:49
  I wanna know how this application is ultimately going to make money. Maybe the user is also the buyer. That's typically the case in consumer applications. That's a pretty straightforward process. Maybe the business model is just based on advertising.
• 9:02
  Maybe it's a little bit more complex, and we're doing business to business sales, and the buyer will be somebody different than the actual user. We need to plan for that in our sales process. So all of these things come together to form what I call a product brief. This is one document that the other side of the table can digest, and you'll see it's really focused on the business and not just the technology because the business really does impact what we're building. Carly, could you go write a product brief based on what I've told you at this point?
• 9:29
  Carly Ries: So far, it's making a little bit of sense. But, what kind of tech are you talking about?
• 9:32
  Josh Jordan: So when we talk about technology, I'm talking really broadly about web applications, mobile applications, desktop applications. I'll get into talking about those in in more detail at this next step where we kinda have our our high level tech understanding that you're going to need in order to take your product brief to a team of developers and have a meaningful conversation about what they're gonna build for you.
• 9:54
  Carly Ries: Got it.
• 9:55
  Josh Jordan: So I have kind of a checklist of things that I like people to have a passing knowledge about. I go into this really deeply in chapter 2 of the book, and I'll I'll talk about each of the things on that checklist right now. Like I said, don't be intimidated by it. You don't have to, go get a computer science degree in order to have a meaningful conversation. But as a an entrepreneur who has technology as a significant part of their business, these are things that are not just going to be important this initial conversation.
• 10:24
  They're gonna be important for the rest of your product's lifetime. So it it does really help out for you to have some knowledge, about the the kind of conversations that you're gonna have with your developers on an ongoing basis. Some of this is really technical and gets into how your databases work. Like I said, it's not terribly deep, but, let let's have a conversation about it.
• 10:45
  Carly Ries: I have my notepad ready.
• 10:46
  Josh Jordan: Good. Good. Cool. The the first item, that I'm gonna talk about is the delivery mechanism for your application. Whatever solution you have in mind, we need to talk about whether this is going to be a website that somebody types in in their browser or a mobile app that they download from one of the app stores, the, iOS App Store or the Google Play Store or both?
• 11:08
  Or is it going to be a desktop application that they download to use on their their laptop or their desktop computer? We also talk at this step a little bit about responsive design, which is a strategy we can use on the web to make the application look really good even if somebody's using it on their mobile device. That's a great way to avoid having to spend all the money on building an additional mobile app. If you're not sure whether you wanna be on web or mobile, typically, we tell people that it'll be cost effective for them to build a web application that is also available on mobile because then you hit all the platforms I just described because every device has a web browser on it. But some, applications, they'll be kind of thinking about mobile first.
• 11:46
  And when I say mobile first, that could mean we're designing for mobile as a, website that's responsive, or it could be we're truly building a mobile app as the first release of the product or perhaps the only release of the product. If your application is really heavily dependent on the features that are only found on a mobile device, like a persistently ready camera or push notifications, then, mobile app is probably the right way for you to go. You don't have to have all the answers to which of these platforms is the best for you based on the features available, but you need to have an understanding of what they are because you're gonna be talking about them. The developer is going to be asking you questions about which is appropriate. So just have an understanding at this point when we're talking about delivery mechanism, it's web, mobile, or desktop.
• 12:33
  With me so far, Carly?
• 12:34
  Carly Ries: Got it.
• 12:35
  Josh Jordan: Very good. Beyond that, something we'll talk about is client side versus server side. In most of these applications, we're gonna be talking about code that runs on the client, which is the device that your user owns. So my laptop computer or my mobile phone, that's my client. This is important because client code is what makes the application feel really good.
• 12:59
  When you have a great interaction on your device where you tap on something and then fireworks pop off, that's great and that feels nice. But we can't run any secure code on the client because we don't trust the client. That's where somebody malicious could be changing the code or manipulating it. So all the secure stuff happens server side. That's on a server that you, as an entrepreneur, own or are paying a hosting provider for.
• 13:24
  If we're doing credit card processing, if we're updating user information or sending email, that all happens server side. You don't have to go write the code that runs client or server side, but you're going to be having conversations with your development team about what operations in your application are secure. And so client side versus server side is going to come up. You're gonna wanna talk about the system integrations that you see happening in your application. When I say system integrations, I'm talking about what other systems does your application interact with.
• 13:55
  So if you're doing, integration with HubSpot or Salesforce or with an email client, these are all places where you might bring data into your application or push data out to other systems. So when we talk about integrations, we just mean interactions between your system and something else. There's a lot of forms these can take, but just be aware of those integrations. Because very often, we're building applications that do not just live on their own. They're much more interesting when they interact with something that's already a part of the user's everyday life.
• 14:26
  Joe Rando: Josh, could this include something like a a Stripe integration, like, where you're trying to collect credit cards, get paid?
• 14:31
  Josh Jordan: Yeah. Stripe is a great example. PCI compliance is a big deal, for software applications. And if we can, we can avoid a lot of cost in the build by never touching the credit card. If the credit card number never enters our system, we can avoid PCI compliance.
• 14:47
  So a tool like Stripe is a great integration because it allows us to do that. Anytime a credit card from the user's perspective is entered into the application, that actually goes right to Stripe's servers, and we do that by building an integration. So that's that conversation that you would have with your development team about a specific integration you would need, and many, many applications are going to need to do that. There are, a couple different payment providers you can use that offer this feature. Stripe is the one that we've worked with most often, but that's a prime example of an integration because we don't wanna take on all the complexity of storing credit card information in a way that complies with the payment card industry standards.
• 15:24
  I wanna talk a little bit about data model and data access patterns. Again, we're you're not expected to design the data model or build the indexes that will enable great data access patterns. This is just about having a passing knowledge of what the developers are talking about when they get into this. When we talk about the data model, we're talking about where is your data stored and what shape does it take. If you can imagine a database like a big spreadsheet with different columns, and you would say, well, this column, everything in this column represents money, and everything in this column is a name.
• 15:59
  We'll call that a string. We need to know kind of what data types every single data field in the application is, and we need to know how the data is grouped up and related to one another. So, actually, your database is many spreadsheets, and each table in a spreadsheet relates to other tables. And we need to know what those relationships are. When we talk about data model, that's really all we're talking about.
• 16:18
  Imagine your database as a group of spreadsheets. When we talk about data access patterns, we're talking about how data is read and written in your application. For example, if you're building a forum, there are posts that are made in your forum. These posts are written relatively infrequently, but they're read all the time. Every other user is probably going to see every post many, many times.
• 16:45
  So we would think about that as written infrequently and read frequently. But there's other types of data like log data, compliance data, that would be probably written most often and read almost never except when there's a particular type of audit happening. So one thing we'll talk about is for each piece of data, for each spreadsheet that you can imagine in your application on the back end, What are the data access patterns? This is important to tell the developer so that they can design it according to the intended use. Remember, the developer is going to be coming in without particular knowledge about the problem you're trying to solve other than what you told them in the product brief.
• 17:21
  So if compliance is important in your industry and you're going to be writing some compliance log data, they need to know that and they need to know how that should work. So that kinda brings us to talking about databases themselves. You don't need to know which database to choose, but you should have a passing knowledge of the various options as the developer brings them to you so you can have a meaningful conversation about them. A lot of applications today still use what's called a SQL relational database. And, again, this kind of fits really nicely with the spreadsheet idea that I brought up a couple minutes ago and imagines each piece of data as a table that gets related to one another.
• 17:59
  There are other types of databases that are a little bit less structured. We call that a non relational or, NoSQL database. Those are really great for rapid prototyping, moving quickly, especially in cases where we don't know how our data is going to evolve over time. And there are graph databases that store data in what we would call a graph, but basically looks like nodes and edges between the nodes so you can travel between those paths. If you think of something like Facebook or LinkedIn, where there's a large social network, those are often visualized as graphs.
• 18:30
  And we wanna know, well, how many degrees of separation do I have between somebody else that's traveling through nodes and figuring out what that distance is.
• 18:39
  Joe Rando: Kevin Bacon.
• 18:39
  Josh Jordan: Like Kevin Bacon. Exactly. Kevin Bacon distance is a classic graph problem, and that could be solved really nicely by a graph database. It's not the only solution to the problem, but it's, it's an important one. And so just having some fluency in that as the developer talks to you about whether they wanna use SQL or NoSQL, spend a little bit of time understanding why they are proposing the technology that they're proposing.
• 19:03
  And one of the reasons I bring this up at this point is because often we see development teams that are fluent in a particular set of technologies, And in my view, that's not really the right way to approach what technology stack do we use for your application. I'm a big fan of using the right tool for the job, which means figuring out which database and back end technology and client side technology are right for the particular needs of your application, not the ones the developer just happens to be fluent in. So if they can't articulate exactly why a particular database is the right solution for your use case, that's a red flag. And then the the final bit that I want people to understand is the difference between user experience and user interface. User experience is what does the user do overall?
• 19:51
  What do they feel as they do it? How do they experience your application? This is if I want to get my problem solved, which pages do I have to go through? Which things do I click on? And how do the elements on the screen react when I interact with them?
• 20:06
  That's as compared to user interface, which really just refers to the visual aspects of the application. What does it look like, and what do I see? Those are important because the user experience is something that's going to permeate all the way through the application, and you kinda wanna have consistent user experience patterns so the user gets used to interacting with your application, and it trains them. For instance, when you release a new feature, they're probably gonna have some intuition about how that works already because they have intuition about how your application works just by using it. And then the user interface bit is, like, let's talk about what pieces of flare are going to make this really stand out to the user and visually appeal to them and delight them as they use it.
• 20:46
  Carly Ries: Just going through all this, thinking about everything you just discussed, you said it's important to be conversational in all of this. But how do you go about finding somebody that is fluent in all of this and finding the right people to bring on to your project?
• 20:58
  Josh Jordan: It it's a great question, and I think there's not an easy answer to it. But I do really like to tell people they should start with their immediate network. There's almost definitely someone in your network that you can trust either personally or in terms of their technical skills. Hopefully, both. They can help you, and I want you to kinda cling to that person.
• 21:14
  It might be you based on your past experiences. It might be a friend or family member. It might be a colleague. In any case, this person could be a future member of your team, but they most likely aren't. I want you to use this person to help you vet the team members that you're gonna be talking to soon.
• 21:29
  Since we're talking specifically about solopreneurs, we don't need to get into how you bring out a technical cofounder or what software developers as permanent full time folks, look like as part of your team, let's talk about, outsourcing your development, which I assume is the path that, most of our listeners are are going to take. Your best bet on this front is to ask around your network for other folks that had good experiences with an agency or a consulting group. I'm a bit biased towards small focused agencies because that's what I do, but there are larger agencies that do good work too, and it's all about how willing they are to get their heads into your product and really become a part of your team once you engage them. Again, that's about making sure that they are seeing your product as unique and serving its specific needs rather than their specific process or previous experiences. I also like to tell people that when considering, outsourcing offshore versus onshore or nearshore, there's a quality gap that we see for better or for worse.
• 22:24
  I like to talk about this as programmers versus software engineers. When we talk about a programmer, we're talking about somebody who can be handed a set of requirements and can go implement them, And there's plenty of need for that. But when we talk about software engineers, I'm talking about somebody who can really engage with the problem and think deeply about what the solution is. Because in your shoes, if you're listening to this and thinking about how you go forward to do it, you probably don't know how to solve your problem from a technical perspective. And so that's why, typically, I'm recommending that software engineers are the right way to go.
• 22:55
  If you had a technical cofounder, a CTO who could manage the process and write very succinct requirements and review the code against those requirements, then perhaps programmers would be right for you, and maybe you could save some money by doing some offshoring. But, generally, I want engineers who can think really deeply about the problem. And so I'm generally recommending that onshore people that you can get on a call with kind of at any time and dive deep into, well, you know, what if I changed the business in this way? How would that affect the technology? That's what I think will help most.
• 23:25
  So I I do like for people to find those agencies through their networks. I think that's, basically how you're gonna get folks that you trust. So once you find a few agencies that you wanna talk to, you absolutely should have multiple options to compare between. You're gonna call them up and grill them like your life depends on it. Your your product's life really does depend on it.
• 23:45
  And I I kinda, wrote a guide to, what your first call with them looks like and how you vet them, that I'd like to go through. The first thing that you're gonna do is convey your idea to them, and this is why you wrote a product brief. You don't have to stress about exactly what you be telling them because you can share this with them in advance, and you may wanna put an NDA in place, before that. That's all good. They should be used to that.
• 24:06
  Joe Rando: NDA being a nondisclosure agreement. Yes.
• 24:10
  Carly Ries: And if if people are, writing all of this down really quickly for this, particular article that you're talking about, we will include this link in the show note. So just heads up there that this is super valuable, and we will have that link to his guide to agency intro calls.
• 24:25
  Josh Jordan: Yeah. And then the second step is to let them describe their relevant experiences. You don't need to push them here. I'm hoping that when you have shared your product brief with, an agency, their eyes are gonna light up, and they will tell you they have the chops to go implement, what you described and that they understand it well enough to, relate it to the similarities of other products that they might have worked on. Then we should talk about constraints.
• 24:51
  Sometimes I liken the process of finding the right team to work with to dating. I think there are some good analogies there, but this is finding out if you're compatible at all. Wanna know if there's a specific launch date you need to hit, and maybe they don't have the avail availability to do it. You know, is there some kind of promotion that you wanna do at a specific time or there's a specific market event? Does your business need to, demonstrate certain metrics in order to keep the project funded?
• 25:17
  Are there certain internal quality standards that you need to hit? Share these things with them and see how they react. I wanna understand that they can meet the requirements of all those constraints. I usually tell people not to share their budget at this time. That's not how we operate, but you can imagine that there are less principled firms out there that will fit their estimate up to your budget.
• 25:37
  So if you tell them that you have $50 to build a product, they might say, well, that's cool. How coincidental? It looks like we estimated this at about $48. And that's it's just not what we wanna see. Let them give you an estimate based on what you described.
• 25:51
  Then we wanna ask them about what their process is, some of the key things to look for in their development process. 1, plenty of opportunity for you to see some work in progress and to give early product feedback. I could talk, at length. We could do a whole podcast about agile software development and why early feedback is important, but the bottom line is early feedback kind of reduces the cost of fixes and changes. I kind of fundamentally believe that there will be changes as you start to use your own product and understand how to interact with it.
• 26:21
  At Super Villains, we do this by deploying code multiple times per week in an environment where you as the product owner can go use the real thing. Even if it's not complete, that's okay. It allows us capture feedback and say, wait a minute. This doesn't feel right, or this is great. Let's continue down this path.
• 26:38
  2, listen for quality checks. Without you prompting them too heavily, they should be able to tell you how they keep their software quality very high. We do this by writing a lot of automated tests so that at any point in time, we can press a button and verify that everything we've written to date works just the way we intended it to work.
• 26:55
  Joe Rando: Hey, Josh. Yeah. Can I just jump in and say, you know, this is an easy one to skip, and a lot of people skip it? And I've been there, And it can be very, very costly because you can find out that a change that you've made to your software has broken something you don't know about, and very bad things can come out of it. And I can tell some horror stories but I won't.
• 27:18
  This idea of these automated tests to keep quality high doesn't really do anything, doesn't make the app feel better at the time, but I just wanna drive home how important that is to getting a good result and a and good maintainable code over the the life of the product.
• 27:34
  Josh Jordan: It's true, and it can be particularly daunting at the beginning of the process because, it does add a a nontrivial amount to the cost because your developers are gonna spend a fair bit of time implementing these tests. But I want you to imagine the cost down the line if every time you deployed a new version of your product, which might be as often as multiple times per week, you had to go retest every single feature of the application. And that's not just a matter of clicking around the application, which itself is quite time intensive as the application grows. But imagine in your integrations where if you've integrated Stripe or some email system where you need to go test every case, which means signing up from scratch with a brand new credit card and verifying that the application still charges that credit card at the right times. In reality, you are not going to do that.
• 28:20
  You're not going to be able to test all those things every single time you deploy code, and, it's it'll be very expensive because you'll leave gaps for yourself, and then you will inadvertently have broken things. The nature of software is that it's very complex. Sometimes it's difficult to tell that one benign change you're making has some downstream effects, that will impact, some other feature. That's that's unfortunately just the nature of the game. So we do kinda recommend building automated tests because although they're relatively expensive to build up front relative to the features that you're building, it's not as large as the feature work, but it's still a significant portion of the time that your developers will spend.
• 28:57
  It will save you so much time down the line and not to mention the the pain of having to do emergency bug fixes once your users are the ones testing the application for you if you don't have these automated tests. Another thing to ask is who manages the servers that your application will live on? Is that them, or what do they need from you in order to make it happen? There's kind of a lot of different models here in terms of who, host the application, who pays for it. I don't think the answers, to those questions are things that we can exactly anticipate.
• 29:26
  Every agency is gonna approach this differently, but you should know what that is up front. The next thing you wanna talk about is what is their financial model? Are they gonna get paid hourly or at certain milestones, or do they wanna make a portion of your future revenue? You do assess the risk, both yours and theirs, and what the future impact to your business is, especially if you're planning to share profits or revenues with them. Most of them are gonna wanna work hourly or in milestone payments because they don't wanna take on that risk.
• 29:54
  Do they have any minimum commitments? Are they looking for a monthly retainer? What happens if you decide you don't like their work and wanna cut ties? I think this is specific to every single engagement, and you need to decide what's right for you, but you should have a very serious conversation about it. That brings us to talking about what it's going to cost.
• 30:11
  I can't emphasize this enough. They should be able to put a reasonable projection together, and this might take them a few days. But you should be able to see in their projection that they understand your business at a fairly deep level, and they have customized their proposal to the specifics of your project. If it smells generic, you can expect that they're planning to throw your project together according to generic patterns. Again, that's specific to them, not you.
• 30:33
  Run away from that.
• 30:35
  Joe Rando: A question, Josh, on that. The construction side of the real estate, there's something called change orders. You know, you give them blueprints, and they start building the building, and you go, oh, wait a minute. We need to change this. And the next thing you get an additional bill where you sign you sign an agreement, a change order.
• 30:50
  Is that common in software?
• 30:51
  Josh Jordan: It is common in software and especially because we embrace, change with Apple's agile software development. It's important you should expect that there will be changes. Like I said, once you start to use your own product, I think you're going to think differently about what the experience should be. So instead of building in specific requirements to go right into your contract, and you should be talking about specific requirements. But instead of putting them in your contract, especially if the folks you're working with are going to be working hourly, you should have a conversation about what that change process looks like.
• 31:22
  There's no reason why even once you engage in the process, the developers can't continue to provide you estimates. If you say, well, what if I wanted to insert another page between pages 12 in a specific process, what will that cost me? You should be able to have an ongoing conversation about how much effort each thing you take on this, and especially if you are constantly reprioritizing as you start to get customer feedback as you get close to your launch or post launch, that should be a pretty regular conversation. I think the last bit is to find out if they wanna stay with you long term. I always tell our prospective clients that our goal is to develop a long term relationship, even if that meant we weren't building a whole lot together in the first pass.
• 32:01
  Sometimes I'll tell people that the first pass at their business can be built in a spreadsheet, and that might be the right way to go. That doesn't make us a whole lot of money in the first, iteration, but, selfishly, we we do best with our clients, when we do have a long term relationship. But for you, it's an indication that your development team wants to stand by their work. They're able to, stand by the quality. We show off quality to our clients just by working with them.
• 32:27
  If it starts to feel like the developers wanna cut and run after the 1st iteration, move on. You can expect that they're not building with quality if they don't wanna support it after it's launched. That's unfortunately a typical model for, offshore firms, and and, unfortunately, we've been a part of a lot of rescue projects where an offshore firm built something that could not be maintained or scaled, and entrepreneurs come to us in a panic to fix this. So suss that out early on in the process. Look for folks who are going to stand by their work by committing to staying with you in the long term until you are ready to ramp on to either, full time developers or you've gotten the product into a state where you don't need constant changes, bug fixes, and feature improvements.
• 33:06
  Carly Ries: Well, Josh, I have to say just to piggyback off of that, a benefit of the long term relationship too is the education component. Like, it has been so helpful working with you over the past year plus, because now I feel like I'm more than know with everything that's going on. And again, speak conversationally to all of it because of that long term relationship that you don't get with the short term.
• 33:25
  Joe Rando: Mhmm. Yeah. Absolutely. I guess that brings us to one of the common mistakes you see people make. And most specifically with one person companies with I guess these really are so we'd have to call these solopreneurs as opposed to freelancers, but they're trying to create a business and it's just them and they're trying to do all of this software development with an outside contractor.
• 33:47
  What are the mistakes that these people tend to make?
• 33:49
  Josh Jordan: Yeah. I I think the first really big one, that I see often is it's really the process of planning rather than the plan itself that is going to be most useful throughout the the process of software development. I think it was Eisenhower that said plans are useless, but planning is indispensable. I don't want people to expect that the vision in their head is exactly what they're going to
• 34:09
  Joe Rando: end up building. Fundamentally, I think that once you get to use your own software
• 34:13
  Josh Jordan: and really touch and feel it, you'll come to understand your own idea at a much deeper level than you ever could have in the planning phase. It's gonna mean making changes to the original vision. That's okay. That's a good outcome. So we build our process, our agile software development process, to embrace change.
• 34:30
  It means throughout the initial product development phase, it means, again, when we have our 1st beta customers, it means on an ongoing basis when we develop a regular feedback mechanism with our everyday users for the rest of the product's life. This is why we do agile software development. Our agile development practices let us react quickly and inexpensively and ultimately build a better product that's more in tune with what the user wants. Kind of along those lines, I also see people who build too big in their first iteration. We don't need to build for every use case, for every possible user persona in the first version.
• 35:04
  Let's get something meaningful into the market first and assuming your business model permits it, and then we can change directions drastically if we get feedback from the users, that ultimately is gonna make the product better. I don't want you to spend too much money before you get that feedback. It makes the product more complex and slows feature development, if we build features that really don't resonate with the users. So let's prove that the product is necessary in the market by getting it to a user, getting them to agree that the product is worth real money or change the product until it is. Then let's have a conversation about how we tackle the next big hairy problem.
• 35:40
  I think there's a tricky balance in building for scale for cell phone entrepreneurs, especially. There's a famous quote from Paul Graham about doing things that don't scale first. So you can learn how to do them once you do scale. And And frankly, I can't really teach a computer to do something if you can't tell me first how it's done by hand with a couple of notable exceptions. I believe in that a lot.
• 36:00
  It saves money, and it gets the processes right. And often, this means kind of asserting yourself as a ghost in the machine so that when, for example, a user submits a piece of data, maybe, we tell them, okay. Come back in a few hours once we process this, and it's really you doing the work to do that processing in the first version of the product perhaps. But as a solopreneur, you are not going to have the luxury of releasing a feature that creates a huge operational burden for you. So if your feature takes off, you need to know how the software is going to address that.
• 36:28
  Plan for a realistic level of scale in every feature you build. There's no easy answer here. It's specific to every single feature. The last one that I see, frankly, is having unrealistic expectations about how long it takes to build the product. Often, something that sounds simple, sounds like it can be built quickly, but even small variations on it could introduce a lot of complexity from a development perspective.
• 36:51
  Work really closely with your development team to find costly requirements and find alternative ways to satisfy them. It requires some trust with your team, but it can save you weeks weeks of development time. Make sure to allocate time for the odds and ends that are kind of boilerplate for every product. You think about user authentication logging into your application. Think about security concerns, user settings, or options that you're going to want the user to have to set.
• 37:17
  Could be as simple as light and dark mode in a mobile app, or it could be, how often do you want notifications? But users are going to expect that. Expect to have to build something to handle spam, opt out links that go in your emails, notifications, customer support. These are all things that require development time even though they're not a core part of your idea. Even if your idea is is as simple as having a black box that takes in something from the user and satisfies a problem for them by spitting out some answer, you're still gonna need to think about how these other aspects fit into your product.
• 37:49
  It's just part of productizing your idea.
• 37:52
  Joe Rando: Makes a lot of sense. My next question is if you had one thing that you want a person with flying solo in business to take away today, what would that be?
• 38:02
  Josh Jordan: Yeah. We should talk about how we turn use cases that are in your head into user stories. We have a language that we like to speak, in terms of user stories at my company. And so every time we have a feature, we like to phrase it as as a specific sentence with 3 kinda fill in the blanks, and this helps the development team think really deeply about what we're implementing and why. And I I think I've put a lot of emphasis on the why, and that's because I really do believe that we'll build a better product if the developer can think about why they're building it because there are many very nitty gritty details to solve it.
• 38:38
  Like I was talking about a minute ago with kind of prioritizing the idea, the developers should be able to think about who they're building it for. And if there are decisions to make about is the user going to experience 2 pages or 10 in order to complete this process, but we should know what the user's goal is. So we have a template that we use that says, as a blank. And in that blank, we put a predefined user persona type. This might be, on a, like, a 2 sided marketplace.
• 39:05
  This might be as an expert or as a, as a buyer, whatever those personas are for your specific application. As a blank, I want to blank. This is a just a clear statement about what action they're trying to perform in the system, and then we follow it with so I can blank. And that's the why. That's the the mission or the the fulfillment of the problem.
• 39:31
  Joe, we did this many times on Lifestyle. Do you wanna give an example of one that we wrote, for Lifestyle?
• 39:36
  Joe Rando: Sure. As a user, I want to be able to set the start date for a task into the future so that I can be reminded to start doing that task when it's appropriate.
• 39:48
  Josh Jordan: That's a great example. It tells us not only that we need to have a field for the user to fill out that start date, but now we know why it's important to the user. And so I might ask Joe as a response to that, well, do we also need a notification so that the user can understand on that date and be drawn back into that task? And if I said that, what would you say?
• 40:07
  Joe Rando: I would say absolutely. Yeah. So and that's the point is that it really draws at that process of explaining it that way draws out a lot of implications, which is what you were saying earlier. It's really it's really a powerful way. I've developed a lot of software over the years and it's definitely been the the best way to get started at least.
• 40:25
  At some point it doesn't become as important because they you've established the patterns but early on, it's really magical.
• 40:33
  Josh Jordan: Yeah. Exactly. So I've kinda given a lot of caveats. I hope I'm not making people think twice about whether software is the right direction for them to go. I don't want you to second guess that.
• 40:44
  My hope is that you can save a lot of time and money based on what I told you, but I I do wanna be really clear. I think that building software is how even a single person, like the listeners to this podcast, can create incredible scale in their business. I've seen clients who had good solid manual businesses that were working hard at every single day, then invested in putting their process on the web or into an app, and they're now seeing massive scale by selling their process via software. Now there are lots of years of work that went behind that to get their process right and the time and capital they put into building their software, but their work can be really significant. It's a really powerful approach to doing business.
• 41:23
  Joe Rando: Okay. So besides your book, which I'd love to talk about at the end here, do you have any resources you think would be helpful for a person going it alone?
• 41:31
  Josh Jordan: Yeah. There's a couple that I really like to point at. There's a site called UI patterns, uidashpatterns.com. It's a great site that you can use to kinda cobble together sketches of common user interfaces and user experience patterns to mock out and test your idea on paper. Go ahead and draw those out on paper or print them out and and cut them into pieces and look at it all end to end and get an idea whether it makes any sense to you before you share it with anybody else.
• 41:57
  The creator of DuckDuckGo, a wonderful search engine, name is Gabriel Weinberg. He wrote a book called Traction that I love about growing your user base. But first, I really recommend that everybody read Eric Ries's Lean Startup or Michael Gerber's E Myth Revisited. These books are not exactly specific to technology, but they teach you how to build scalable processes that can be implemented by technology rather than being an operator of your business. In other words, the one implementing that manual process.
• 42:23
  It shows you how to make that leap.
• 42:25
  Carly Ries: I'm gonna second that one. That is such a good book to read for anybody looking to get into entrepreneurship, solopreneurship, what have you.
• 42:33
  Joe Rando: You're talking about The E Myth Revisited?
• 42:34
  Carly Ries: The e myth. Yep. It is it's fascinating. It totally changes the way you think about it.
• 42:40
  Josh Jordan: Yeah. It it taught me a ton of lessons about my own business as I did it, and I can see how it applies to every single product I've worked on.
• 42:46
  Carly Ries: So, Josh, for solopreneurs, do you think a good community is important for people to have?
• 42:51
  Josh Jordan: Yeah. I really think that's that's the best resource that you can have. It'll keep you grounded, keep you on the right track. If you're lucky to hook up with the right people, they can even help to keep you accountable. Need to figure out what the right group of people for you to work with is.
• 43:04
  Joe Rando: Alright. So this is a standard question that we have for everybody on this show, and that is what is
• 43:09
  Joe Rando: your favorite quote about success?
• 43:12
  Josh Jordan: I love Reid Hoffman's quote that if you aren't embarrassed by the first version of your product, you've launched too late. It's not exactly about success, but I think launching is a key step and success it's a success in itself because some folks won't ever even get that far. Reid sums up a lot of what I talked about here in terms of not wasting your money gold plating your product. Get it out there, get feedback, and respond to that feedback. Your product is never going to be perfect or done.
• 43:37
  That's not the nature of business and certainly not the nature of software development. So don't chase perfection as a goal. Chase success with your product.
• 43:45
  Joe Rando: That's perfect. So, Josh, you can talk a little bit about how people might get a hold of you if they wanted to get information about your book or what you do for for your company and that kind of thing?
• 43:55
  Josh Jordan: Sure. You can get me on our website at supervillains.io, or you can just shoot me an email at josh@supervillains.io. I love talking about how we can improve the world with technology, and I'm happy to talk. If I can point somebody in the right direction, that's a big win for me. Please reach out.
• 44:12
  And you're right. We're we're launching the book soon in a few months. We're in the final phases of editing right now. It's called starting your startup, and it outlines 7 steps to launching an app on the web or on mobile. It starts by going in-depth on the things we talked about today and continues on through how a solopreneur should prepare and involve themselves for the rest of the software life cycle, meaning the design process, the development process, internal testing and feedback cycles, preparing for your launch, the chaos of a launch day, and where you go after your initial release.
• 44:41
  If you're interested at all on that, we're gonna be taking early sign ups and happy to give a 1 person business podcast, listeners a discount or release. So, Carly, I think you're gonna put a link in the notes.
• 44:52
  Carly Ries: Yep. Yep. There will be a landing page where you can sign up to get on the waiting list, and that link will be in the show notes. So be sure to check that out.
• 44:59
  Josh Jordan: Cool. Wonderful.
• 45:00
  Joe Rando: Well, Josh, thanks so much. This was really great. I mean, I've been doing this a long time, and I learned something today. So getting something into my brain is, is an impressive accomplishment.
• 45:11
  Josh Jordan: Absolutely. My pleasure. Thank you for having me.
• 45:13
  Carly Ries: My brain exploded, but in a good way. Good. Yeah. So thank you so, so much. We really appreciate it.
• 45:20
  Joe Rando: Thank you, Josh, and thank you everyone for joining and listening. And, obviously, please, please sign up for this podcast, subscribe, and there'll be lots more great stuff like this coming your way. So look forward to, next time. Take care.
• 45:33
  Carly Ries: You may be going solo in business, but that doesn't mean you're alone. In fact, millions of people are in your shoes, writing a one person business and figuring it out as they go. So why not connect with them and learn from each other's successes and failures? At LifeStar, we're creating a one person business community where you can go to meet and get advice from other solopreneurs. Be sure to join in on the conversation at community.lifestar with 2 r's.com.
• 45:56
  That's community.lifestar.com.