27: Questions to Ask Your Development Team

How can you, as a budding app owner, decide which app development team to hire? Tim provides a list of questions you can use to interview potential developers, as well as what answers you should be looking for.

In this episode, you will learn:

• What questions to ask to find a long term partner
• Red flags that can identify potential issues down the road
• Ways to figure out how a team thinks about development

This episode is a follow-up to a previous episode where we discuss how to choose the right development team for your project. You can find that episode here.

This episode is brought to you by The Jed Mahonis Group, where we make sense of mobile app development with our non-technical approach to building custom mobile software solutions. Learn more at https://jmg.mn.

Recorded December 4, 2019 | Edited by Jordan Daoust

Episode Transcript:

Welcome to Constant Variables, a podcast where we take a non-technical look at mobile app development. I'm Tim Bornholdt. Let's get nerdy.

Today on the show, we are going to give you a list of questions that you could ask anyone who is going to be developing your app. And in a previous episode, we talked about the different types of development teams you can hire for your project. And we thought it would be a useful exercise for you to hear some questions that you can ask any development team, and hopefully use that to vet out who would be a good fit for your project and who might not be the best fit. And, you know, regardless of whichever team you choose, you can really ask any combination of these questions and come to a conclusion as to whether they'd be the right development team for your project.

So first question, have they done a similar app in a different industry? Or are they experts in the industry that you're looking to build an app in? Sometimes you need to have somebody that obviously is an expert in whatever field you're dealing with. So if you're dealing with, say, a medical device that you're trying to build, it's useful to have somebody that's been through the ringer before of all the FDA approvals and dealing with HIPAA. And you know, there's a lot that goes into it. So hiring somebody that is a specialist in building social networks might not be the right fit for you. But in some instances, if you are, say, building a social network, you know, not all social networks are the same. So it's useful if somebody has built a social network that is geared towards one industry, but you want to gear it towards yours, it's nice that they have that experience, just broadly speaking, that they can apply to your project so that you're not necessarily starting from ground zero and the development team is learning, you know, kind of using your project to learn an industry.

Next question. What projects are they working on right now? It's useful to know, in general, what types of projects. If you're working with like an agency, for example, some agencies have a deep, deep knowledge in one type of app. Some agencies have a broad amount of knowledge that's not super deep, but covers the entire gamut of what you're looking for. So asking them, you know, what projects they're working on right now can give you a good fit to see if they're working on something that's going to be applicable to what you need built.

Next question, what apps can you try out right now? It's useful, obviously, to get a feel for what apps people have built. First of all, it's nice that you can go into the App Store and actually download something that somebody built. If you see an app that's in the App Store, that's a really good indication that they've gone through all of the things you need to go through to get an app listed in the App Store. But it's also nice because then you're able to get a feel for what types of apps they build. Do they focus really heavily on the user experience? Do they build a lot of animations and complex transitions between screens? Is the app really cluttered and unfocused? There's a lot of things you can glean by actually downloading some of the apps that they've built and trying them out for yourself. Now, again, this isn't directly applicable in some industries. Again, if it's an app that interfaces with a physical device, and it's like, you know, something like a pacemaker or whatever, I'm sure you're not going to go get open heart surgery to try out an app. But you can get a good feel for that. And also, some app developers are under a nondisclosure agreement. So they might not even be able to show you what apps they built. But either way, it's useful to just have that capability so that you can, you know, even sit down with them and try out those apps. Sometimes development teams will let you do that. But make sure you get a handle on some apps that they've actually built so that you can play around with them and see what you think.

Next question, what is their plan for the next five years? I think this is a good way to tell whether somebody is looking to sell in the space, and you know, this is one of those tough ones, because I'm sure that people are just going to give you the answer that you want to hear. But it's nice to hear, especially if you're interviewing an agency, you can get kind of a feel for whether they're looking, you know. Are really hungry? Are they gonna stay around for a long time and help you out with your app? Or are they just, you know, going to put you in and fit you into the slot because they're just looking to, you know, sell their company in the next couple of years. It's useful to know, especially for like contract developers. If you're interviewing a contractor, maybe they're, just, you know, looking for contract work just for the next year, and then they want to go take a full-time job somewhere else. That's useful because you don't necessarily want to hire someone just to do a quick job and not stick around for the long haul. Or maybe you do, just something to consider when you are interviewing your developer team.

Next, how skilled are the developers who will be working on the project? Sometimes you get a team that is all junior developers that have very, very little experience. Sometimes you get a team that is all senior developers with 15 years of software development experience. This is really dependent on, you know, what kind of project you're looking to build and who the team is. I find that in most projects, it's appropriate to have a mix of senior developers and junior developers. In our case, frequently, we'll have, you know, a senior iOS developer and a junior Android developer, and that will allow us to build everything out on iOS, test out API's and find bugs in the user experience or find bugs in the design that then we can apply. You know, we don't have to let the junior developers struggle over those things. They'll be worrying about other things that they need to get done. But they can just kind of lean on some senior team members to figure out, you know, if they come into any issues. So I would say that it depends on budget as well. Obviously, if you have a team of all-star, 15-year senior developers, it's going to cost something different than if you hire a bunch of, you know, 17-year-olds to build your app. So it really depends on budget and timeline, and how comfortable you are with all of those factors. But just something to ask is just asking about the skill set of the specific developers who, if you're hiring an agency, how skilled are those developers that are going to actually be working on your project?

On a similar note, you may actually know what platform your app is built in. If you're coming to find a development team, because you're replacing an old development team, you want to make sure that they actually know the platform that you need developed. So, you know, are you building out a native app? Does the development team have experience with Swift and Objective C? Or do they have experience with Java and Kotlin or is your app built in React Native? You need to know these kinds of things if you have an existing project so that you're not hiring, say, a team that is heavily Microsoft centric, so they're really specialized in Azure and .NET. If your project is all written in Ruby on Rails, and it's hosted on AWS, you just have to make sure that whatever team you are hiring, they actually have the specialty knowledge that is required to continue to work on your platform.

Next question, how do they ensure the app is bug free? This is somewhat of a trick question. I mean, it is a trick question because no app is bug free. So if somebody comes back to you with a response of, you know, we guarantee everything, and there's no way that your app is going to have bugs, that can be a pretty big red flag. But the point of this question is to hear how they deal with bugs. And they should really be able to explain what their QA, their quality assurance process is, for testing out apps and making sure that, you know, whatever app you have, they at least know about all the bugs. And sometimes in the industry, we say that we're shipping bugs knowingly, which is totally a valid thing. And any app that you use, even apps at Apple and Google and any of the big players put out, they all have bugs in them and they all know about certain bugs, but there's certain priorities of which bugs you fix. So all in all with this question, it's really making sure that they can talk through how they QA their apps to make sure that the apps that you're putting out for as many users as possible is as error free as possible.

Next question, how do they ensure that your app won't get hacked? Again, like the last question, this is a bit of a trick question. Because no app is hack proof. But really, they should be able to explain how they're going to use industry best practices and any other things that they've gleaned over the years to show how they're going to secure your app. So for this question, you should be hearing things like encryption and backups, and, you know, dealing with social engineering issues. There's a lot of things that you can do to make sure that your app is as hack free as possible. But again, this is somewhat of a trick question because let's just get it out there that any app can get hacked. If there's a way into the system, a hacker can find their way. So this is all about making sure that they just have a plan for if that ever is to occur.

Next question. Where is their development team located? So some agencies have sales teams that they have locally, where their development actually takes place in some other country or other state or just some other location. This is done in a way to save money. And sometimes it's done in a way to like, you know, drive down their profit, increase their profit margins by charging you the same thing they would have charged you anyway, if they hired locally. So it's not necessarily a bad thing to hire a team that does it that way, if they have a good process in place, and they've done it with many other clients. It's not necessarily the end of the world. And sometimes they really can save you a lot of money by having a local force here that's kind of selling and helping do the strategy. And then the actual development gets done overseas. Sometimes, though, you may want to actually have direct contact with your developers. And you may want to actually, you know, sit down face to face and show them what's going on and whiteboard out some solutions. So just make sure as you're picking your development team, if that's a concern for you that you ask them upfront where their team is so that you can have that option going down the road.

Next question, how do they keep my app up to date? Software is ever evolving, right? So iOS is going to come up with a new version of iOS; Android is going to have a new version of Android. We're going to get new phones; we're going to have new technologies. Things change quite a bit. And if you just kind of build your app one time, and let it sit in the App Store, you know, you check in on it. If you want to see an example of this, go download any app that was built eight years ago and not updated in the App Store. There's a lot of cruft out there. And users can tell when apps aren't updated, especially if they want to see new features. And if they want to, you know, have bugs fixed. So understanding how their process works for keeping apps up to date, and whether it's on you to monitor that or whether it's on them. It's just something that you're going to want to have negotiated as you're picking out your team to make sure that whatever you think is going to happen is something that they're going to actually deliver on.

Next question, how do they document their code and their processes? So this is a really important question, especially if you're hiring contractors. But if you're ever planning on transitioning to a full time team, and if you have a successful project, that's the ultimate end goal, right, is to have full time people working on your app. You need to make sure that whoever is building out your app initially is documenting their code. So when we're talking about documenting code, what we're really doing is making sure that the decisions that were made when they were developing the app are written down somewhere so that people that read it in the future can understand why decisions were made the way they were. And it's also when you're talking about documenting your processes, this is talking about how do you get into the server? How do you do version control? How do you make sure that you're able to keep everything in sync as you're deploying new code out? All these processes and things are unique and different. They vary between development team; everyone has their own way of doing it, even though there's a lot of similarities, there's still differences and you want to make sure that whoever is building this code is building it with the future in mind and kind of building this... You can say it's like building yourself out of a job. It's knowing that in the future, you're going to be handing this code to somebody else that's going to have to work on it. And worse off as a developer, sometimes you write code and then four years later, you have to go back into this project and you forget what you were doing. So having solid documented processes in place is the way to get around this. So that's one question you want to ask your development team is, how do they do that? And how do they make sure that they're able to transition the code in the long run?

Next question, I probably didn't need to tell anybody this, but how do they charge? Different app development companies charge for their services in different ways. There's hourly, just straight up however many hours it takes to get this thing done. We charge you a flat rate. There's project-based fees so they try to estimate everything out in advance and then charge you a flat fee every month until the whole thing is built. There's retainer-based where they can say, you know, we can work on it for 800 hours, so you pay us 800 hours, and we draw down on that amount of money as we work. There's many, many different ways to do this. And I think just like with all these questions, you need to figure out what works best for you and your situation and your team. And make sure that those are in alignment, and that you guys have talked about this upfront so that there's no surprises going forward. You should also at the same time, ask them, how do they charge for change orders if they're going to do everything upfront? Do they do a change order where they will charge you an additional fee? Or do they just go hourly if it's out of scope? And how do you know when something is out of scope? All the things around money and how projects get charged is something that you're going to want to make sure you are very clear on so that there's no surprises going forward because app development is pretty expensive.

The next question, this is actually a question that a client asked us several times and I laughed about it after the fact, and it kept coming back to me, like, no, this actually is a really good question to ask a development team. And the question is, do they "get" your project, and get is in air quotes. And by "get", I mean, "Do you understand?" This is super important for your technical team to really understand the reason for the app existing. Developers, when you're going through and making apps, they make a lot of decisions that they're not necessarily vetted by you as the app owner. A lot of times they kind of make these decisions in isolation. And so having a good understanding of the overall goals of the project can really help alleviate and really make a difference between a company that gets it and doesn't get it. And also having a company that understands how to execute on whatever strategy you're going after. You know, how does this app make money? Knowing that and having your team know that that's a primary goal of yours is really going to help you in the long run. So finding... I think this is one of those intangible questions, but something that's super important, and I apologize for laughing about it to the previous client, but I've learned my lesson and now I really do think that that's an important question to ask your technical team is, you know, do they get what you're doing?

Next question, what is their development process? We kind of touched on this with how do they charge it. Sometimes it ties into their development process. But when you're talking about software development, you'll hear two commonly used approaches for development. And that's agile and waterfall. So agile development is where you're taking a big project, you have a long concept of what you want the app to be, and you break it down into chunks. Like usually, it's, you know, two to four weeks; they call them sprints. And you say, you know, within this two weeks, we're going to make it so that you can sign into the app. And then in the next two, after the two weeks is up, then you evaluate where you're at. And then you plan, you know, you take a week to plan out what the next sprint is going to be. And then you go into the next sprint. This is a pretty common approach in software development, because as you're going through development, things change pretty frequently. So it's nice to not have a giant roadmap of features that's done upfront, which is the other approach, waterfall. So, waterfall like I said, it's where before the project begins, you spec out the project from top to bottom and you say, you know, this is how this screen is going to look, this is how this screen is going to look. You're going to do the whole thing upfront. You're going to get a bid on that amount of work. And then if things change halfway through, you have to go through change orders, and you have to figure out how you're going to deal with changes to the initial spec. Usually, you know, I like to say our organization is pretty agile-ish. And I think most companies are in that, trying to go that route, as well as being purely agile. There's like an actual book and everything around the agile movement. So there are companies that are strictly agile, and I would say most companies are agile ish, because at the end of the day, most clients want to have some understanding of what things are going to cost and have some budgetary mindset around it. So there's a way that you can approach it where it's agile-ish, where you are iterating quickly but you're also not locking people in, and we get around that by just doing hourly rates and having monthly checkins to make sure that we're hitting goals. So I would say if when you're talking to your development team, just make sure you understand what their process is. And this actually becomes really important if you're hiring a bunch of contractors and doing things ad hoc, or you're picking, you know, here's my iOS developer, here's my Android developer, here's my server developer, and they've never worked together before. They're going to have to figure out a process that gels for them and works for their flow. So understanding the process is pretty important. And it's going to be different between the different types of teams. So just make sure you have a handle on that when you're going out and picking your team.

Next question, who owns the code after they're done? When you're talking about software, IP, intellectual property, is everything, right? If you don't have ownership of the code, you really don't own anything. So you want to make sure that whoever you're working with, and this is the thing that's tripped us up before in the past too, is if you go and hire a contractor to build out your software and you don't have terms in your contracts that say that this is a work made for hire and that you're assigning intellectual property over to the company, then you're kind of in a position where the person who developed the code is the one who actually owns it. That's how copyright law works. So you need to make sure upfront that you are assigning the code properly to the company that's paying for the software. And that's the thing too, is like, even if you pay somebody else to build something for you, they still built it, and they still own the copyright to it. So upfront, make sure that you identify who owns the code. And one thing I wanted to cover in this section too, is when it comes to ownership of code, you know, our organization, because we are an agency and we write a lot of source code, a lot of our source code is stuff that can be reused in other projects, right? So, you know, let's take an app that has like a profile picture, for example. The profile picture is not necessarily something that's like exclusive and proprietary to your app. So we reuse a framework that we built that, actually, we plug into all of our apps. We can skin it and customize it to the way that we want it to look. And then it just helps us develop things a lot faster. If we were to write that code and give you the rights to all that code, then legally, we wouldn't be allowed to do that again in another app. And we'd have to rewrite the code again from scratch. So sometimes what companies will do, and this is how we do it is, we give you the ownership to your code, because it's your code. You paid for it. We think you should own it. But then the code that we reuse across multiple projects that's not necessarily proprietary to your app, we will get, basically, we retain ownership rights of that code, but we give you a license that says you can do whatever you want with that code and and it's yours to copy and distribute and do whatever you want. And from our perspective, and after like our consulting with our legal team, that seems to be the cleanest way to do it so that everybody's happy. We are able to continue to do what we do and make money by working with other clients and you're able to continue to do what you do and you've got a pretty profile picture capability within your app.

Next question, how will they keep you updated on progress? Communication is probably the most important thing when it comes to a development team. The worst thing that you can get is what I like to call the the Mount Sinai situation where you basically, you know, have Moses going up to the top of Mount Sinai and then descending with the 10 commandments and being like, well, here it is. Here's the law. You just deal with it. And you know, when you get a developer that goes into a cave, like you give them, here's the spec to the project, and then they go off and just do their thing, and then come back to you six months later and say, here's your app, it's done. That's not really useful. And I'm sure you'd be biting your nails the whole time being like, I paid you a ton of money, where's my stuff? So I think the important thing here is just establish a pattern upfront of how you're going to communicate progress. Does the team communicate in a weekly standup? Do they want you to be part of that stand up? Do they communicate monthly? Do they communicate, you know, every other week? You know, can you call them on the weekends? Can you call them after hours? What are the times that they can talk to you? Is email preferred before phone call? All of these ways for figuring out communication, I find it's best to establish those rules right upfront with a kickoff meeting in the project to make sure that you guys are on the same page with how you're going to actually communicate the progress of projects. And when problems do come up, there isn't a weird barrier. You guys can work together to figure out how to get the problem solved.

Next question, how involved will I be in the process? This again, kind of like we talked about before, with keeping you up to date on progress. Sometimes people and clients that we have want to be very, very involved with development. And I mean, down to the point where they're working on figuring out logic issues within the apps and picking out colors and being involved in the App Store Connect setup of the project. So sometimes clients... it's a spectrum, right? Sometimes clients really basically want to be learning app development, and some clients are just like, I've got this problem I need solved. I don't care how it gets solved. Just come back to me, like we talked about like the Mount Sinai situation. Sometimes people want that where it's just like, go into your cave and do your thing, right? And it's a spectrum somewhere in that some development teams work really well on one end, some work really well on the other. So ask them, how involved will I be? And how involved can I be? Maybe you do want to be very involved in the process, and maybe you don't. So make sure that you have a good set of expectations between you and your team so that you're on the same page with how involved you're going to be with making decisions in this process.

And finally, the last question, and probably one of the most important questions is, can I see references? reference checking is absolutely Critical, especially when it comes to a software development company, you want to make sure that these people have done what they say they've done. There's a lot of scams and scuzzy people out there that will take your money and run with it and ghost you and you'll never see them again. And I've seen that time and time again, from clients. And it happens like in the middle of projects, it happens, you know, it happens more often than you would like. So a reputable company, when you ask them for references is going to say, Oh, yeah, here's a list of, you know, five people you can call and here's one that has a project that's very similar to what we're talking about here. So you can ask them how things went. And this is super illuminating. Because if you go to a client of theirs and ask them questions, they're going to tell you like straight up, here's what was great. And here's what wasn't unlikely, you know, there's going to be things that obviously the company's not going to tell you of things that might have gone wrong and issues that happened but at the end of the day, it's you want to make sure that they're if you if you talk to somebody else that's had a good experience that social proof is is critical and and can really help kind of steer you in the direction of one way or the other. It can ask them questions about culture and ask them questions about, you know, all the things that we've we just gave you like 20 questions, right? So you can ask them some of those questions and see how they responded on those things and how they're dealing with those issues. And that's going to help you kind of pick the right team that's going to fit for your specific case. All right, we made it to the end of the questions, huh? That's, that's a lot. So some final thoughts that I wanted to throw your way. One thing with going through all these questions is, I don't think that you're going to find a development team that's going to answer every single one of these questions what you would call like, you know, the right way. Every single team is different. And different teams work really well on different projects. And a team that may have delivered exceedingly well on one type of project may do incredibly poorly on another type of project. I think the goal with all of this is to find a team that fits your style of work the best. So use these questions to vet out and kind of get a feel for what's going to be the right fit for you. And your Going to pay dividends by interviewing multiple teams and hearing multiple responses and kind of trying to use these questions to synthesize a response of what team is going to be best for you. Well, thanks for tuning in to the episode today. Show Notes for this episode can be found at constant variables.co. You can get in touch with us by emailing Hello at constant variables Co. I'm at Tim born old on Twitter and the show is at CV underscore podcast. We're also on the Instagrams. Today's episode was edited by the unflappable Jordan doused. This episode was brought to you by the jet bonus group. If you're looking for a technical team who can help you navigate these complicated waters of mobile software development, give us a shout. We're at jmg.mn

Next, how will they measure the success of my project? So there's a lot of different ways to measure success. And again, just like we said, upfront, it's good to have these expectations set right away. Does success mean that the app is in the store? And we're done? Does success mean that you've made a million dollars in the app store? Does success mean that anyone can use the source code and do whatever they want with it? There's a lot of different things you can do here to measure success. And I think that everybody would be happier upfront knowing that we have this goal at the end of the project that says when the app does this, that's a success. And being able to not only know what those success points are, but celebrate them when you actually do hit that point. So make sure you have that also in line when you're talking about finding a technical team.

Next question, how did they think about design? So when it comes to design, we like to say that it's both UI and UX, so user interface and user experience. Steve Jobs had this famous quote that a lot of people around design say that, "Design is not how something looks; it's how something works." And so how something looks would be more of the UI, the user interface, and how something works would be more of the user experience, the UX, when it comes to your project. And in your technical team, a lot of technical people maybe aren't exactly designers, right? I'm certainly not. That's why we have designers on staff that make things look good that we build, but sometimes it's very ingrained into their culture. They actually have designers that are developers as well and they're in there doing the design work to make sure that it looks good while they're building it. It really again depends on your style and your development team's style and making sure that you guys mesh with how important design is to you as a company. Maybe you're willing to just use more stock elements and be more on the just, you know, it works well side of things. Where some teams might really want it to be something that looks really, really beautiful and has all these animations and beautiful color scheme. So make sure you have that in line when you're talking to your developer team.

Homestretch here, three more questions. How do they deal with technical debt? So this is a question you can ask to really get a handle for how people are going to be coming back into your project. And we kind of alluded to this earlier. But I think throwing out the term technical debt is really going to be illuminating to see if your team understands the concept and they're actually thinking about it. So what is technical debt? Technical debt is, as time goes on, when you have a project, you're going to change things. There's going to be new features that get added. There's going to be features that get abandoned. Apple is going to change things. Google is going to change things. The software is going to be evolving. And as this software evolves, there's more stuff that just gets put into your app. There's frameworks that get plugged in that never get used. There's code that just references things that don't get referenced anymore. And there's just all this cruft that builds up. And we call that technical debt, because at some point, all of that cruft needs to be paid off, and it needs to be removed or changed or refactor it or whatever. So having a plan for dealing with that technical debt and having a team that has that foresight to think about what they're going to do with that is illuminating, because it shows that they're going to want to be around for a while and help you deal with these problems as they come up. So keep that in mind as a possible question that you can throw in there as you're interviewing a team is how they deal with that sort of technical debt.

Right. These last two questions are really kind of intangible. They help you feel out, you know, how a team is going to be working with you. So first of all, what are their response times to your questions? Sometimes a team is lightning fast and they get back to you really quick and they're willing to meet with you for coffee and do whatever it takes to really help you understand what's going on. And some teams are not so fast, and they put you on the back burner. They don't respond to you for a few weeks at a time. And sometimes that can be an indication either that they're really, really busy or that they don't care or that their processes are misaligned, or something's going on. So I would say that, when you're interviewing a technical team, the way that they perform as you're going through the sales process is going to be very, very indicative of how they're going to perform when they're in the development process. So if they're quick to respond to your questions, and they're quick to answer any problems that you have, likely when you're going through development, they're going to be quick at responding to those things as well. So this isn't necessarily like a question that you can ask them, it's more something you feel out while you're going through the development process. And keep that in mind because people don't typically change and same with organizations is things pretty much stay the same. So just monitor how quickly they get back to you. And keep that in mind as you're moving into the next stage of your development process.

And finally, the last question, and probably one of the most important questions is, can I see references. Reference checking is absolutely critical, especially when it comes to a software development company, you want to make sure that these people have done what they say they've done. There's a lot of scams and scuzzy people out there that will take your money and run with it and ghost you and you'll never see them again. And I've seen that time and time again, from clients. And it happens like in the middle of projects, it happens, you know, it happens more often than you would like. So a reputable company, when you ask them for references is going to say, Oh, yeah, here's a list of, you know, five people you can call and here's one that has a project that's very similar to what we're talking about here. So you can ask them how things went. And this is super illuminating. Because if you go to a client of theirs and ask them questions, they're going to tell you like straight up, here's what was great. And here's what wasn't. Unlikely, you know, there's going to be things that obviously the company's not going to tell you of things that might have gone wrong and issues that happened but at the end of the day, you want to make sure that they're... If you talk to somebody else that's had a good experience that social proof is critical and and can really help kind of steer you in the direction of one way or the other. You can ask them questions about culture and ask them questions about, you know, all the things that we just gave you, like 20 questions, right? So you can ask them some of those questions and see how they responded on those things and how they're dealing with those issues. And that's going to help you kind of pick the right team that's going to fit for your specific case.

All right, we made it to the end of the questions, huh? That's, that's a lot. So some final thoughts that I wanted to throw your way. One thing with going through all these questions is, I don't think that you're going to find a development team that's going to answer every single one of these questions what you would call like, you know, the right way. Every single team is different. And different teams work really well on different projects. And a team that may have delivered exceedingly well on one type of project may do incredibly poorly on another type of project. I think the goal with all of this is to find a team that fits your style of work the best. So use these questions to vet out and kind of get a feel for what's going to be the right fit for you. And you're going to pay dividends by interviewing multiple teams and hearing multiple responses and kind of trying to use these questions to synthesize a response of what team is going to be best for you.

Well, thanks for tuning in to the episode today. Show notes for this episode can be found at constantvariables.co. You can get in touch with us by emailing Hello@constantvariables.co. I'm @TimBornholdt on Twitter and the show is @CV_podcast. We're also on the Instagrams. Today's episode was edited by the unflappable Jordan Daoust. This episode was brought to you by The Jed Mahonis Group. If you're looking for a technical team who can help you navigate these complicated waters of mobile software development, give us a shout. We're at JMG.mn.