One of the common concerns or fears for people wanting to get into app entrepreneurship is that they have no idea about coding or how it works and therefore it is not for them. You don’t have to know coding to be a successful app entrepreneur. There are many successful app entrepreneurs who aren’t coders. Let’s take a look at some of them.
- At age 25, Evan Spiegel, the co-founder of Snapchat, was reported by Forbes as the world’s youngest billionaire. He did not seem to have any advanced programming skills.
- Jack Ma founded China’s largest B2b e-commerce website, Alibaba, and is a billionaire now, but when he borrowed $2000 to set it up, he knew nothing about computers or even emails.
- Melody McCloskey, the founder of Styleseat, a successful marketplace app, know no coding when she built the first version of the app by outsourcing it to freelance developers.
- Alex Turnbull, the founder of Groove, a helpdesk software, was not a coder and did not have a technical co-founder, yet he took his company to multimillion dollar revenue by outsourcing the app development to an agency.
- The man, Steve Jobs, himself, was never a programmer and did not do any coding since the early days when they coded the Apple 1 OS. In fact, Steve Wozniak, the cofounder of Apple, once said Steve Jobs knew no technology, let alone programming.
Though these guys did not know programming, they had some understanding of technology or product development. It is important you have some level of technical knowledge and understanding of the development process in order to choose the right team, make the right decisions, manage the tech team, and produce the desired outcome.
In this blog, you will learn the jargon and technical essentials to make informed decisions when choosing your development partner and technologies.
1. The app-development process
Building an app is similar to building a house in lot of ways (but it is also very different to building a house in lot of ways). You have to create the plan and lay the foundation, step by step, stage by stage. Let’s take a look at various stages involved in building an app.
Requirement gathering and analysis
This is the initial phase, when you and the whole team are involved in the development brainstorm and analyze the requirements of the app. The goal of this phase is to ensure everyone not only understands the requirements, but to produce a document that captures all the requirements in detail. Companies may use various terms, like SRS (system requirement document), BRD (business requirement document), or PRD (product requirement document). Most app development companies have a “business analyst” or a “product manager” who owns the process of gathering, analyzing and documenting requirements. In your documentation, make sure the following details are captured.
- High-level goals of your app. Why you are building the app – what is the objective? This is developed based on your answers in Section 1.
- Functional requirements. These describe the details of the features and functions available in your app. This is the most important and detailed part of your documentation. The term “User stories” or “Use cases” are popular in the app industry as a way to document requirements. User stories are short, simple descriptions of a feature told from the perspective of the person who desires the feature, usually a user or customer of the system. They typically follow a simple template: As a , I want so that . For instance, “As a videographer, I want to be able to upload my video into the app, so I can back it up and never lose it.”
- Technical and non-functional requirements, which are not functions, but describe how the app should work. For example, “The app needs to work without internet.” “All pages need to load in less than five seconds.”
You can download our BRD template at Appomate.com.au/resources
UI/UX design
In this phase, the wireframes of your app are designed by UX designers. Wireframes are skeleton drawings showing the different buttons, functions, and info in the different pages of the app. This is an important part in developing your app. With millions of apps in the App Store, what’s crucial is no longer what the app can do – it’s how the app does it. Is it easy, engaging, and intuitive to use? A professional UX designer takes your documentation and turns it into screens and mockups of the app. Uxpin, Balsamiq, and Invision are some UX wire framing tools available in the market.
Typically, a branding expert designs the logo, color, and fonts for your app brand based on your target user and their goals. User persona is great tool to workshop and understand your target user. These branding elements are put in a single document called a style guide. Your brand’s style guide is then applied to your wireframes to get the desired User Interface of your app. At this stage, you can pretty much see and feel the end product you are building, even though no coding has been done yet.
Development
This is the stage where the programmers look at the documentation (BRD) and the UI designs to code the app features and functions and bring the idea to life. It involves the development of different components of an app, like the front end, back end, API (Application Programming Interface), etc. It often involves multiple developers, as the app may involve multiple technologies.
Testing
Many business have testers, or a QA (quality assurance) team, who test the app end to end to ensure it works as per the expectations in the documentation and design. With the rising variety of devices and operating systems, you need to ensure your team is testing your app for a range of devices and operating systems. The more your app is tested, the more reliable it is. It is a good idea to invite your friends and family to test the app as well and give you feedback.
Launch
This is the final step after the developers have fixed all the testing feedback. It is not uncommon for apps to go live with some small bugs. This stage involves uploading the apps to the App Store and Google Play Store to make it available for download and use.
Now that you understand the main steps involved in the development of an app, let’s look at the two key development methodologies or approaches in app development.
2. App development methodologies
Waterfall approach
In this approach, the steps of analysis, design, develop, test, and go live are done in sequence, one after the other. You complete each step for the entire scope of your app before proceeding to the next step. This approach is ideal when the app is relatively small and the requirements are clear and not expected to change quickly. It keeps the process in control in terms of time and budget, but does not offer much flexibility to changes in market conditions. If the entire development is expected to take less than six months, and the requirements are not subject to change, the waterfall approach may be suitable.
But if the app is big and is expected to take longer than 6 months, a lot of things can change during that development time, like technology, design trends, competition, market demand, etc. The requirements you capture in the document at the beginning may be less relevant by the time you test the app at the end of the project.
The waterfall approach might suit bigger projects in some case, for example, when you are migrating or upgrading an existing system within an organization. The requirement might be just to replicate the features of the existing system, and the changes in the market may not have an impact, as the app is not in the open market. Using the waterfall development approach allows developers to provide a fixed quote and timeline based on a fixed set of requirements.
Agile approach
In this approach, an iterative approach is followed for building the app. Instead of going step by step for the entire app, you do it for small parts of the app, building the app in an iterative approach. Each iteration goes through the analysis, design, develop, and test phases to produce a small piece of working software at the end of each iteration. The software grows as you move forward from one iteration to the next. This approach encourages flexibility and allows quick response to change. It is very suitable for projects where there are lot of assumptions on what is required, and when the market conditions change regularly. The challenge with the agile approach is that you cannot have a fixed deadline and a fixed budget because the requirements are subject to change.
With your understanding of these two approaches, you (with your developer) can make an informed decision on the right approach for your app. An agile approach is what experts (including me) recommend, because the world changes so fast. If you are bringing a completely new idea to the market, the agile approach is definitely better than waterfall, because you don’t really know what the users want. But if you are creating a product to replace what already exists, and there is nothing to validate and test, waterfall can be a more efficient approach.
| Waterfall | Agile |
|---|---|
| Fixed requirements during the project | Requirements can vary during the project |
| Favors fixed cost, fixed time. Upfront expectations can be set | Challenging to have fixed cost, fixed time as requirements are expected to change and evolve |
| Challenging to adopt to changes during development | Easy to adopt to changes during development. Changes are embraced |
| Suits when the requirements are already validated by users. Example: you are simply building a clone or migrating existing app to a new technology | Suits when you are building something new in the market and user validation is required |
| Wait till end for a working software | Working software versions released during development |
| Suits when you need to keep the budget low for an initial launch | Suits a lean start-up approach where you constantly update the product based on feedback |
3. Types of apps
The other important technical aspect you need to understand to build a successful app business are the different types of apps. Often app entrepreneurs are bombarded with options of mobile responsive websites, mobi sites, native apps (iOS, Android), cross-platform apps, and hybrid apps. Different developers recommend different options, based on their experience and expertise. It is critical you understand what each means, and the pros and cons of each type, so you can make the right decision for your app.
Two types of web-based apps
Mobile responsive websites
A responsive website automatically responds and fits itself to the user’s screen size. The design makes use of fluid, proportion-based grids and flexible images, so all the elements in a page automatically resize and position according to the size of the device screen. This method is suitable for information-only websites, like e-newspapers and blogs, where there is no heavy interaction with the user. In fact, all websites built these days should be mobile-responsive, because a huge percentage of your visitors will be accessing the website via mobile devices, i.e. phones and tablets.
Mobi sites
In this approach, you build a separate version of your website specially designed for mobile devices, usually hosted in an m.yourdomainname.com site. Facebook follows this approach. You can go to facebook.com and m.facebook.com to compare the two websites. When you access facebook.com from your mobile device’s browser, it automatically takes you to m.facebook.com
| Responsive website | Mobi site | |
|---|---|---|
| Initial build cost | Higher | Lower |
| Access to information for users | All info on website is accessible on mobile deices | Only limited data is available on mobile devices |
| Ongoing maintenance requirements | Lower – Only one code base and one content backend to manage | Higher – two separate code base and two separate content management backend |
| Search friendliness | Recommended by Google guidelines | Not recommended by Google guidelines |
| User experience | Typical top-to-bottom navigation. Not optimized for mobile devices. | It can be optimized well for mobile device to provide a user experience similar to apps |
Responsive websites and mobi sites are websites, often referred to as “web apps,” which only work with an internet connection, using browsers like Chrome, Internet Explorer, and Safari on your mobile devices. Since they run in mobile browsers, they can’t make full use of the mobile device’s capabilities, such as accelerometer, contacts, camera, etc. The term “Apps” is used to refer to mobile apps that are downloaded to the user’s phone which can make use of all the capabilities of the mobile devices.
Two types of mobile apps
“Apps” generally used to refer to mobile apps, which are downloaded from Apple app stores, Google play stores to various mobile devices (phones, tablets, etc.) run on the mobile devices’ operating system. There are two types of mobile apps, native and Hybrid.
Native apps
Each mobile platform, like iOS, Android, and Windows, offers their own (native) software development kit (SDK), which has the tools and interfaces to build, run, and install their apps. For example, with Apple iOS, native apps are built using iOS system frameworks and objective-C language. Recently, Apple introduced Swift to build native iOS apps faster. Similarly, native Android apps are built using Java SDK. Native apps are installed physically on a device, and are therefore always available to the user, even when the device is in Airplane mode. Some data, however, may need online connectivity. Native apps provide the best user experience, since the user experience is customized for each platform. Since most features can be built without depending on internet connectivity, native apps are faster than web or hybrid apps. For example, the Angry Bird app, and many little game apps like it, are native apps. They can be used without any internet, whereas an app like Facebook needs internet connectivity to work.
Hybrid apps
Hybrid apps sit between web apps and native mobile apps. They mainly make use of web technologies to build the app, just as web apps do, but then they’re wrapped inside a native app using web view. (Web view is basically a browser bundled inside a mobile application.)
Hybrid apps can make use of native UI elements. This allows hybrid apps to have significant cost savings, as the majority of the development is in web technologies and can be reused for all platforms, but at the same time they are downloadable on the app stores like the native apps.
The disadvantage with Hybrid apps is that they cannot provide a rich and dynamic user experience equivalent to native apps. Hybrid app are slower than native apps, and most of the app features need internet connectivity to work. Game apps, for example, are best built as native apps, whereas simple business apps can be built as hybrid apps. Instagram is a hybrid app for example. Though it uses a lot of native components and native UI elements, it uses a web view for the timeline feature.
Cross platform development
The other way to build apps cost effectively is by using cross platform development technology. Cross platform development uses tools and technology that allows developers to build apps for multiple platforms at the same time, instead of building one platform, like iOS or Android, at one time. You build the app once using the cross platform tool, and then simply publish the app in multiple platforms like iOS, Android, or Windows.
Sometimes people confuse cross platform development with hybrid apps. You can use cross platform technologies to build either native apps or hybrid apps.
For example, NativeScript and Xamarin are cross platform development technologies that allow you to build native apps for cross platforms.
Phonegap.com and Ionic Framework, for example, are cross platform technologies that allow you to build hybrid apps for multiple platforms.
Cross platform technology can often be a cheaper way to build apps, but it has technical limitations, especially in the area of UI. Example, they are not great for game apps or apps with sophisticated interactive reporting.
Even if you are not a coder, having the basic technical knowledge discussed in this blog and building on it will enable you to have meaningful discussions with your technical team.
Add comment