LunarLincolnLunarLincolnLunarLincolnLunarLincoln
  • Home
  • Process
  • Services
  • Work
  • Writing
  • About
  • Contact
  • Home
  • Process
  • Services
  • Work
  • Writing
  • About
  • Contact
Sep
26

Initial Questions for a New Mobile App Project

  • Posted By : LunarLincoln/
  • 0 comments /
  • Under : App Advice, Business

It can be daunting to know the first place to start after you know you want to build a mobile app. We are here to help. We can help you focus in your project goals on what makes sense.

Ultimately only you will be able to provide the core vision for what you need. As you ask the questions below, think through the lens of what needs to be in front of users first.

Let’s Build a Minimum Viable Product

Minimum Viable Product

Source: Kunal Naik

Since building technology costs money, having priorities will save you money. So what are the priorities? As we explore this question, keep in mind that it’s always smart to build a minimum viable product (MVP) first. Rather than having a little of everything that works ok, focus on building one aspect of your vision well so that it’s a great foundation. That may mean focusing on one platform before doing both iOS and Android. It may mean we should focus on core functionality before adding extra features.

Have an idea of what’s a must-have versus things that aren’t crucial. This will help you know what you should invest in first. It’s always better to get a smaller, great product in front of users, rather than an app that has more, but doesn’t work great. Having an MVP also helps you get to market faster, which has huge advantages. If you keep launching major updates to your app every 6 months, you’ll be learning what works and what doesn’t. This saves you money since you know which ways you need to pivot your thinking. It often doesn’t make sense to work on a large app for years, without getting feedback from users along the way.

That’s the critical piece of advice I’d give any of my friends who are involved in getting an app built. Keep in mind you’re building a MVP, and not the kitchen sink when considering the questions below. Here are some common questions we get when people reach out for a quote. This should help prepare you for a conversation with us.

Let’s Play Common Questions Bingo

If we wanted to build a Bingo board with the common questions that come up during a conversation about building an app, we’d be winning lots of Bingo. If you don’t know how to answer the questions below, spend some time thinking it over and reach out if you’re stuck. We can point you in the right direction.

You want to know: “How much will it cost?”

We need to know the answer to some of the questions below before we’re able to answer this one for you. In general apps are expensive to build, and zeros are involved. Thankfully a round number can get more focused as we learn more.

So what will we ask to get to the answer for that question?

What’s the big idea?

What makes this app unique and different? What will compel people to use it? What is that one thing that absolutely needs to come across when someone uses this thing?

What kind of features are you envisioning?

What are the core thing someone can do with your app? It can be helpful to see if you can distill your app in 2-3 user stories. A user story is a high-level description of one of the things a user can do with your app. Here are few examples:

  • As a car driver I can swipe my app while paying for gas to earn rewards.
  • At the gas station, I can show my app to redeem rewards at the counter and get a free Coke.
  • As a beer enthusiast I can scan a beer’s barcode to see details about a beer.
  • As a movie buff, I can search for a movie and mark it as watched.

Does this need to be an app?

Hang with me. Sometimes people will have an app idea that may not lend itself to the app format. If you want to build an app for writers that helps them build up their typing speed, it may work better as a website or desktop app, where people are more likely to have a keyboard when using it. What’s the advantage to people having this product on the go?

Who is this app for?

What’s your target demographic? Who will be using this app? This can help decide how the user interface works.

How do you plan to make money with this app?

This may sound a big harsh, but what’s the business plan? If you haven’t considered the longterm plan for how the app makes you money or meets your goal, you may be missing a core feature that needs to be in the app.

What’s the play? Should users be able to subscribe monthly to the app? Are there in-app purchases? Are there ads or messages from you or partners? How does a user give you valuable information such as their email address so you can reach out and tell them about your next rally for saving the rainforest? Does your app help you reach your goals?

Do you have a specific timeline in mind?

Do you have time pressures tied to your app? For instance, are you building an app that helps you create custom emojis that you’d like to release on the same week that the next Emoji Movie releases? Or do you have investors or stakeholders with expectations on when the app will be rolled out?

Based on the timeline, we may recommend what would be doable within your desired time window.

What other apps are your competition?

This question helps in a couple ways. Are you building an app that already exists? If so, what is your competitive advantage? If you’re building something different or better than someone else, how will that inform the features you’re wanting?

If you do have competition, what do they do that you also want to do? One advantage to not being the first on the scene, is that you don’t have to re-invent the wheel. You can likely glean from others what is already working in your space.

How fleshed out is the design?

Do you need a designer? Or is everything already mocked up? If you need some help with the ideation phase, we can help figure out a plan. Knowing how far along you are in this step will inform how long the process may take.

What devices will be able to run your app?

On what devices will your app be able to run? Can it only run on iPhones? Or just on Android phones? Both? What about tablets? Should the app look different for users using larger screen sizes? The answers to these questions greatly impact what needs to be built.

What other technology will accompany the app?

  • Do you also need a website?
  • Does an API need be built so that the app can access the data it needs?
  • Do you need an interface that allows you to edit or see user details?
  • Do you need analytics about the app so you can see reports of how people are using it?

Bingo!

If you have the answer to 5 of these you’re off to a great start. Keep going. If you don’t have all the answers, that’s totally fine. We can help you think through all of the questions above. These are just some introductory questions we often cover so we can start to figure out the size of your project.

Reach out when you’re ready to figure out your app’s next steps!


Apr
19

Let it go – Building a real MVP

  • Posted By : Jennifer Bennett/
  • 0 comments /
  • Under : Coding

In Startupland, the most valuable product is the Minimum Viable Product (MVP). Why? Because you didn’t blow your entire budget/savings getting there.

People often come in and start throwing this term around “MVP”. Requesting something along the lines of:  iOS and Android apps, a web portal, and a full dashboard for all users and grandma! Oh and an admin portal with state of the art features as well.

This is not an MVP. This is your wish list. Your nice to have list. Your 2 years in list.

“But…but… I NEED to have these things or I won’t be successful.” you say.

Hogwash. Success is based on building the RIGHT thing. Not ALL the things. I know it’s exciting to start building but slow your roll!

While it’s not too hard to trim an initial feature list down by pairing some low hanging fruit, oftentimes you’re still not at your target budget. You may need to drastically slash costs to get to market or not get there at all. At this point we’re not talking about removing 2 questions from the signup page or changing out how fancy search is, we’re talking about removing entire areas or better yet – entire platforms. 

Prove your business model before investing in it in multiple tech stacks.

Do you rrrrreally need that admin portal for your 25 users?  Can you hold off on Android to see if what you have in iOS is really what users want? Do users really need to have both web and mobile access?

 

What should I cut when I don’t want to let go?

1. Assess features & users to find platform launch targets

Where are your users hanging out? Are they older? Younger? Are they turning to the web for this service? Is this something they need on the go? Assess your audience and the core features of your product to determine whether this is a web or mobile play to start (you can add more entry points later! This isn’t forever!)

2. Sweat Equity for Behind the Scenes

Even the great and powerful OZ understood the value of manual effort.

Do you really need all the management stuff automated? Weigh your time versus your cost of development. Is hiring a $10 an hour intern to review applicant profiles cheaper than building a machine learning service? Can you keep track and manage payments with excel and quickbooks instead of a custom point of sale system? Only upgrade/build your tools when the workload demands it not before.

3. Tech debt can be your friend (in the beginning)

Don’t polish and deeply invest in a feature if it isn’t proven yet. High traffic areas can be improved upon once their value is clear. What if you spend half your budget on a feature that when launched collects cobwebs from your so-called target audience? Make pivoting painless with lightweight development decisions.

 

Infinite runway? A budget as deep as the Grand Canyon? You may not have the make these hard choices, but I would still advise you to do so. It’s healthier for a product to be able to grow based on real world user experience. Give yourself the flexibility to change features and change messaging without having to visit 6 different codebases and remove 8 months of work. A simple product launch isn’t easy or straightforward, but it’s a smart one to start with.

Still having a hard time slimming your MVP? We’re here to help! We love creating products that built for success and don’t have a problem saying no (or strongly judging you for not being able to say no to yourself).

Need someone to question all your decisions and make helpful suggestions?

 


Jan
17

Native vs Hybrid Apps – Part II

  • Posted By : Jennifer Bennett/
  • 0 comments /
  • Under : Business, Coding

We recapped the technical decisions of whether you should build natively or with a hybrid solution back in this post. But let’s be honest, native is “technically” always best.  The real reason client’s opt for hybrid solutions comes down to one thing. Money.

Why pay for development twice when you can build it once? Right? riiiiiight?

Well, sometimes.

If your desired app is largely simple elements and displays content: like reader apps or lists or shopping or blogs then YES HYBRID! If your app only needs maybe one or two things that need native integration then PROBABLY HYBRID.

The catch with hybrid is that any part of the app that needs any sort of custom UI or native phone integration like maps or camera, etc is going to need to have a native-code bridge written between your hybrid solution and the source. Which means we’re back at native development twice (Android and iOS), and your money savings is starting dwindle. Remember this image?  Also, that in-house .NET team you thought could whip this up in their free time? They might get a bit stuck at those parts.

When there are new updates to the operating system from Apple or Android these third-party providers need to write their own hybrid platform features to interact properly – causing you to be reliant on their timeline for upgrades instead of implementing code updates the day the OS is made public.

To recap the recap:

Hybrid is cheaper in that it often uses web developers (lower rate) and is mostly build once, use twice. Great for simple projects, first/test versions, or apps that generally are reproducing web content verbatim.

The caveats are that:

  • You’ll still need to build native bridges to more complex parts of the app (bye web developers!)
  • You are reliant on updates by your third party platform to maintain pace with new operating system updates (dependencies)
  • It still has those technical limitations of UI and responsivity (design award bummers)

I’m sure you’ll find lots of articles about both – we’re obviously a bit biased being an all native shop, but we HAVE built a few React Native prototype apps to see for ourselves.

But sometimes, after listening to a clients needs, features, and budget, we still find ourselves recommending hybrid. Honestly! We want you to get the best value AND the best app! Success for everyone!

So take what we’ve said above and before and assess for yourself! Do some pro/con lists. Ask your mom. (Or don’t ask your mom but DO ask the opinions from many potential contractors). Read more than one article.

We hope at the end you come back and choose to build your app-baby with us (if its native 😉 )


Jan
10

The. End.

  • Posted By : Jennifer Bennett/
  • 0 comments /
  • Under : App Advice, Business, CaseCollage

You’ve had the idea. You’ve built the app. You’ve marketed the hell out of it. You’ve seen results. You’ve made updates and improvements.

But now what?

Are you done? Close the lid, package it up, never look at it again? You could. For CaseCollage, this app did achieve what we set out to do. We got widespread exposure. We got to practice the whole app launch process from start to finish on an app that wasn’t really “our baby”. We learned more about working processes and how to run more efficiently in the future.

CaseCollage definitely has more we could do. In fact we have pages of “future plans”: Refining UI to add a copy/paste element, implementing in-app printing and delivery with third-party companies, additional templates for other hole-designed cases or case company partnership. But all of this requires significant additional time commitment. And we all know time=money. Whether its time for client work or time for new ideas – the current rate of income for this app doesn’t work out for future CaseCollage development.

It is hard for many to decide when is your app finished. It isn’t always as simple as profits. There are a lot of questions to weigh: Is the app something you are passionate about? Is it something that could see leaps and bounds of improvement with some updates? Is there a dedicated user base and room for growth? What about your current user base? Do you want to leave them in the lurch for future OS updates? If we had deeper, more complex answers to some of these questions, maybe we would pause and devote some more hours to the project. But, as stated above, it did what we wanted, and we’re happy with the final results (and app).

We aren’t completely shuttering CaseCollage and never looking at it again. Rest assured, I will still be coddling my instagram audience with daily/weekly new designs, and providing basic customer service (for the millionth time, please print “fit to page” do not print a screen shot, no shit, that isn’t going to be sized right). It is just time to devote the majority of our brain power to new exciting endeavors.

Just like the Internet and their goldfish attention span, we have one as well.


If you’re late to this rodeo, you may not know, we built an app and wanted to share some of the details. You can find related articles below:
Part 1: The Ah-Ha Moment And What Comes After – The idea for the CaseCollage app

Part 2: Building an App in 2 Weeks – App development process, Wiley’s analytical take

Part 3: Roller Coaster App Store Review – App store submission hurdles

Part 4: Becoming “Internet-Famous” – Prepping for launch and app marketing 101

Part 5: Squashing the Bugs and App Maintenance – When things invariably go wrong

Part 6: A+ Work: Analytics and Ad Tracking – What are all these chart thingys?

Part 7: The. End. – The lifecycle of an app


Recent Posts
  • Copious Communication
  • Initial Questions for a New Mobile App Project
  • Gif TV: A LunarLincoln Product
  • Onboarding other peoples code
  • What’s in a name?
  • Don’t build it all. Picking a Platform.
  • Talk to your Users
  • Design for Fat Fingers
  • A new look
  • Hourglass for Jira
Archives
  • May 2021
  • September 2020
  • November 2019
  • October 2019
  • June 2019
  • April 2019
  • February 2019
  • January 2019
  • October 2018
  • August 2018
  • June 2018
  • April 2018
  • January 2018
  • October 2017
  • August 2017
  • June 2017
  • February 2017
  • January 2017
  • September 2016
  • July 2016
  • April 2016
  • March 2016
  • February 2016
  • October 2015
  • September 2015
  • July 2015
  • May 2015
  • February 2015
  • December 2014
  • November 2014
  • September 2014
  • May 2014
  • April 2014
  • January 2014
  • December 2013
  • September 2013
  • August 2013
  • July 2013
  • June 2013
  • December 2010
Categories
  • Agency
  • App Advice
  • Branding
  • Business
  • Business
  • CaseCollage
  • Coding
  • Design
  • Design
  • NSVille
  • Uncategorized
  • Web Design
Copyright LunarLincoln 2023. All Rights Reserved