Category: Mobile Services

As a startup coach and as a freelance app developer, that’s a sentence I hear a lot. Entrepreneurs with a business idea, but not necessarily the tech know-how to make it a reality, want to know what it takes to develop a mobile application. And of course, like many things, it’s not as easy as it looks, there are many blind spots, a lot of misconceptions and depending on who you ask questions, you might get very different answers.

So in this post, I will try to cover all of the questions that I generally ask back to entrepreneurs who come with this statement. I will do it from my point of view and based on my experience as both a Lean Startup coach and a Belgian freelance software engineer. I co-founded the NEST’up startup accelerator a few years ago, I coached at least a dozen entrepreneurs, especially to Lean Startup principles and techniques, and as a developer I have developed a couple of apps. A few years ago, as a VP of Engineering for Take Eat Easy, I even supervised the development of a whole line-up of mobile apps for consumers, restaurants and couriers.

So if you want me to answer the big question, here are the “small” ones you need to think about first.

TLDR; This article is long, so if you want to skip to a shorter version of its content, here is a small document I prepared for you.

Do you really need an app?

Mobile apps are everywhere, we use them everyday, and as an entrepreneur, it’s easy to think they are necessary to any serious business model. But remember that a startup IS NOT an app, it CAN HAVE an app, that is only a part of your overall business model. It can be one of your sales channels, one of your promotion channels, one of your customer support channels, sometimes even part of your logistics, but you have many parts to figure out around all of that, many hypotheses to validate about your pricing model, your customer target, your marketing, your competition, etc. And if you count on a fully developed application to figure out all those things, you are taking a huge risk, because (sorry for the first revelation) AN APP IS FREAKING EXPENSIVE! And by that I mean developing a fully custom application, with your brand on it, and all of the features you dream about.

So the first question you should ask yourself is whether there aren’t any other creative ways to de-risk your investment, to validate your hypotheses about who your customers are, what problems you want to solve for them and what a solution to those problems could look like, without developing an app. There are dozens of examples of that in entrepreneurship history, from Zappos to Airbnb all the way through AngelList: a website or an app is not the most efficient way to figure out your business model early on. It can be part of a strategy, going through different forms of your products, getting progressively more and more sophisticated as you understand your market better and better, but it is rarely the first phase of that strategy. So think about mailing lists, setting up a simple phone number to respond to your customers’ requests directly, off-the-shelf Drupals or WordPresses or forums, a Slack or a Discord, a Google Form, or even a no-code app that you can configure yourself (Bubble, Quixy, Airtable, Webflow, Glide, etc.).

Granted, those early channels are often not very scalable (they are often called “concierge mode”), but remember that when you start up, your most precious capital is not “a lot of customers” or even money, but validated learning. It is all the things you learn about your market. Those validated hypotheses can get you funding (through sales and investors), they can prevent you from wasting valuable money and energy on developing features no one will use, they will be a competitive advantage over all the competitors who will just jump on making an app, and they will help you clarify and prioritize what your future app will really need, which will inform the initial UX design, which is a prerequisite to any budget discussion.

Of course, mobile app development agencies will rarely tell you that, but as an app developer, I would rather have you come back to me in a few months with a clearer idea of what your market needs in your app, and possibly even some funding, than trying to develop an app now based on a very vague idea of its design, no funding and a huge risk that I will end up developing a throw-away application and building a very stressful relationship with you.

Are you ready for a long-term commitment?

A lot of business-only entrepreneurs imagine developing an app or even a website as a one-time thing. They are looking for a magic budget number that they can add to the one-shot column of their business plan and call it a day. And unfortunately, some development agencies, who prefer working on fixed price projects, will go along with that misconception.

But the fact of the matter is that your app, just like your business model are living things, especially for a startup. Your market will change a lot around you, independently from anything you do, and all throughout the life of your company. Think about the impact that the COVID-19 crisis had on a company like Airbnb for example, or even Zoom, and how it impacted their apps’ features. And of course your company itself will change a lot over time, you will onboard more customers, with more diverse needs, expectations and tech-savvyness levels, you will scale up to integrate with third party systems like Customer-Relationship Management (CRM) platforms or customer support platforms, etc. And of course, the mobile ecosystem itself will evolve under your feet, what mobile devices can do, their technical characteristics, the technology used by developers to build those apps. All of those changes, whether they are internal or external will require a constant ongoing and recurring effort to update your application(s), some features will need to be re-developed because of tech changes, some features will need to be removed or added over time, your branding will probably also change every once in a while.

All of those changes are the reason why Pivoting is such a key concept, and why any business model reflection should start with clear values, a long term vision statement, and a strategic mission statement.

And that’s also why on the long run, most startups who have their own apps also have their own developers in house. Now even though it would be too big of a risk to try and hire a whole team of app developers right away, it’s important to look for partners that you can create a true partnership with, with a lot of trust, flexibility, expertise and initiative.

For example a lot of agencies will work on a fixed price contract: so they will ask you for a detailed specification beforehand, they will estimate a budget and a time frame for that specification, generally add some extra contingency in there, and start working on that. That generally means you won’t see anything while the app is being developed, you will have to wait for the end of the contract, or very late in the implementation to actually see a first version of your product (tunnel effect). And if you realized some important change was necessary in the specification, you will have to pay more to amend the specification and implement those changes. Some agencies go as far as to make you sign a seemingly very cheap fixed price contract at first, knowing full well that they will be able to make up for it in change requests later on, at which point you will be locked in to them, you will have no choice but to pay them to finish. Which kind of defeats the whole purpose of fixed price, right?

The fact of the matter is that fixed price contracts only ever make sense for well known and pretty stable app development projects, like an app for a restaurant or a hairdresser or a news platform, etc. In those cases, the feature list is pretty easy to estimate and pretty stable too. The thing is that in most of these, the needs are so generic that a simple no-code app will do the trick just fine. But fixed price is not realistic for a startup. You need to think in terms or time-and-material.

In this collaboration mode, whoever develops your app will invoice by the hour or by the day of work, and then it’s up to you to figure out how much of your monthly budget you can dedicate to building your app. The more you need to get done, the faster your need it, the more expensive it will get. But generally, this kind of collaboration is based on an Agile process that gives you a lot of visibility and power over the backlog of what needs to get built, the priorities that you determine, and it even gives you the possibility to modulate your budget based on your cash flow, or even to interrupt development if it’s not working. Then one of the questions becomes how much you will pay for each hour/day of work, and this can vary greatly. In Europe for example, we are generally talking about upwards of 50€/hour or 400€/day of development all the way to 100€/hour (or about 800€/day), sometimes more if there are intermediaries involved or a lot of corporate overhead. That depends on the expertise of the developers, how much of the whole development process they can take care of (more on that later), but more importantly their experience and how fast they work, and how much coordination and project management are needed. If you hire a 400€/day developer who invoices twice as many days and doubles your time-to-market compared to a 800€/day developer, the total cost of development may not vary that much, but it can have an important impact on your growth. Another important aspect is quality: a 400€/day developer will generally be a junior developer, with a small amount of experience, and can sometimes produce buggy code, that will require a lot of back-and-forth, and a code base that might be very hard to pass over to other developers later on, or to simply maintain on the long run. Clean code and good software architecture also make a huge difference when you want to add new features over time. Think of it like the difference between a house built by an experienced construction craftsman and one built by a rookie do-it-yourself amateur. This difference is generally very hard to evaluate for non-technical founders but it can truly make or break your business perspectives: look up Technical Debt. I won’t do it here, but I can tell you many stories of companies who took too many shortcuts, or didn’t invest enough in the right development partners early on, and then came very close to or downright failed because of it.

And then of course, there is the possibility of near-shoring (Eastern Europe, North Africa, etc.) or off-shoring (India, Pakistan, etc.) your development. Off-shoring is usually the cheapest option, near-shoring being the least damaging compromise, a little more expensive than off-shoring but less “remote” in all meanings of the term. To be completely honest with you, I personally think that off-shoring is almost a scam. Not necessarily in terms of technical expertise, as countries like India have very good education systems and very capable engineers. But there are things in their management culture (very little place for individual initiative), in their organization (a lot of turnover on projects), in the culture shift (their usage habits are simply different from a European’s) that generally more than make up for the apparent savings on daily rates. And I’m not even talking about the problems caused by timezone differences, language quirks, and again, “remoteness” in all possible ways. Most big companies who still work with offshore partners in India have some of their people there, on site, to manage and monitor projects and report back home, and otherwise need big support teams in house to specify everything in the most minute details so that Indian developers can then implement the specification without having to fill in any gap. It’s exhausting, and it’s expensive on the long term. So don’t do that.

Near-shoring is less of a stretch, the timezone difference is less of an issue, they are culturally closer to Europeans, so collaboration is generally smoother. And it is easier to find partners or agencies with a stronger sense of entrepreneurship and initiative who will be better at turning some of your vague ideas into actionable features without the need for bible-like specs. But still, the risk is higher, and I have seen more projects fail when working with Bulgarian, Polish or Romanian developers than with closer-to-home developers. Of course I would say that, I’m a freelance Belgian developer, and my daily rate is in the upper part of the ranges I gave earlier. But the one thing you should take away from this is to not just look at the daily or hourly rate. Think of the total-cost-of-ownership or your app. How long will it take to develop? How will it affect your time-to-market, both for the initial version of your application and for future features and changes? How will it affect the quality of the deliverables, and how your app will react to subsequent waves of new users? How easy will it be to grow the development team, and ultimately take over development entirely with your own people? These are all important factors to consider as a business owner, and there is no miracle: what you save one way, you generally end up paying for it another way.

What does your app need?

Mobile apps rarely work in a vacuum. Most apps work in conjunction with a backend of some sort. We will talk about different kinds of apps in the next section, but whatever the kinds of apps you need, they generally store their information in a database, and their files (pictures and other documents) on a file server of some sort. Plus, if your app processes payments, needs to receive push notifications, or integrates with third party services, all of those things are generally integrated on the backend. This server-side software is vital to most apps and its development, hosting and maintenance needs to be factored in to your app’s development time and budget.

Development of that kind of software generally involves a very different skillset than the one required to develop frontends like mobile apps or websites. And it’s rare to find those skills in the same person. There are even some development agencies who specialize more in frontend or backend development, and some frontend agencies specialize in either web or mobile development. Personally, I started my career as a backend and web developer, before extending my skill set in mobile development. So I can do it all which has a positive impact on efficiency and speed since there is less coordination needed between different actors, and more consistency between the different components of the overall software system. On the other hand, it’s true that more specialized developers can have more expertise with very specific aspects of backend or frontend development like:

• security: highly critical datasets like financial or health data for example
• compliance: certain specific regulations you need to abide by, like PSD2, etc.
• performance: dealing with huge surges in usage like food orders, time-based sales, etc.
• data-mining: big data analysis, machine learning, business intelligence, etc.
• integration: Single-Sign On integration with corporate systems, Enterprise Resource Planning (ERP), Customer Relationship Management (CRM), etc.
• 3D and gaming for frontend applications involving Augmented Reality, Virtual Reality or simulation
• Media applications like sophisticated image, audio or video processing
• And many more.

If your app involves one of these things, it might be interesting to look for partners who have specific experience in these domains.

But whatever the case, in addition to your app, you will need a backend to be developed, but also hosted, monitored and maintained. Hosting refers to making the backend available on a server somewhere, either in house (data center) or in the cloud (Amazon Web Services, Microsoft Azure, Google Cloud, etc.) so that apps and other frontends can access and share data and files over the internet. Monitoring involves setting up the right tools and processes so that if any of your backend components crashes or fails for whatever reason and becomes unavailable, your team is immediately notified and the situation can be remedied as soon as possible with a minimum loss of business. And maintenance implies regular security and performance updates to your backend software so that it remains available and doesn’t expose any of your customer data to your competitors, hackers or other unauthorized users. Sometimes, you will here those concepts referred to as DevOps, where Dev is the development of your backend and its databases, and Ops (or operations) is the hosting, monitoring and maintenance part.

To make things easier, there are a lot of Infrastructure-as-a-Service (IaaS) or Backend-as-a-Service (BaaS) solutions that automate a lot of those things. For example, I personally love Google Firebase, that relies on the infrastructure of Google Cloud. It is incredible versatile, easy to integrate and crazy cheap for startups.

But overall, the complexity of your data model, the criticality of the data you want to store and process, the number of third-party services you want to integrate with your services, all of those backend things will influence your app’s overall budget and time frame by a lot.

Last but not least, coming back to the app itself, you need to think about the device features you will need to integrate with:

• Geolocation, whether it is one-off instant location, location tracking, navigation or even location-based notifications (geo-fencing), and at what level of accuracy (country, city, neighborhood, meter)
• Camera, whether it is taking pictures or loading pictures from the photo library, taking videos (or loading them), recording audio, etc.
• Phone data sources like the address book, the calendar, etc.
• Bluetooth, whether it is connecting to your own devices, scanning for nearby Bluetooth beacons, etc.
• More cutting-edge device-specific capabilities like Augmented Reality (AR), client-side machine learning, mobile assistant (Alexa, Google Home or Siri), etc.
• Gyroscope, compass and other instruments built into devices
• Map access and associated services like geocoding, reverse geocoding and so on
• Push notifications, whether they are individual and transactional or more generic marketing announcements and offers
• And some more.

Those mobile capability integrations have a big impact on the kind of tech stack that can be used (more on that later) and on the overall complexity of your application.

Who is the app for?

The most important aspect of your app is its users, and depending on who they are, how many of them there are, and how heterogeneous they are, it will have a big impact on your app, how long it takes and how much it costs to develop and maintain.

First off, what big categories of users will interact with your app. For example, if you are just selling your own products through your app, there is only one category of users: buyers. Or is there? Because you will probably need to update the information about your products, add new ones, etc. And you don’t want to call developers each time you want to modify data in your database. So most likely they will need to provide you with some form of backoffice, either mobile or more likely web-based, that will let you manage all your data. For more sophisticated multi-sided platforms like a food delivery company for example, you might have other users like couriers, restaurant staff and customer support people in addition to consumers themselves. Each of these categories of users will come with their own needs and features, and the more you try to cram all those features into the same app or frontend, the harder it will be to use. So you might need several apps, or an app that can easily adapt its interface to the kind of user using it. And one important instrument to think about all that is user personas: do you have a user persona for each of your user groups?

Another element to take into account is mobile platforms. There are mostly 2 dominating mobile platforms out there, Android and iOS, with different market shares depending on the country and specific demographics you want to address. If your customer target is mostly made up of CEO’s and high level executives in the US, you will likely have more iOS (iPhone) users than Android users. On the other hand, if you target third world countries, you will have more Android users, and not the most up-to-date kind. Figuring that out can have a huge impact on the complexity of your frontend. If you already have a first preliminary version of your product, analytics can give you numbers on that.

The smallest common denominator is generally a responsive website, meaning a website that adapts very well to all sorts of form factors, including vertical smartphones or all sizes. These responsive websites generally work on all devices, even the oldest ones, whether they use Android or iOS as their operating system, and they are easier to update and maintain since you don’t need to make them available through the Apple App Store or the Google Play Store. But they generally offer a sub-par user experience and limited integration with the device’s capabilities.

Then we get into the real app territory, and there too, there can be several approaches. The most natural one is what we call native apps, meaning apps (plural) developed specifically for each platform with the technologies provided for each one. Those native apps provide the best possible user experience, best performance and best integration with device capabilities like geolocation, camera, Bluetooth, etc. (more on that later). But they do so at the cost of having to develop and maintain two different applications that you will need to keep in sync. If you can find a developer that can develop both native Android and native iOS apps (like yours truly ?), that will be ideal in terms of coordination and consistency. But again that is rare, as most software engineers specialize in either one of these platforms. So this model is more adapted when your early users tend to use one of those two platforms, so that you can focus on building an app for it first, and then later expand your investment over to the other one when you are ready for it.

Finally, you can go for the hybrid app approach: there are technologies that make it possible to develop apps for both platforms but with just one code base, or at the very least with all the common code in one place, and a little bit of platform-specific code on the side. Those technologies are often third party, which means they are provided by other actors than Apple and Google, hence they need their own development tools and specific skill sets. Here are some big names you might hear about:

• React Native is a technology provided by Facebook, that makes it possible to develop native apps for both Android and iOS using web skills like Javascript (probably the most popular right now).
• Xamarin also makes it possible to develop native apps for both platforms but using Microsoft technologies (C#, .Net, etc.)
• Flutter is a toolkit provided by Google that offers excellent performance (same as native), excellent developer experience and although it is the most cutting-edge of those three, it’s rapidly gaining in popularity (which personally pushed me towards it).

And there are other such platforms but I can’t cover them all here. The one thing to take away is that the choice of software strategy (what we sometimes refer to as “tech stack“) will greatly impact the user experience of your users, your time-to-market, the maintainability of the whole thing, how easy it will be to bring on more developers or hire your own one day. But the best tech stack is the one that your software developers master, so choose your partners wisely and let them work with the technologies they do best. And again, all of that depends on who your users are, and what sort of devices they use.

About that, it’s always important to think about form factors. Most mobile apps are primarily for smart phones, but if you simply use a smart phone app on a tablet like an iPad, the user experience will be awful. So even with a native or a hybrid app, you might want to think about responsiveness, which is how the application needs to adapt to bigger screens like tablets.

Last but not least, don’t forget to think about the languages your users understand. Internationalization is often an overlooked topic but it can also impact your software architecture and the cost of your apps. The easiest thing is to internationalize your app’s user interface, meaning all the buttons and generic elements of it. But if you also need your data to be internationalized, like restaurant menus for a food delivery app, or product listings for an ecommerce app for example, then it’s a whole different story. Plus, some languages read right-to-left instead of left-to-right, or use other character sets like Chinese or Russian, and this can also greatly impact the design of your app. Whatever the case, you will need tools, processes and resources to translate your app’s interface so that it remains usable for all your users. And even if your app only targets French people in France for now for example, you might want to prepare internationalization right now for the day when you want to grow your business outside of those borders, knowing that it can be much more expensive to add that internationalization after the fact.

How will your app make you money?

In general, your app will at least be part of your sales channel, which mean you will use it to sell goods or services. And there are many different ways to monetize your app.

The most obvious revenue model is to sell your app directly, which you can easily do for native or hybrid apps you sell through the App Store or the Play Store. In that case, you don’t sell your app directly, Apple or Google sells it on your behalf, and pays you royalties after taking a commission. This commission used to be a hard 30% for both platforms, knowing that you could still offer your app through another channel like a website on Android (side loading), but you can’t do that for iPhones. These 30% might seem harsh, but remember that it includes payment processing fees (generally around 3% anyway), hosting and promotion of your app on the store, access to platform services like push notifications, etc. And of course this lets Apple and Google finance the development of all the tools and technologies used by developers to create your beautiful app. Plus, as I said, it used to be 30%, but recently, Apple announced a small business program that makes it possible for small businesses and startups with less than 1 million dollars in annual revenue to take advantage of a 15% commission instead of 30%. You can already enroll today, but the program will only be launched on January 1st 2021. And it would not be surprising to see Google offer something similar soon. But there is a problem with this revenue model: it creates a huge barrier to entry: only a small proportion of mobile users are ready to buy mobile apps outright, and they have to be convinced of its value before they hit the purchase button.

Which is why another model has become extremely popular over the years: in-app purchase. With in-app purchases, you can offer your app for free, and then offer services and feature access inside your app for a fee. That fee will be submitted to the same 30% (or 15% for small businesses on iOS) as if you sold your app outright, but those in-app purchases will go through the same painless payment process with the card or Paypal account associated with the user’s App Store or Play Store account. There are two important limitations though:

• If you are developing a Business-to-Business application, selling your services to companies instead of end consumers, those companies generally require business invoices and payment channels (check, on-invoice, etc.) that are not supported by the heavily B2C-biased model of stores. The good news is that Apple has an exception in their conditions just for that use case that lets you offer other payment channels in addition to in-app purchase. Unfortunately, it doesn’t look like the Play Store has similar exceptions yet.
• In-app purchases are only for virtual goods and services that users can access within the app. If you are using your app to sell physical goods to be consumed in the real world for example, you must use other payment channels. And integrating a payment processor like Stripe, Paypal, Adyen or similar also has a cost per transaction in addition to the development cost to integrate them into your app and backend.

And then of course, beyond those payment channel considerations, there is the question of the revenue model itself:

• Will you take a commission on each transaction where your user buys something through the app?
• Will you have a recurring subscription model where depending on the subscription tier they are on, your users will have access to different features?
• What happens when a user wants to cancel their subscription, or revert a transaction?

All those questions and many more can have an impact on your app’s design and complexity.

Last but not least, if your revenue model is based on a lot of micro-transactions, you absolutely need to talk with your accountant about it, because most accountants will charge you for their services based on the number of transactions you process and they have to account for. Some accountants and fiduciary firms offer automation and integration services so that your transactions can be reported directly to your books, but they are not always ready for it, and it can incur additional costs.

Do you have a lawyer?

Probably not. But you might need one. The moment you start gathering identifying information about your users, say hello to privacy policies, cookie policies and other terms of service, not to mention the new kid on the block: General Data Protection Regulations, aka GDPR.

It’s another thing that is often overlooked, but it’s not enough to know about it and add a GDPR logo to your website to be compliant. There are roles to define, rules to understand, tools and processes to set up to keep track of which data you store and why, and which third party providers have access to your users’ data.

And just like your app itself, those things will likely evolve throughout the life of your business, need some updates and so on.

In addition to that, for everything you contract other companies or providers to do for you, you will need to have or review contracts, which are especially critical when we are talking about software consulting contracts.

For all of these, having a lawyer who knows your business and follows you can be precious. And even if you will not need them a lot at the beginning, even if you can use generic services like Iubenda to take care of some of your legal needs, it’s generally a good idea to think about those things right from the start, because they have an impact on where your data can be stored, how it can be backed up, what you can legally do with it and so on.

What will your app look like?

I kept this one for the end because it is the most impacted by all the previous ones, and the most crucial resource that any developer will need to answer the dreaded question: HOW MUCH?

There are 3 main aspects here: User Experience (UX), branding and User Interface (UI) design.

User experience is all about the general flow of screens and actions inside your applications. How will features be organized? What are the key use cases you want to cover, and how will they work? Which ones are absolutely essential in the first version of your app versus which ones can be added later, and in what order of priority. The best way to formalize user experience design is by drafting wireframes, rough drawings of the different screens of your apps and the interactions between them. This can help developers determine how many screens your app will need, and how complex they will be, which is essential for any kind of estimation work. At this stage, no need for any fancy colors or branding, and it is even possible to turn these wireframes into a working prototype that can be played with without any coding involved. Some developers (like myself, of course) can help you extract those wireframes from your ideas.

The second important aspect that can be integrated into your app to make it feel less generic is branding. Do you already have your own visual identity, color palette, fonts, icons and logo that can be turned into some sort of graphic charter or theme for your app?

And of course the finest of the finest of design is User Interface (UI) design. That’s when you start adding more custom elements and interactions to your app, that require more work from developers but make it look more specific to your business. I generally advise entrepreneurs to keep that for a later version, because it can add a lot of overhead to development, depending on which tech stack is being used (for example, UI design is much easier to customize in Flutter than in almost any other tech stack, except maybe for responsive web apps). Plus, it’s best to wait until the user experience of your app has stabilized a little bit before you start adding bells and whistles. So unless visual design is part of your core offering, or creates a huge competitive advantage for you, it’s best to focus on UX and branding first.

Also, keep in mind that Android and iOS each have their own UX and UI idiosyncrasies and customs, and it can sometimes be better to stick to the design conventions of each platform rather than having the same exact experience across platform. Always remember that as a business owner, you are managing one app on several platforms, but your users will use many apps on one platform, and the more it fits into the ecosystem they are used to, the more comfortable it will be for them.

This design work, whether it is UX, branding or UI, generally requires yet another skill set, some agencies offering this service too, others specializing in design only. Personally, I can generally help entrepreneurs with UX design, turning vague ideas into wireframes, and then those wireframes into a usable prototype. But for everything branding and UI, I generally work with other designers.

But whatever the case, a set a wireframes is absolutely required to get any sort of estimation about how much an app development will cost, and how long it will take. Don’t trust any company, developer or agency who gives you a budget or a time frame number without any wireframe or detailed idea of what an app will look like. It’s a TRAAAAAP!

Epilogue: are you a product manager?

Knowing what you need to put in your first version, and being able to express it is only the first step. Through the process of formalizing your ideas into wireframes though, you will no doubt come to realize that designing a product is harder than you imagined. Every usage scenario will come with edge cases, potential errors (either from the user or from the app/backend).

What happens if a users tries to sign up with an email address that’s already registered? What happens if the users kills the app in the middle of a long workflow? What happens when the user taps a push notification?

And since, as we said it before, developing such an app is not a one-shot thing, you will have questions like that all the time. If your developers are really good and have a product sense, they will take initiatives to fill in those gaps, but these developer-minded solutions might not be what you need. And if you always wait for developers to come back to you with these questions as they are raised during development because you hadn’t anticipated them in the first place, it can slow down development considerably, and kill your own productivity with all the interruptions.

That’s exactly where Product Managers, or Product Owners come into play. It takes a special kind of experience and mindset to think about all of this, to anticipate all these edge cases, to think of design solutions that remain consistent across your entire product.

And as time goes, you will need to maintain several versions of your app in parallel, the one that’s currently in the stores, the one that is currently being tested, and the one that developers are working on. And each version of the app will need to be coordinated with the proper version of the backend. All of this can quickly become a mess.

Not to mention the issues with coordinating more and more actors as your company grows: designers, developers, testers, third-party providers, lawyers, all those people will have to work in unison and in a coordinated fashion if you want your product to move forward. And again, you might think that you can do it all today, but wait until all of this falls on your lap while you are fundraising, recruiting, dealing with the administration, answering interviews and so on.

Last but not least, as your app becomes more and more sophisticated, you will face situations where there are several ways of doing things, and where the “right” way won’t be obvious from the get go, especially if you have to think about the habits of your users, the conventions of the platform they are using, the way things are done throughout the rest of your app, what is technically reasonable to implement, what is legally advisable, etc. To find the right approach, you will need to run experiments, to do some A/B testing, to talk to several of the people involved in this feature, etc. And again, that’s where a good Product Manager can literally save your product.

So in a first approach, maybe you will be able to do it yourself, or share this responsibility with your developer or your agency if they have this product sense. But given the time it takes (I have seen some founders having to dedicate 80% of their time to this), I can only recommend that you start planning this as a recruitment as soon as possible, because managing a product, especially an app product, is a job in and of itself, and a hard one.

Conclusion

Remember that developing an app is not like building a house or a car. It is a highly unpredictable process, that involves a lot of craftsmanship, expertise, trial-and-error, exploration and uncertainty. So always remember that it’s more an investment than a cost: an intuitive, well designed and well developed app can be a very important element of your business model, but a cheaply executed one can also break your business. The saying goes that the most accurate estimation for a software project can only be produced once software has been delivered. This is what we call the cone of uncertainty. So however stressful it can seem to have only vague numbers at first, try and embrace it and have a software development process that is agile and flexible, that allows for changes and evolve based on what you learn on the ground, and try to find partners who will take initiative, anticipate your concerns, be reliable in terms of quality and efficiency and will strike a balance between engineering and pragmatism.

If you want the short version of this brief, here is a link to a document you can work with.

And of course, if you need an app developed, or a guide to help you find answers to all those questions, you know where to reach me.