I Need an App

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.


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.

Payment Processing Landscape in Europe

It is a well-known yet long-standing fact that setting up payment processing is much harder in Europe than it is in the United States for example. A major reason for that complexity comes from the fact that, contrary to the US where they have big national banks that cover the entire American market, European payment processors have to deal with 27 different legal and tax environments, and very often 27 different sets of partnering banks. That’s probably why it took so long for Braintree Payments and Stripe to cross the Atlantic ocean, and even as they do, they do it in a very limited way.

I’m currently working on a new experiment for which I want to process payments in a native iOS app without disturbing the user experience I have spent hours perfecting. So I reviewed the most well-known contenders, limiting myself to the most modern and country-agnostic actors, and I’ve completed the following benchmark which might be useful to some of you.

Note that I have a few special requirements that are decisive for me but might not be applicable to you:

  • I’m using Parse for my backend, which doesn’t allow me to run any server-side code easily. I can run simple Javascript code that can call REST API’s (or special integration code when they have a partnership like with Stripe).
  • My service has a peer-to-peer marketplace business model, which means that I take a commission on direct transactions between end-users, which payment processors call Third Party Payments Aggregation. For acquiring banks, this kind of business models is often considered a risky one because it poses all sorts of questions in case of refunds. So not all acquiring banks accept TPPA.
  • A lot of payment processors say they offer mobile processing services when in fact they mean mobile WEB payment, which means stripped-down restyled version of their web forms that you have to integrate with web views and greatly disturb the user experience. That may be enough for most applications, but I didn’t want to sacrifice user experience (and thus conversion) in my case.
  • As I said, my app is just an experiment for now. I don’t know how much volume it’s gonna deal with, and I don’t want to wait months to have my payment processing ready just because I’m a “small fish”.
  • Since it’s a mobile app, I would really like to be able to store credit card data for later so that my end users don’t have to enter 23 digits for every transaction (secured vault).

Also, be careful. This is the situation as of mid-April 2013 and it’s very likely to evolve a lot over the coming months and years.


  • I’ve rejected Paypal and Adyen because of their lack of native iOS integration
  • Stripe is not available in Belgium yet and will probably not be anytime soon
  • Braintree Payments is available in Belgium but their mobile wallet (Venmo Touch) is not available in Europe yet, and the dealbreaker for me was that they couldn’t find any acquiring partner in Europe to support TPPA.
  • Ogone is very cumbersome to set up, their documentation is awful, their backoffice interface is simply unreadable, but more importantly they don’t support native iOS integration.

A few days ago, Paymill released the first beta of their iOS and Android SDK. The activation process went pretty smoothly and their documentation is rather clear compared to some of the others. They are using Acceptance as an acquirer in Germany. I have started to integrate the SDK into my app and so far it works great. The API is pretty straightforward, even if they still need to work on naming conventions in my opinion. But it’s definitely the most promising actor on the market today.

If you have any complement to add to this information, feel free to leave a comment.

EDIT: Thanks to marcos for pointing me to 2 mistakes in my benchmark. Paypal actually does have a REST API but it’s only available in the US for now (in beta). They also have a native iOS SDK that I hadn’t found. Given that the REST API is not available in Belgium, I wouldn’t be able to verify payments, and I still don’t trust Paypal to keep my funds available so I’m still sticking with Paymill for now. But I have updated the benchmark accordingly.

EDIT2: There’s a new kid in town. Leetchi just publicly announced their new e-money service for collaborative consumption and marketplaces: MangoPay. I’ve added them the the benchmark. Their REST API is still a little too low level for me and they don’t seem to be planning an iOS or Android SDK right now so it won’t make me switch from Paymill yet. Plus their e-money concept needs some explaining. But it looks like an interesting European alternative to Stripe Connect.

UPDATE: Paymill just released their marketplace offering to compete with Stripe’s Connect: https://www.paymill.com/en-gb/product/unite/

UPDATE: Braintree Payments just released their marketplace offering, but it’s only available for US businesses for now: https://www.braintreepayments.com/marketplace

Software Architecture Cheatsheet (Part 3/3)

In the previous post, I tried to think of the business constraints that intervene in the choices of a software architect. In this one, I’ll take a feww shots at guessing which technologies are important nowadays to build software solutions for these constraints.

I see… I see…

There are so many technologies out there that I will not risk myself in designing some sort of female magazine test like “tell me about your application, I’ll tell you what technologies you should use”. That’s a very exciting part of what I perceive as what is the job of a software architect: finding the right combination of tools and techniques for a specific business context in order to develophigh-quality, high-value and robust software for customers.

That said, there are a few important areas that seem very important to explore or even master in this world, and more specifically in this new economy we’re facing.

Productive dynamic Java

Java is a very mature and popular technology, so much so that many people have predicted its death times and times again. But in my view, it’s very much alive, especially with recent developments that made Java development much more productive. Of course, SpringSource-originated frameworks like Spring and its galaxy have changed the enterprise Java environment for a long time.

But even more recently, inspiration has come from the “casual programmer” side with Ruby on Rails and Python/Django yielding even more interesting developments like Groovy and Grails that combine the flexibility of a dynamic language with the incredible power and richness of the Java platform.

In my opinion, Groovy/Grails are about to rejuvenate enterprise development in an incredible way.

Modular Java

There has been a lot of marketing fuzz a few months ago about something called Service-Oriented Architecture. Unfortunately, although it was based on common sense, marketers and tool vendors completely killed the concept in the egg, but still, some important aspects have emerged and remain limitations of the most popular technology platforms. One of them is the importance of modularity: the ability to change one part of a system without touching anything else, whether it is to adapt them or to restart them.

OSGi (Open Service Gateway initiative) is a standard that has made a remarkable progression on the server side in the past few months, and with its massive adoption by major vendors, it’s definitely going to be something to watch.

Server-agnostic Rich Internet Applications

RIA-enabling technologies compose a very competive landscape: Adobe Flex, Microsoft Silverlight, Sun JavaFX, and even more niche technologies like OpenLaszlo, Curl. And I’m not even considering all those Javascript frameworks and AJAX-generating techniques that I personally don’t see as viable alternatives in an enterprise environment.

My technology of choice is definitely Adobe Flex: it’s open (and it’s even become one of the most impressive examples of Open Source development lately), it’s robust, it’s server-agnostic (it works with Java, .Net, PHP, Python, what have you), it offers desktop integration capabilities, making it possible to cover many of the use cases mentioned above, and it’s very elegant by design. More importantly it was one of the first RIA technologies out there, which makes it both very mature AND very popular.

Native Mobile Development

Mobile development has always been a hobby. Taking useful applications with you is an old fantasy. For a long time, it’s been so poor that it was difficult to turn this hobby of mine into a professional activity. That was until I came in touch with iPhone SDK development, which really blew me away. For the first time we have some great mobile hardware with unique usability capabilities, and we have the software development platform to use those capabilities like never before. And it’s going to be even better with the release of iPhone OS 3.0.

Of course, it’s about to become a very competitive area too, with the release of Palm WebOS, Google Android and Nokia Qt. But for now, the iPhone SDK is by far the most advanced native mobile development option.

What’s my point?

The purpose of this series is double:

1. try to show why software in general, and software architecture in particular are such exciting fields
2. wake up people who tend to have only one single hammer in their toolbox

Now if in addition to that, it can create a debate, then I have a few questions for you guys (and hopefully gals :oP) So, what technologies do you think are important to know in the current and future software world?

Software Architecture Cheatsheet (Part 2/3)

In the previous post in this series, I tried to enumerate the most frequent kinds of applications. The question I’m going to ask myself here is what are the constraints that intervene in choosing the right paradigm and the correponding technologies to implement it.

Environment! Environment! Environment!

Before we start answering that question, let’s just be clear with something. We live in a world where there are plenty of free and Open Source libraries and frameworks and tools of all kinds. It doesn’t mean that free is always good, but at least it’s an option, and if you have a commercial option that can add some value somewhere, then go for it, it’ll be worth it. So I won’t consider tooling cost as a parameter here.

Performance (high computational power and low bandwidth)

Whenever you hear your customer say “I need it to handle several million transactions per second”or “I quickly want to make decisions based on thousands and thousands of records”, you know that you will have to think about performance. There can be several kinds of performance: memory consumption, CPU cycles, disk space, network bandwidth, hardware cost, etc. And all those metrics very often play together, which means that any change to one of these metrics has an impact on all of the others. For instance, it’s very common that you have to increase memory consumption to optimize CPU or disk access (caching).

Another important characteristics of performance is that optimization requires you to dig deeper into low-level details, because most of the performance is lost when abstracting machine constructs to be closer to human users. That’s why optimizing performance requires more work than doing things naively, and it’s very important to weigh the benefits of this work compared to the cost.

Moreover, it’s sometimes tempting to think of performance very early on and to focus on that more than the business value the application is supposed to create. But experience proves that you can quickly end up with very fast systems that don’t do what they are supposed to do because the closer you are to the machine, the harder it is to develop on it or maintain it. That’s why Donald Knuth said:

We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.

Distributivity (number and spreading of end-users)

Nowadays, it seems like all applications are meant to be web applications, all the more so with the recent fashion for cloud-based applications that attempt to “webify” traditionally desktop-based apps like word processors, worksheets, and so on.  And there has been so much effort spent in web apps in the past 10 years or so, that everyone knows about the technologies to build them. Yet it’s always important to ask yourself a few questions: will the application be accessible to the general public? Will it be extranet or intranet? How many users are likely to access the application at the same time? Are potential end users ALWAYS online? What would be the impact of the browser crashing in the middle of a session?

Sometimes, having to think about data access concurrency, network bandwidth or security is a useless hurdle that you can avoid just by developing a desktop application.

Automation (launch it regularly and in the background)

What if your application doesn’t need a complex user interface but requires just a few parameters to do its job? What if, on the other hand, it needs to be easily automated and integrated into a batch processing system? When you face such a business context, it’s important to consider the option of a CLI app, because then it can also be easier to integrate with other kernel system apps through scripting.

Whenever you hear your customer say words like “data analysis”, “system check” or “automatic synchronization”, you’d better think twice about your web app idea.

Ergonomics (easy and quick data input and visualization)

At the other hand of the data analysis pipeline, there is data input. And the more data there is to input, the higher the risk of rejection of the application by end users. And since end users generally wait a long time to get theirs hands on the application, this rejection traditionally happens very late in the development process. Combine that with the fact that people who ask for the application are not the ones using it, and the very special mindset of developers and you have all the chance in the world to miss your target and have the project fail before it reaches the finish line.

Of course, technology is not the primary solution to this problem. The first thing is to consider end users, consult them, talk with them, even if the business owner doesn’t think it’s useful. Then of course, methodology goes a long in putting the application into end users hands as soon and often as possible. But as soon as you realize the specificity of what users are expecting, you understand that you need a technology that gives you all the freedom to implement very complex use cases, without forgetting about the conventions and paradigms that people are used to.

Integration (with operating system and external systems)

Web apps have another big drawback in addition to ergonomic limitations, which is desktop integration. This issue comes from the security model of the web. Because it’s so easy to access a web application, because you don’t have anything to install and because the application is directly connected, it also creates a huge opportunity for malicious use. Which is why web apps usually work in what is called a sandbox: network access is limited to the originating domain (unless specified otherwise), no direct access to the file system is allowed, no native API access to things like system tray icons, drag and drop and so on.

And if your application has tom import or export very big files, or notify the user on a regular basis, those limitations can be a killer. There are some technologies now that create some sort of a bridge between a runtime plugin in your browser and a runtime app on your machine, but portability of this bridge across systems and across browsers is sometimes limited.

Productivity (getting things done and adapting fast)

How stable are the business rules you’re asking me to implement? How sure do you know what you expect from this application? If your customer answers “not very” to any of these questions, you might think twice about using this low-level highly-optimized programming language. Because if it takes you weeks to implement any change or new feature, your application might quickly end very far away from the business value is was supposed to create.

Fortunately, with the maturity of web application development, there has been a lot of very interesting developments in the area of development productivity lately. Development tools like integrated development environments certainly go a long way in making developers more productive, but when this concern is dealt with at the programming language level, it’s even better.

Maintenance cost (number and quality of resources)

Whatever technologies you plan to use, you definitely must consider the constraint of resources. There are so many techniques out there that it’s impossible for everyone to know all of them. Some of those technologies are very mature and popular, thus making it easier to find people to maintain and evolve your application on the long term. But the more mature the less innovative they often are. So finding the ideal compromise between the benefits of innovation versus the cost of resources to maintain your application is very important. Thus is might require some insight and technology watch in order to anticipate which of these innovative techniques will grow fast and be there for a long time.

And if you really need one of these innovative technologies that is not very popular yet, then don’t forget to include training costs in your plan. Last but not least, don’t forget to consider company-wide policies: IT architecture departments can create substantial impediments on your way, which might lead you to weigh in the cost of those impediments.

Continuity (robustness and evolutivity)

Beyond people able to maintain it, there is another thing that is very important for the longevity of your application: the intrinsic software quality assets of the technologies that you use. Testability, decoupling, Domain Specific Language support, portability, internationalization support, integration capabilities with other technologies and platforms, extensibility, modularity. All those characteristics can be very important to consider if your application is supposed to stay there for more than 5 years and evolve with the business at hand.

A lot of money is spent and sometimes wasted in reegineering entire applications just to keep up with current technologies or new business constraints, so much so that choosing robust and evolutive techniques can greatly reduce the long term ownership cost of the application.

In the final issue, I’ll risk myself into making some predictions about the technologies that seem very important in order to implement applications with that kind of constraints. But before I do that, do you see other business constraints that might be important to consider before choosing the best tools for the job?

Software Architecture Cheatsheet (Part 1/3)

What I really like about being a software artist is the richness of tools and techniques you have at your disposal. And the more tools you have, the harder it is to use the right ones, the more tempting it is to limit yourself to a few of them. But to me it’s like analogic versus digital DJing: given that your ultimate purpose is to create sounds that make people move, why limit yourself to sync-and-scratch when you can have effects, loops, samples and a virtually unlimited library of tracks?

But I’m sort of missing my point here. Let’s get back to software. I’ve recently come to work on a new project that has been in the works for almost 2 years. For 2 years, wanna-be software developers have tried to solve a very difficult problem with very usual tools. It’s like Maslow said:

When you know how to use a hammer, everything starts to look like a nail.

Well, guess what! Everything is NOT a nail. And I’m gonna try to go over the reasons why in this post.

Software is one big family…

…and each member of the family has its own personality.

The most popular right now is certainly web applications. And by web applications, I mean traditional ones. HTML, CSS, throw is a little bit of Javascript, and maybe generate all of that with some server-side scripting like PHP, Python, JSF or whatever. Heavy load on the server, but very lightweight on the client. The interface is somehow poor because it relies heavily on technologies that were designed for documents gathered in websites, rather than for full-blown applications, with all the interactivity that it implies. Yes, some progress has been made in the past few years with all this AJAX stuff, but bear with me, this all seems like tinkering to me.

The mirror opposite of lightweight clients are certainly fat clients, aka desktop applications. Those applications are based on a composition of graphical widgets the user interacts with, throwing events around and interacting with the operating system. Contrary to their web counterpart, they usually require quite a procedure for deployment and maintenance, because they are physically running on the user’s machine and only check in with the server if they need to. But damn they’re fast.

More recently, a new compromise solution has shown up, offering the best of both worlds: the great ergonomy of desktop clients combined with the ease of deployment and maintenance of web clients. That’s what marketing guys have lovingly called Rich Internet Applications. Now behind this lovely RIA thing, there are a few technologies that make it a lot easier to write rich user interfaces that run within the confines of a web browser. But still, those have limitations compared to their pure desktop brethren: poor integration with the operating system, security constraints all over the place, heavily rely on server-side business code.

Now if Rich Internet Applications are web applications that solve the ergonomy problem, there is of course the other side of the compromise: desktop applications that solve the deployment and maintainability issues. Those are sometimes called smart clients: local database, offline mode, online synchronization, automatic updates, easy one-click installation.

Even though, those seem to fulfill the family picture, there are a few weird cousins out there that are good to be known. Command-Line Interface (CLI) applications have poor to no user interface at all. Their main purpose is to be run on the command-line by some geeky system administrator somewhere, or to be part of batch scripts running automatically every night. Very useful for maintenance apps, and for all long tasks like data analysis or system checks.

And of course there are mobile applications and all kinds of embedded systems. The user interface simply cannot be rich here, because the display is so small, and the computing resources are so limited. Small memory, small keyboard. The iPhone is certainly changing the landscape here, but you still have to manage memory!

Don’t forget extension apps, like SAP modules, CMS plugins, MS Access applications. Those are applications of their own. Usually highly specialized but very fast to develop for simple use cases, to get things done quickly.

Finally, even though, they’re less and less popular, there are still many mainframe applications out there. Now I won’t go into much details here because I’ve never set foot on that ground. But it certainly doesn’t harm to remember that it exists.

Now there certainly are a few other kinds of software applications out there that I didn’t think of, but you get my point. There are a lot of different tools out there, and very different techniques to use those tools in order to create software solutions to very different problems. And what makes those problems so different, you might ask. Well, it’s all about the business context. In the second part of this series, I’ll focus on the characteristics of a business environment can influence the tools you choose to implement the solution to a problem.

But before we get there, do you see other kinds of applications that I forgot to mention?

MobiMap 1.0-RC2

I just released version 1.0-RC2 of MobiMap library. Amongst the features I’ve added are:

  • better icons for screen controls
  • better support for touch screen devices with a new zoom slider
  • all strings are now internationalized in French and English
  • a help screen with all the active shortcuts when you hit 5 numeric key
  • it is now possible to customize all shortcuts programmatically

More information on the official site.

And if you want to test a demo application using MobiMap component, just point your mobile browser to http://mobimap.epseelon.org/mobimap.jad

We’d love to hear your feedback.

MobiMap First Release Candidate is Out

We needed a reusable mapping component for TagSpot development, and we wanted it to be Open Source so that everyone can reuse it and improve it for the general interest. There was no such library available on the environment we’re working on so… we made it!

And here comes MobiMap. MobiMap is a library that offers a reusable and customizable mapping component for several mobile platforms. Today, we’re releasing the first release candidate for version 1.0 of the JavaME version. We’re still working on porting this library to Windows Mobile and iPhone environments, and we’ll release the final version of all three libraries at the same time. Until then, we need feedback from mobile developers and we need help to improve the library.

The project website is on http://mobimap.epseelon.org
Out support forum is on http://groups.google.com/group/mobimap
Our issue tracker is here: http://bugs.epseelon.org
MobiMap’s Subversion repository is here: http://svn.epseelon.org/mobimap-javame

Special Thanks go to…

First I would like to thank developers of Pyx4Me and Microemulator, thanks to which we could develop this library on the Mac.

I would like to thank Romain Guy, Richard Bair and the whole SwingLabs Team: MobiMap component is heavily inspired from JXMapViewer Swing component.

Special thanks also go to Antoine Jacquet, aka Royale, whose blog article about tile providers really helped me a lot in understanding all the tile APIs.

And last but not least, thanks to the whole TagSpot team for their help and support.

Finally, if you want to see what MobiMap can do on your phone, you can type the following URL on your phone: http://mobimap.epseelon.org/mobimap.jad. Or if you’re just too lazy to type this URL and you know how to use a QRCode, you can use the one on the right.

Be careful though, as MobiMap will download quite a bit of map data over your mobile connection so…