If you are an entrepreneur, chances are you already know that startup world is tricky! More so with the app startups. Knowing when to take the next step can be nerve-wracking and doing the due diligence is a very important first step that a lot of entrepreneurs miss out. How do you know if your great idea will disrupt the market, or… blow up in your face?

Well, it can go either way, but there is some groundwork that you can do at a minimal cost (or even free) to validate the ideas before investing your hard-earned real dollars into it. The first thing that you might wanna look for is, yep, competition!

The research stage is usually a three-step process, but as you can imagine, those three steps are not completely straight forward.

• First, we need to know how to define our product and audience. In ther words, what keywords can be associated to this product.
• Second, we will need to discern how our audience is likely to search, and when. In simpler terms, if you were looking for a product that you are trying to build, how would you search the good old world wide web.
• Finally, we use that information to search for direct and related information over and over until we are satisfied with our scouting. So, you see, these are just not three steps, you are cycling through these steps multiple times to make sure you have left no stone unturned.

Let’s use an example.

Your new app is going to help shoppers determine where they can get the most deals for a specific diet. This will give us, the Diet Name (We’ll go with Taco Diet, because I wish it was real), Deals, Cheap, Cheapest, Best, Weight Loss, Lose Weight, Lose Fat, Skinny, Lose Size, Beach Body, Healthy Nearby, Near Me, New Diet, Diet, 2019 (or relevant year), Android/Apple etc.

Allow me to introduce something that everyone should have in their toolbox: Google Trends

If you have never used it, this is a researching miracle, allowing you to search every bit of data you could need on any term you can think of. Not only that, it gives you related terms, related topics, and generally gives you the insight you may never have even considered. The idea is to come up with as many possible relevant terms as you can: if your customers can find them, you have a competitor. Remember to keep in mind common misspellings. If a simple typo can get you an edge, it’s worth knowing about. If you plan to do Split Testing down the line (Also known as A/B Testing), make sure to follow up on those ideas as well.

If you are trying to pursue an idea that involves a smart device or hardware (Internet of Things), there is another step you would want to try before wrapping up this first part. Let’s say we’ve gone through, and found absolutely nothing. How do we know for sure? If you already searched every term you can think of, there’s always the option of searching through public record databases. While this won’t be fast, you may be able to find companies and patents registered under specific names or track down companies with no online presence. Offline businesses are rare these days, and unlikely to be able to complete outside of their local area, if that. It’s very likely that you may not have any effective competition at launch in this case.

The great thing about all of this is that it’s free, or at least mostly free. Researching your competition with a reasonable degree of accuracy is far easier than it’s ever been, and the internet is just chock full of fantastic resources to help out in this regard. Below are a few that may help out for your specific situation.

Landing pages are simple, and they are going to serve as the funnel for all of the information above.  There are many tools out there to make one with no hassle these days. While you can use functionally free options hosting and design options like Wix and WordPress, they are also going to be entirely manual when it comes to funneling your traffic, and also will be absolutely buried in the search results without a custom domain to transfer to. We will ideally use an automated system, such as Airstrip.

Now, this tool is amazing. First off, if you have never made a landing page before, it has the entire template ready to go right as you sign up. All that you need to do is go on and put your product information in there. You assign your pictures, put your logos, and describe your product in a few short blurbs.

From there, all we need to decide is whether this will be a sales page, an information page, or a funnel page. As before, everything is already there; sales pages can put their pricing and links, information seekers can put a questionnaire, and a funnel page can direct your customers to download your new app.

You can even run a split test using this, creating two different variations of a similar landing page, and tracking the results of both for data. This can be crucial in determining which path to take with your product. It should be noted that while using their default domain can still technically be viable, due to comparatively fewer people using this over something like Wix, but a custom domain will usually be needed to get those first page results we’re hoping to nab. Remember that once you are on the first page, you generally will get more and more cemented there as your relevance to your search terms grows through Google’s system.

Asking questions can be hard. Asking good ones may be difficult. Asking wrong questions can leave us sunk. Then what do we put in our questionnaire?

Thank goodness for the internet once again. While questions will vary from project to project, there is a site that can actually set up with already made questionnaires for just about anything out there, and like all of the above, it’s free to use to some extent. Start with industry standards like Surveymonkey or its cool buddy Typeform. You will more than likely find what you need on here. If not, they also have templates and all of the information you could ever need on making a successful questionnaire.

So now we have our Landing Page mostly pieced together, we have out Questionnaire ready to hunt down that sweet, sweet data, and maybe we put a slightly different version out there just to test the waters with some different crowds. Now we need to make sure our pages are using the tags we found to be popular earlier, and we’re ready to launch all of this!

See? It wasn’t that hard, and once you have it all down, you can be out and researching that new project in as little as an afternoon… though maybe spend a bit more time just to be sure

Good Luck, and good searching!

Book a free consultation with our team if you are looking for a technology partner to take your startup to the next level.

People often tell me, ideas are dime a dozen, and it’s the execution that really matters. That’s a fair point, however, it doesn’t change the fact that we still have a very personal stake in keeping our ideas secure. They might be our livelihood, our reputation, or our way to advance to where we want to be. It also doesn’t change the fact that getting a project out before anyone else will always give it the best shot of success.

So, how do you separate what you want to do, and what you should do to protect your app idea? How do you know what the cautious approach even means in this situation?

Let’s take a step back for a moment and assess the idea to begin with. What kind of feedback have you received for your idea? I know it is a chicken and egg story! How the heck do I get feedback without sharing my idea, and how do I protect it, if I am sharing it with anyone and everyone?

It is important to ask the right questions to refine the concept and get to the next step in the process. First of all, you need to think, what level of protection your brain child will need. You may want to let go of the need for secrecy a little if you want to get good feedback for your project to get better. For example, if you are discussing it with a closed group of subject matter experts or a potential development partner, you should trust their expertise and reveal just enough information, so that they can give you meaningful suggestions.

Okay, let me put it this way, ideas are like a Toddler’s Crayons. The first toddler that realized that crayons can be used to write on walls must be ecstatic, and may well want to hoard all of the crayons. The other kids in the area are busy playing with cars and stuffed animals. They would either have to go through the same process of figuring out the idea (Seeing the crayon, figuring out that it writes, and then discovering that the wall is a blank canvas of endless possibility), or see it in action to think of using them to draw, rather than attempt to eat them. That first kid will have gotten his work out there long before anyone else, and will usually be the first one associated with colorful scribbles on the wall.

A piece of advice that sometimes gets floated out is to make all involved sign an NDA. After all, it’s what all the big guys out there do, right?

All good things get copied, so naturally no idea is going to stay unique forever. Imitation is the sincerest form of flattery, after all! It just means you did good. So, keep expanding on that good idea! You will always have the early entrant advantage. Just make sure you are listening to your users and constantly improving your app.

• Patents are for those situations when someone establishes a functional business, and needs to make sure no one steps in to directly copy their methods or ideas.
• If a startup has invested a large amount of resources into a project, and has direct competition threatening them, but are still able to file a Provisional Patent first, it would be worthwhile.
• If an established business is going steady, knows that they have others that can step and take part of their market, and have the spare capital to file, it’s a good call.
• If a business is new, and hasn’t invested thousands in research/development/time, or has no immediate and ruining competition, it’s more than likely going to be safe without a patent until it’s at least functional. Some might be ambiguous enough to never need one.
• Just remember that patents can stop someone from risking a lawsuit by copying you, but it can’t physically stop them from making a clone just different enough to avoid it.

Patents can mean a lot of things to a lot of people. To some, they’re a safeguard for their work, to others they can be everything from an obstacle to a needless expense or a trap, depending on how they’re used.

Legalzoom has a handy guide on the different patent types here, but in very brief summary, there are 4 types of patent.

• Utility Patent – A Patent showing use and design of a system or device.
• Provisional Patent – A temporary patent used when you want a Utility Patent, haven’t quite ironed out the details, but also are worried about having the carpet pulled out from under you.
• Design Patent – Covers cosmetic and aesthetic improvements, in our case something like unique UI elements.
• Plant Patent – Not even remotely relevant unless you’re managed to make a dandelion with a touch screen, though I’m sure there’s a market for that, if anyone’s interested.

Patents are an expensive process, and more often than not are simply too complicated and cumbersome. Without counting time investment, we’re looking at prices ranging from $700-1100 or more just to file, and that’s not the kind of expense you want if it’s not doing what you want it to.

Successful businesses don’t just pop into existence (Unless you count multi-million dollar corporations creating a small company for the hell of it, but that’s a debatable technicality).

Any idea needs time to form, so making it easier to build based on feedback. This doesn’t have to be months or years, we just need that first functional MVP, which can then get our ideas out there, which can, in turn, get more feedback, which can help us churn out those little updates that make everything look better.

Build your core idea, make it work, and worry about protecting those theoretical millions after proving the idea work. Good luck!

Native applications are apps written specifically to take advantage of components unique to the platform the app is being developed for. iOS and Android, the two main players in the mobile app market, are completely different operating systems. Their UIs (user interfaces) are very different, as are many of the base assumptions about content display and functionality built into their code bases.

In answer to the challenges presented by maintaining two separate, OS-specific code bases developers began creating hybrid apps, apps that ran on both platforms but shared a common programming language. To accomplish this all of the OS-specific tasks had to be handled by a go-between, a container that the app was nested inside of. Remember that iOS and Android have different ways of doing pretty much everything. This container bridged the gap between what the app was attempting to do and how the specific operating system expected you to do it. The container was a translator of sorts, taking generic instructions from the cross-platform app and translating them into OS-specific actions.

One of the most common ways of accomplishing this early on was to develop a web app, an app coded like a website, using HTML, CSS and Javascript, which would normally be served up through a mobile web browser. But instead of serving it through a normal browser like Chrome or Firefox the web app was served through a webview, a native app shell that functioned like a browser but interfaced directly with critical UI components on each mobile platform. This allowed the user the experience of running a native app while all of the heavy lifting was being carried out by what was essentially a web app.

React Native takes a novel approach to cross-platform development. Instead of saddling an app with messy, real-time translation duties like you find in hybrid apps, React Native generates fully-compliant, native code for multiple devices off of a single code base. No container program is needed to translate between the app and its environment because, using a single language and a single set of instructions, React Native creates a native iOS app and a native Android app. This is a huge boon to developers looking to create native applications for multiple mobile operating systems. It lets them focus all of their efforts on writing the app, wasting very little time making it run everywhere it needs to.

Apps built using React Native are ALMOST native apps. They can’t be called truly native because they aren’t developed using fully native techniques, but the final output uses exactly the same building blocks that true native apps use to interface with the device they’re running on. This means they are indistinguishable from native apps in the most meaningful ways. Developers can create native apps without writing a single line of code in the native environment. This optimized workflow is why so many developers consider React Native the future.

But this isn’t the end of the story. React Native certainly has its detractors, it’s own functional problems, and several other persnickety issues that could limit its viability going forward. For one, there’s no guarantee that Facebook will continue to develop and support the package. It would certainly take some doing on their end to extricate themselves from the framework since their own apps are built with it, but it’s possible that over time they may sunset the framework and move to something else. The issue is that React Native is currently dependent on the support of a somewhat monolithic patron. However, this risk could be mitigated by recent announcements that Facebook is converting more of the framework to open source, meaning the wider development community will be able to develop and maintain the package themselves.

Facebook has recently announced large-scale architecture improvements and other modifications to improve the speed and efficiency of the framework. This seems to demonstrate a strong, ongoing commitment to React Native.

And there is a strong user community building up around it. This, paired with Facebook’s plans to open source more of the framework is a strong point in its favor. It could well be that in the future development of the package moves away from Facebook and into the public domain, which increases its future viability.

There are quite a few notable projects developed using React Native. Walmart’s app, Instagram, SoundCloud, Wix, UberEats, and AirBnB are just a few. Most of these cite the shared codebase and faster development times as the biggest benefits to making the change. However it’s interesting to note that AirBnB just recently announced that they will be sunsetting the package in favor of something else. Their decision, after two years of development, highlights some of the issues React Native developers face.

Can there really be a conclusion? The trust of the matter is, no one can predict the future, but we can say with a reasonable amount of certainty given what we know now, that React Native, or some other development environment that uses a similar approach, is likely the future of app development FOR NOW. Until a better approach is formulated or until some major, game-changing pitfall is encountered, the React Native model for cross-platform app development is the best approach available for most modern developers. If Facebook continues to support and improve it and it continues to be adopted at its current rate it will be a major player in the development world for years to come.

Until it isn’t.

And there’s another reason to consider MAP versus MVP. A minimum viable product is fine in situations where there’s little competition, where users have no pre-existing expectations.

But what about situations where products like the one being developed already exist?

In this case you need to include these pre-existing expectations in your design. It’s not enough to include only basic viability. You need to make sure your user experience stacks up to what users already imagine it should be. And the greater the density of competition, the more awesome you need to make your MAP. Otherwise even early adopters may ignore you.

Consider our car analogy again. Midway through our iterative process earlier we created an MVP product that functioned like a bicycle. If bicycles didn’t already exist then no one would have any expectations for how they should look and feel. You could get away with two wheels bolted roughly to a single metal bar with a plank on top for a seat. But ask yourself if that would satisfy a customer that already had experience with existing bicycles. The answer is a resounding, “no”. In order to satisfy these customers your design needs to be elevated to match their pre-existing expectations. This, in simple terms, is the difference between an MVP and an MAP.

The thing to remember about MAP is that it still agrees that an MVP, in terms of features, should only include those needed for minimum viability. What’s in question is the user experience, the look and feel of the product. With MAP, you need to give this more love than you might with a classic MVP implementation. But otherwise the concept is very much the same.

The market is saturated and there are hardly any new ideas. What that means is, your product needs to kickass, and has to offer a better user experience than other products out there.

If you are reading this post, I would like to assume that you already know what is “internet of things” (IoT) and there is a fair chance that you are working on some idea to bring an old fashioned stand alone device to the internet.

Being in this business, we learn about some brilliant innovations every other day, but then there are times when it just doesn’t feel right. So, let us try to understand what is important and how to make your next IoT idea successful.

While it is easy to slap in devices together and get them to talk, the real value of an implementation lies in how quickly users adapt to these solutions and for how long they can serve. When investing in a project, it is important to think about building an environment and not just a device.

One of the days when your marketing collateral overhaul is a back burner project, you happen to come across a design that is just too impressive in your face. And then, when it comes to a design inspiration, you quickly raid your laptop’s history to find that great work of art that hasn’t left you yet. Voila! you find it, to assure yourself, that this is THE design you want your project to have.

One such thing happened to us while overhauling our website. And what hit us was an unassuming shape, we call a Hexagon. A typical hexagon is a six sided polygon, to define it simply. But, how does this harmless form of geometry become a nightmare.

Well it starts with that phase, when you appreciate some design. Then this admiration grows into fondness and Hexagons become the smartest thing to have happened in geometry.

The next phase is when you start noticing Hexagons everywhere. So the storyboarding of the project happens, our design is just a cluster of hexagons scrolling up and down the webpage. We are good to go. Then we add animations to them, fair enough. Now that is where the monster wakes up. How would you align a six sided figure, a bunch of them, to pop, slide, appear, or sway across the screen?

So you decide to animate each of them individually, while dancing to a common tune. That was too much music for a website design. Some hexagons jumped, some swayed, some slid etc. But it is not happening. The co-workers start giving their suggestions and inputs. We improvise, but the we are still not there. Stuck on a design we are lagging behind our deadline, numb on creativity, and a team of frustrated designers who just don’t understand what’s the big deal with Hexagons.

Our developers have started hating us, our designers think we are logic less individuals, aimlessly obsessed by a silly shape, our other key projects are getting hit, we are paying one big bunch for months together just to make a few hexagons glide elegantly from right to the left of the screen, and we still have the audacity to try, once more! Why? Because they are different, they represent complexity with a simple shape, and because you like them.

This is what hexagons can do to you. Well, this has happened with most of us, who work in creative environments. Those times, when you feel, was creativity really your calling, were you actually hired for it?

How do you shake it off:

And if this is not enough, there are apps to help: