Sep
26

Initial Questions for a New Mobile App Project

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!

Oct
26

Sunk Cost Fallacy: Don’t do it.

So what happened?!? What did you do with all the research?  Did you make the feature list?

We did take a few more steps post-market research.

First, with all of the info we now had from talking with ACTUAL USERS, we redefined our audience size and attributes in our TAM. And discovered that even though we were now focusing on two audiences (meetup organizers and conference organizers) we needed to further segment them into novice organizers and smaller conferences – which made our target audience much smaller.

Second, I listed out all the features needed to make the platform appealing to each audience. Then I took away anything that might not be quintessentially necessary. This list was still really long.

Let’s look at those two numbers:

  • Tiny audience
  • Giant feature list

Wait a minute…those should be flipped for a successful business, right?

This is the part of the process where you start making mental excuses even though your gut and rational brain are pointing elsewhere.

“I mean…it could work….we already put in a lot of time…people said they liked it…we can just charge less till we get more users…maybe we don’t need to target both audiences…man, we have this cool name already…everyone is going to ask what happened after our meetings…let’s just build it and see.”

And off you go to the wonderful graveyard of failed startups, because you couldn’t bear to kill you idea-baby during the research and validation stage.

It’s okay to admit that some ideas aren’t the right fit. It’s totally okay, even if you’ve put a lot of time into it.

Sunk cost fallacy is real y’all. Don’t be a part of it.

So off we go back to the drawing board, looking for a concept where the numbers make more sense and the build-out to MVP isn’t months long.

Aug
23

Sifting your User Research

So last we left you we were meeting with every meetup or conference organizer in the Metro-Nashville area. And then I emailed some in San Francisco for good measure.

When we’d meet, I had a giant list of questions that I’d generally attempt to cover during our chat. If we veered off into an uncharted area, no problem, but I typically tried to cover some of the same topics with each and every person I spoke with so that later I could compare and contrast responses. After each meeting, I’d “brain dump” everything we talked about into a text document. At the end of this I had over 20 pages of “notes” from organizers here in Nashville.

Welcome to Jennifer’s crash course in user research….

  • Did everyone say the same thing? Nope.
  • Did everyone have exactly the same issues? Nope.
  • Did you really expect every single person, to have the exact same needs? Well, no…but that would definitely have made this easier.

So how do I take all of this broad feedback and use it to come up with meaningful answers?

First I looked for trends…
  • What is something I heard from more than 3 or 4 people? Something that kept coming up without my asking or prompting?
  • What was the response when broadly outlining my idea? Tepid, interested?  People will rarely, if ever, ACTUALLY tell you they don’t like your idea. They’ll just…kind of nod and make noncommittal statements about the idea instead of discussing how they, themselves would use it.

Now what are the trends amongst the people who offered similar suggestions or had similar responses?

  • Is it one specific kind of person or kind of meetup/conference?
  • Are issues noticeably split amongst different groups?
  • Are these suggestions/trends actionable, solveable, and from large enough demographics?

I discovered that those who, in a previous life, held a job that required them to be more social didn’t have as hard of a time going out there, hitting the pavement, and offering the right information to potential sponsors. I also noticed that organizers who had been doing this for a while succeeded through trial and error, or through helping with other local efforts like tech conferences where more experienced people gave advice.

All of a sudden our market for organizers who needed help with how to ask for sponsorship was smaller. It was looking like just newbies and those whose core competency was more solely focused on code versus people .

But, I DID have one piece of feedback that came up over and over from this more experienced group – “Once we’ve used up our personal connections, we don’t know who specifically to ask to grow our sponsorship” …not what to ask, or how to ask but WHO.

This was different from our initial assumption. (And why you do this process to begin with).  And this isn’t feedback that we can easily solve with a simple solution. Which makes sense—usually the hardest problems are the most prickly. After some internal discussion we did determine that there were a few potential ways to tackle the “who to talk to” problem but none of them are super easy.

So now what?

We have to ask ourselves, can our potential product not only provide help to those with the “how to ask” problem (early stage meetup organizers), but begin to seed data and insights for those organizer-pros who have trouble with the “who to ask” part (veteran meetup organizers and larger conferences).  Will our actual “value” be on the back end of the product and not where we initially thought?

In assessing your own user research ask yourself:

  • Are there still problems I can solve?
  • Can we still reach users with these pain points?
  • Is this still profitable? (Are there enough users with this pain point, is the solution reasonable to build, and will those users pay for it?)

 

For us, it’s time to go back to the business model and adjust our numbers. If not as many people are within our initial demo or willing to pay for the proposal product, can we get enough users in there to build data for a sponsorship leads product which seems more valuable to experienced organizers?

 

Next steps?  We’ll attempt to broadly scope and estimate features for supporting the two types of users in order the reach profitability instead of just one. We’ll need to talk with organizers again now that we have firmer features in mind. And we should put some infrastructure out there to test the interest beyond Nashville (Product Hunt, Beta List, etc).

 

 

Jun
27

Forcing Lighting Bolts

So last we left you, we had dialed back our agency commitments and were skipping down the yellow brick road to product development.

#1 question we get when mentioning this: So…what are you building?

Um…. ummmmm…..*crickets*

We’re doing something a bit unconventional. We don’t have the idea yet. I don’t think the idea was going to come to us in the midst of agency-managing-doing-happening. We needed some brain space to get those inventive juices flowing again.

So what HAVE we been doing for the past two weeks?

Identifying markets we want to work in. Identifying technological strengths we have. Identifying contacts we have in interesting areas. Making some lists and making some more lists.

Most of the lists consist of the following:

  • Having AWESOME IDEAS and then getting depressed about how many great companies there are already out there doing that.
  • Coming up with AMAZING IDEAS that will never make any money.
  • Thinking of SUPER COOL IDEAS that only 100 people will need.
  • Identifying some REALLY NEATO IDEAS that will be pretty dang hard/elaborate to achieve.

Seriously. Our three lists combined (Jennifer, Wiley, and Joe) have over 150 concepts on them but no massive, undeniable winners. My creative brain is real tired y’all

And since just trying to “magic” a concept isn’t working.  We’re going back to that original plan. LISTENING TOUR 2018 for all our industries and connections that we love.

Bring me your problems, your frustrations, your business issues and I will bring you some excellent ways to fix them (provided I can also make money off of them and they ARE actually fixable).

You’ll be hearing from me soon.

Jun
15

Another large leap…

Four score and seven years ago…scratch that…just five years ago we took one small step for ourselves into the great unknown expanse of entrepreneurship and started our own company. We’ve done so much in that time, it has really flown by and instead of doing a “State of the Union” this year like we usually do, we thought we’d dig a little deeper for a “Where do you see yourself in 5 years” recap of where we went, followed by a peek at where we’re headed next.

We are now going to force you down our own cute LunarLincoln memory lane. Come watch these photos of our vacation – or rather our development shop.

Year 1: Jennifer and Wiley conceive of the LunarLincoln brand, and Jennifer designs our logo in 2 hours (startups are nothing if not efficient, right?). Wiley sits at home in the same soccer shorts he’s been wearing since 6th grade, and lands LunarLincoln’s first client. Throughout the year he builds an app for festival goers, for our favorite email marketing company, healthcare startups, photo sharing services, and more. He talks to the cats. A lot. We get temporarily Internet famous! We build things, but sometimes want to build bigger things and need extra hands to do that.

Year 2: We staff up with the addition of Jennifer and Travis (you have to see Travis’ cover letter…pure gold). Jennifer freaks out about the lack of formal business “stuff” like…you know…getting around to invoicing your clients. We add design offerings and Jennifer immediately designs the worlds most complicated UI – though it does work really well for the end goal. Travis learns all of the ways to build mobile apps. We build apps for Magic the Gathering aficionados, innovative health data visualizations, gocarts you summon via app, real-time audio syncing, custom PDF display, and much more. We get a real, fancy office in Germantown. We give talks to college and middle school kids where we pretend we know what we’re doing. We add more people and sometimes have to fire people. We almost have to sue a client for payment. We fly a drone in the office. We are in the running for a local tech competition. We set up some snazzy internal tools like a build server and a service to pull invoicing reports from JIRA. Everything is new, and we are doing a lot of googling to learn how this business thing works.

Year 3: More people, more clients, more work. We have our first sales slump and start building some products ourselves in addition to having to have some “real talks” with ourselves about sales and failure. Then we get crazy busy again, leave those products to languish in their internal repos (sorry product babies) and throw ourselves back into the work. We build apps with Research Kit, with bots, with video streaming, app for kids, for shopping, for cameras, for speakers, for ticketing, for doctors visits, for mental health. We give even more talks to more kiddos and adultos. We start hosting Cocoaheads at our office and have to take our tv off the wall each month and screw its legs on and move it to the main room and then reverse that process. each. and. every. month. (why did we do this, we must really love you guys). We deal with a rollercoaster of work and being overbooked. We come to terms with the work-shortage-fear from Year 2, and learn that you don’t have to take all the work that shows up at your doorstep. We’re making money, but have no time to enjoy it (or sleep).

Year 4 & 5: We’ve got this. We have a proposal process, we know what clients are good fits, we know better how to hire and when to not. We are getting better at estimating and saying no and questioning assumptions. We build apps for real estate agents, for healthcare goliaths, for pesticide companies, for veterans, for mobile homes and a lot of those people from Year 1, 2, and 3 come back because they like us for some reason and want to build new things. But despite smoothing of some of the roadbumps through experience and learning, others just never seem to go away. Do we grow bigger and add more support roles? Do we focus on specific markets? Should we reach for more sales outside of the southeast?

 

So pulling back out to a 50,000 ft view. I don’t think we had any idea where we’d be when we started all of this. I know that starting out we had some initial desires/ideas: “This will be awesome.” we said. “We’ll get to build what we want, how we want it.” we said. “We’ll get to have a flexible schedule and a relaxed work environment.” we said. “NO. MORE. MEETINGS!” we said.

Oh boy.

It didn’t exactly go that way. We did get to do a lot of this. We built things. All sort of things. We made new friends, met new people, helped tons of businesses. It was fun. It was interesting. We shipped apps! A lot of them.

But sometimes, it was frustrating. It was confusing. It. was. so. exhausting.

This isn’t to say we weren’t successful. We were. Very. We are even today (often in spite of ourselves).  We ran LunarLincoln as we wanted to see an agency run. Lean, kind, trustworthy, and talented. But honestly, after 5 years of building other people’s dreams, we want to build our own as well.

Now, in June of 2018, five years after we started, we will commence a new era of LunarLincoln that is a bit more product-centric. We’ll be devoting 80% of our time solely to building our products and the other 20% to select client work. Wiley is jokingly referring to it as our Project Apollo Moon-shot.

Come along for the ride as I chronicle the search for the good product idea(s). See if we take our own advice, or stubbornly ignore it. And, for the first time, we’ll be giving you a detailed peek into what it takes to build a product from scratch (without signing up for an ideation engagement with me). I’ll be dusting off this old blog and checking in much more often with you guys. (You may even get tired of my gif-laden, terrible punctuation and inane rambling. Who knows?). I’ll be posting some signups for some weekly blog series on small business bootstrapping, as well as product ideation.

But. But what about your agency work? Can I still call you?
We’re not entirely out of the running for projects outside of LunarLincoln products. We will be taking a few select projects each year and are seeking clients that are a goldilocks fit for our skill set and size. We want to be more focused and purposeful and really look for those projects that are made for us.

To all of our clients, colleagues, family, and friends: We love you, like, so much. We couldn’t have done this without you, and we’ll likely be calling on you even more often in the future for advice and pep talks.

Commencing moon-shot in five, four, three, two, one…

Jan
30

Is Your App Idea Special?

Let’s be honest – app ideas are hard. The world is big and fast-moving and what’s hip today might flop tomorrow. Having what feels like a good app idea is only the first small step in building a successful product.

 

The Process

So, imagine you’ve dreamt up a great new app idea, what should you do? The very first thing any entrepreneur should do is check if their idea already exists, but not for the reasons you might think.

You’re not looking to see whether the door is shut in your face, you’re looking to see if the idea has potential in the market. Most app ideas are not purely original. Tons of people are having the same great idea each and every day. But that’s okay! Other people with similar ideas prove that it is a good one! Seeing competitors shows that there is a need and it is feasible concept.

Realistically, you ARE going to find a few apps that do some similar behavior to what you’re imagining. Whether those apps are wildly successful or quietly unnoticed, you’ll have to innovate and find ways to improve upon these existing products. Think about features that are missing, designs that can be improved, and new ways to monetize. Do you think this market has room for another app? How can you attract the most attention?

 

What if you go app hunting and can’t find anything even close to your app idea? In this scenario, your app idea typically falls into one of three cases:

  1. Your app idea is original and nobody else has thought of it
  2. Your app idea has been discovered to be too costly to develop
  3. Your app idea isn’t appealing to enough users

Naturally, you want to be in the first category, but what if you’re not? This is hard, and you’ll likely need to reach out to potential users and gauge their interest. Continuing down this path is certainly risky but can still be very successful.

 

The Bottom Line

The harsh reality is that most app ideas are uphill climbs. You’ll work, you’ll iterate, you’ll advertise, and sometimes you’ll fail. Failure is a tough pill to swallow, but it’s a fantastic learning opportunity. Did you make a mistake when assessing the viability of your idea? Did market conditions change? Or did someone else beat you to the market while you were developing? No matter the outcome, use this experience to craft your next great app idea.

Jan
17

Native vs Hybrid Apps – Part II

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 😉 )

Jun
20

The Secret to Estimating

What’s the secret

Here is the ONE WEIRD TRICK (ok it’s more of a process) to knowing how long it will takes to build a mobile app. Here are the steps:

  1. Gather relevant information at the beginning of a project.
  2. Divide the project into smaller chunks of work.
  3. Even smaller! (If your work items are too broad you’ll tend to underestimate)
  4. Make a best guess about how long each bit of work will take.
  5. Track your time while building the app.
  6. Check how close you are at the end of the project.
  7. Repeat steps 1-5 a hundred times.

It’s not really much a secret. It’s obvious that getting better at estimates is largely a function of putting in the hours. However the better you are at estimating your work, the smoother a project will go.

Why is it Important?

Accurately estimating how long a mobile app takes to build is key to a great working relationship.

If we tell you an app will take 2 hours and it takes 200 hours, you’ll be stressed. If we tell you it will take 200 hours and it takes 2 hours, you may be happy, but you’ll likely stop trusting us.

Great estimates build trust. If our estimates are close to reality, you can trust us to help steer what’s best for your company, not only for delivery date predictions but also for budgeting and business decisions.

Here’s an example. Say you want as many iPhones users as possible to be able to use your app, which means supporting a different number of devices, running older and newer operating systems. If we know it really will take another 10 hours to support those 5% of people on really old phones, we can provide the accurate data to make a business decision (are those 5% of people worth 10 hours of development time?).

With great information, you can make great decisions.

What are the pitfalls?

Becoming an Estimate Connoisseur takes time, but there are a few things always increase accuracy. Most of it comes down to communication.

Before becoming a software developer, I held the common stereotype that developers were holed up in a corner just cranking out code. This is true for periods of time, but you may be surprised how crucial communication is to a great app. Often there’s a direct correlation on a technical team between the quality of communication, and the code.

The same lesson rings true in the realm of estimating.

It all comes down to asking questions and listening well. For instance, an estimate based on assumptions is often inaccurate. If I assume a portion of work was already done when it wasn’t, or if a task will be very simple and it is much more detailed, there are usually some painful outcomes. A project may take more time or money than originally expected, or the scope of the project may have to be paired down.

Asking clarifying questions always makes sense for both you and us when an estimate is being put together.

 

What about my app?

The real question is how long will it take to build YOUR app? And how much money will it take?

That’s something we can figure out for you once we learn about the project. It all starts with a conversation about your idea. We’d love to prove that we’ve gotten pretty good at this.

 

Feb
24

2016 State of the Union

CLIENTS, CREW MEMBERS, FRIENDS, FAMILY, AND FELLOW AMERICANS: WELCOME TO LUNARLINCOLN’S STATE OF THE UNION ADDRESS (2016 edition).

If year one was a quiet tiny team of two, and year two was a crazy rollercoaster of growth, year three was a lot of figuring out the finer points of business and moving onward and upward. What comes after the giant hurdles? The answer is hundreds of tiny hurdles. (And overcoming those tiny hurdles is surprisingly painful – similar to stomping on Lego’s in the dark – who knew?). But now that we’ve stomped all those hurdles and arrived here at 2017, I have to admit looking around that we did a pretty awesome job. We built so many new things this year, in so many different areas. We got smarter, we got stronger, and we even made a teeny bit of money in the process.

 

But I digress, let’s get down to our favorite thing every. single. year. The Work!

The Work

We added several new and diverse clients: Bkon, Camping with Dogs, GoNoodle, HealthHere, Lasso, TReAD Lab, Pacecoach, Oak Hill School, Revl, Subpac, Synchronous Health, Tandum, and VDCI …whew I think that’s it. (Totally didn’t realize it was this many clients, holy crap you guys!)

With these guys (and gals) we got to work on all sorts of new things:

Some have shipped and are available for your pocket computer right now. Some were featured and reached #1 app in Apple’s App Store. Some were used at events with tens of thousands of attendees. Some helped people do their jobs better than ever before. Some help you get out there and get moving.  Some are still in progress. Some we haven’t even mentioned above because they are too cool and top secret to be hinted at as of yet. We’ve added many of them to our Work page with greater detail, along with our amazing clients saying amazing things about yours truly. Check it out!

The Team

You can’t do the work without the team, and we’ve assembled a stellar team….I would almost say they are rockstar developers…but I won’t because that terminology is stupid. They’re really, really good. We wouldn’t have it any other way.

This year, we had our first interns (MLK class of 15) and we welcomed Cory Wilhite to the crew. There were many Friday lunches, a single ice cream truck quest (found it after weeks of hearing it!), several arguments over code abstraction, and as always: general hijinks.

 

The Community

We wouldn’t be here without the love and support of the Nashville community, be it developer or mobile dev aficionados. This year we put our money where our mouth was and sponsored several events. Some of which we spoke at and some of which we merely cheerleaded from the audience. Each of these events and groups are great examples of creativity and innovation that is flourishing in Nashville.

The Future

So what’s next? Definitely more of the same and hopefully more of better things.  In the meantime we’ll keep building, keep coding, keep working with the community, and we’ll keep checking back with you as the year progresses.

Here’s to LunarLincoln in 2017!

Love and gratitude,

Jennifer, Wiley, Travis, Patrick, and Cory

 

 

Sep
29

Working with Us

How does this whole thing work? Head to Hand. Brain to Phone. Lightbulb to Lightning Cable?

If you already have an idea of how building “apps” works then you’re most likely coming into the office with all your information ready and questions answered. However if you’re not really sure about how the idea gets from your head to the phone – we would like to give a little rundown of our process.

First. We discuss the idea.
There are two questions that need to be answered before any work can begin. First, what problem does this app solve? Secondly, who is the app for? If you don’t have solid and concise answers to these questions, you’re in for a whole lot of frustration and financial pain down the road. When you’re a month into development, and much too close to the project to remember where you started, you’ll love being able to go back and see if your new questions fit your initial value proposition. Yes? Great. No? Leave it. Knowing what you’re building prevents scope-bloat and allows for marketing/pitch success.

200-5

Second. We refine the idea.
Once we know what we’re building and for who, we sit down with our UX expert to refine features. You need a calendar app – great. Does the calendar need to send meeting invites? Do you need to see detailed listings or just high level? Do you want the views to be changeable (daily, weekly, monthly). Will the calendar send push notifications? What about having multiple calendars? As you can see requesting “a calendar” can have a lot of options.

We are here to show you what is ideal for your app and its users, what is possible, and what is cost efficient. When you say you want a house – is it this? or this?

screen-shot-2016-09-29-at-3-48-06-pm

During the ideation process we build wireframes. Wireframes are individual screen plans for all of the app’s features. The final wireframes allow us to give you a really strong idea of scope and timeline for development and serve as the app’s architectural plans. Without building wireframes we could guess at a feature list like “calendar, menus, list of cats” but it could easily fluctuate depending on what your interpretation of that feature really means (see the “houses” above).

Third. We design and test with real live users.
We take the wireframes and lay design on top. We will get a feel for the design on the project not only from who the targeted users are but also the brand and goals of the product. We do this in several ways – looking at competitors, apps the client likes, and making pinboards (yes, they’re useful for more things than your mom’s craft projects). We also place the design in a prototyping tool, Invision, where testers can click and explore. Post-design/pre-development is the best time to make sure what you’ve built works well with your users. You’d be surprised what you learn.

giphy

After the design is approved and flows are optimized based on user testing, the assets are exported and ready for development.

Fourth. We get to coding.
Our developers take the wireframes, designs, and interaction instructions and build “user stories”. These stories compose the scope of the project. “A user can tap a login button to view a login screen” or “A user can tap “support” to bring up a completed email” or “A user can view a loading animation”. These user stories are the meat of the project. If a feature is not clearly specified in a user story the developer will not know what to build. Or really – we can make assumptions. But we all know what happens when you assume….

Many times while coding, there are additional choices to be made (how should this baby be built under the hood?). With code being broken into smaller user stories a client can come in at any time and re-prioritize tasks, leave notes on current tasks, or adjust the plan without affecting the past work or current schedule.

Fifth. We test and deliver the code.
During development, when a set of user stories are finished (similar user stories are grouped into Epics – ie. “onboarding”, or “settings”) they are tested and reviewed by other crew members. If everything looks great, it is sent to the client. We generally like to send “builds” of code to the client at least every two weeks.

200

Steps Four and Five on repeat.
Code. Review. Test. Code. Adjust. Review. Test. Adjust. Code. Code. Code. Review. Test.

Sixth. We publish the app.
When everything is ready for a current version – we push it to the app store. That doesn’t mean it magically appears in a user’s hands. Apple and Android once again review your code and make sure it is in working order for the user. After their approval, it is in the store ready to be downloaded, promoted, and used by your adoring fans.

200

Copyright LunarLincoln 2023. All Rights Reserved