Introducing the app we’ll be building publicly step-by-step

Will Little

At this point in our web and mobile development series I'll introduce you to the specific app we will be building together. We'll follow the steps we mentioned in my previous post “So you have an app idea. Now what?” — which means I'll attempt to actually “walk the walk” and follow my own advice.

[Author's note: I wrote the first couple dozen tutorials in this series a few years ago and I'm in the process of updating the content to reflect the evolution of best practices in the industry. Please comment if you see anything I missed that should be updated. Thanks!]

An app to make meetings more efficient

Ok — so our idea is basically this: We believe that meetings — at least those with the intent to get stuff done — should be more efficient. Too often meetings are disorganized and have agenda items that could be discussed over email and/or do not result in specific action items owned by specific people. Therefore, to solve this problem we're going to build an app that coordinates users, meetings, agenda items, and action items.

That's it. Now let's walk through our steps:

Doing our homework. Is this idea any good?

Let's consider the questions we advised everyone to think about:

• Is the idea taken? — Well, yes, for this simple concept and ubiquitous problem there are a ton of apps — but most have bloated feature sets, are relatively expensive, and/or do not have an interface for Android, iOS, and mobile & desktop browsers.
• Is the idea valuable (to impact a significantly large market)? — Yes, people around the world, especially business professionals, are well aware that meetings are too often inefficient. A growing percentage of this world-wide market has access to a smartphone and/or a laptop to take into meetings.
• Would we be regular users of the app? — Absolutely, we see it especially valuable for keeping track of ongoing, regular meetings with companies we work with.
• Is there an easy way for this app to go viral? Yes — users invite other users via email. This will likely be the main avenue of viral growth, and we'll of course use standard practices to facilitate social media sharing.
• Will users stay engaged after signing up and checking it out? — Users will either incorporate this app intro their business/non-profit rhythms OR they will likely not use it at all. In other words, the solution we are providing does easily facilitate ongoing engagement because this is the central purpose of the app.
• How much time and money will we lose? — The main costs will be for the domains and web hosting. Because this is a relatively simple app, it will not take long to build. Thus, for about $100 USD and a handful of hours, we can give this a go for a few months and see what happens.

Bounce your idea off the most experienced and trusted people you know who have built a software company

Done. The general consensus is that there are no well-known players in this specific niche and — if done right — an app like this would be valuable to users. Large organizations use executive assistants to handle this stuff, and small organizations usually hack together their own solutions that don't work consistently.

Establish an informal advisory board of ~3 people

Done. This is a subset of our network of partners — and they have agreed to help.

Get one or two others (max) to be co-founders with you.

Done. This app will be built by Will (i.e. the author of this tutorial series), and our UI developer (Tim) who was part our LaunchPad Program.

Interview a couple dozen potential users and write up a short, non-technical overview of your Minimum Viable Product (MVP), including user stories

OK, done. We asked what their pain points are in meetings, what software they are using now, and if they would use an app if the UX was awesome. And here is the overview (yes, it should ideally be this short — missing pieces will be sorted out later in the wireframes, mockups, and flow chart):

Overview

We believe that meetings — at least those with the intent to get stuff done — should be more efficient. Too often meetings are disorganized and have agenda items that could be discussed over email and/or do not result in specific action items owned by specific people. Therefore, to solve this problem we're going to build an app that coordinates users, meetings, agenda items, and action items.

User Stories

New User — visits our site on their desktop or mobile browser and understands this is an app to make meetings more efficient by easily coordinating users, meetings, agenda items, and action items. This user will be able to easily start the signup process by entering an email address. If desired, this user can “contact us”, read testimonials, an “about us”, or other marketing copy/graphics to help them understand the app and trust it enough to start the signup process.

Existing User — after confirming their email, they will set a password/first/last and then see a dashboard where they will have the ability to (1) edit their profile (first/last/avatar/email/password), (2) add agenda items (between one or more users — ideally they solve agenda items over email without an in-person meeting being necessary), and (3) schedule a new in-person meeting where they enter meta data (i.e. title, start time, place), agenda items, and users (via email address or names of users they are already connected to) for that meeting.

Leading up to a meeting, and during a meeting, users can comment on agenda items. During or after a meeting, an agenda item will either be closed, remain open (e.g. for email discussion or for a future meeting), or be converted to one or more action items owned by a single user (and can be tagged w/ other users) to be completed by a specified date and time. The app should encourage action items to be SMART (i.e. simple, meaningful, attainable, realistic, and time-sensitive) — and should email tagged users (one time) if the action item is past due without being closed — something to the effect of “hey what's up, this is past due”.

Come up with a name, reserve the namespace, and get the legal stuff done.

We've decided to go with, for now, the name “Our Agenda App” — and we've reserved OurAgenda.Info and the “OurAgendaApp” Twitter/Facebook usernames. This is a good point to also buy reserve namespaces/domains related to your domain (e.g. common misspellings, etc…).

On the business side of things, we registered the trade name “Our Agenda App” with Washington State via our existing entity (Startup Rocket, LLC).

Build the visual identity and initial user interface before we start writing code.

Based on the spec, our designer worked up the following mood board, which we like to start with when building the brand/identity/design of apps before coming up with the logo or the look of the home view/page.

This “feel” and general color scheme will direct how we move forward with the design, which we'll discuss later in this tutorial series as we move forward with next steps.

- — -

In our next post, we'll jump right into setting up our Rails and Backbone.js software architecture with “Hello World” examples across the many languages we've introduced thus far. This will prepare us to receive the cutups from our designer and begin hooking up our app so we can test it on mobile browsers. Previous post: So you have an app idea. Now what?