In our last two posts on using Arbor, we talked about the two crucial steps to creating user stories: writing the story itself and adding the acceptance criteria. But while the actual act of cataloging user stories is important, a big part of the Arbor’s usefulness comes from what you do with those user stories. After you’ve captured and organized your entire product backlog in user stories, Arbor lets you quickly and easily estimate the size and scope of your project. This not only gives you a handle on the cost and timeline of the project, but it also lets you prioritize what you need to get done and in what order you want to do it. We’ve got a detailed video on this subject, but this article will give you a high-level overview of using Arbor for estimation.

Estimating with Story Points

The first step to estimation is adding a point value to each of your stories. If you look at your backlog for your project, you should see a gray circle, probably with a question mark in it, to the left of each story. If you click on the user story to see its expanded view, you should still see the gray circle, and if you click on the circle, you should see a dropdown menu with a series of numbers. These numbers represent story points, which is a theoretical framework we use to estimate the amount of time and effort needed to complete the story.

Story points are laid out in a Fibonacci sequence, which is constructed by adding the previous two numbers in the list to create the next number. We use Fibonacci sequences in story points because they build an inherent “roughness” into your estimation and encourage you to think in broader terms: ultimately, any estimation is somewhat imprecise, so it’s not reasonable for you to expect to know whether a story is 20 or 21 points at the beginning of a project. The Fibonacci sequence ends up producing more reliable estimates because you’re not expecting to have a detailed knowledge of time and cost – the estimation is just for broad, imprecise calculations.

To add a point number to a story, just click the gray circle and select one from the drop-down menu. Go ahead and do this for every story in your backlog.

Estimating: How Long & How Much

Once you’ve done this, refreshing the page should show you some number in the “total points” box of the estimation window, which is located between the user story creation field and the backlog of stories. This number shows you the aggregate number of points from your combined user stories, which is also the number of points you need to complete to finish your project.

Here’s where things get interesting. Click on the gear icon to the right of the Estimation area, and you should see a box titled “Estimation Settings” with two fields: Velocity and Cost per Week. These two variables, combined with your total story points, will let you estimate the overall cost of your project and the time you need to complete it.

Velocity & Cost

Velocity is a measure of how many story points your team can complete per week. At the beginning of the project, there’s some inherent uncertainty in this number. That’s ok, though – it’s best to take a leap of fake and enter some rough estimate of your team’s velocity. As time goes on and you get further into the project, you’ll want to revisit this number and calibrate it based on your actual working velocity.

The other box, Cost per Week, is just an estimate of the cost of your team’s time each week. If you have a team of four developers working 40 hours per week and earning $50 per hour, your cost per week will be $8,000. If that same team is working only 20 hours per person, your cost per week is $4,000.

Once you input these two variables, Arbor will automatically use them to calculate the total cost of the project and the total time in weeks you’ll need to complete it. You might notice that playing with these numbers – even only subtly – can create wide variation in cost and timeline, so you’ll want to estimate them as closely as you can and continue to calibrate them throughout the process.

Prioritizing Your Backlog

The real value here isn’t just knowing the cost and timeline of the project – it’s in your ability to prioritize certain features and see how your prioritization decisions impact your launch timeline. As an example, you may decide that only 4 stories from you 20-story backlog are necessary for an initial MVP launch, but you really want to include two more that add a nice additional functionality. However, if those two extra stories are high in point value, then that extra functionality could easily add thousands of dollars to your MVP and delay the initial launch by weeks or even months. Arbor lets you see that information upfront, so you can make informed decisions about what goes into each product iteration.

Take some time to play around with your backlog, and try using different numbers for your velocity and cost per week as well as different sets of stories to see how they affect the cost and timeline of the project. We think you’ll see pretty quickly how small changes in the velocity, cost of your team, and what stories you include in the backlog can have big impacts on the total cost and time of your project – so keep all of that in mind when you’re deciding what to include in your MVP, v1.0, and subsequent updates.

Get Arbor Today

We hope you find this estimation primer helpful, and if you haven’t tried it yet, we’d highly recommend signing up for the Arbor Beta testing program. We’re always updating Arbor with new features and improvements, so keep an eye out for those, and also watch out for the full release of Arbor, which should be coming soon. This article concludes our three-part series on using Arbor, so now you should be armed with the skills and knowledge to use Arbor effectively as a product strategy tool. So go ahead and get your hands dirty with cataloging, prioritizing, and estimating your project backlog!

In our last blog post on Arbor, we talked about the details and guidelines of writing useful, effective user stories – but writing the actual story is only half of the process. In addition to effectively writing the actual user story, it’s also critical to define the acceptance criteria for that story. Without this step, there’s no clear finish line for the story and no way to turn it into an actionable, reliable organization tool for the project. For an in-depth look at this, check out our video on the subject – but this article will give you a solid primer on the what and why behind acceptance criteria.

Defining the Acceptance Criteria

Acceptance criteria detail when a user story is considered “done.” They state, in clear, unambiguous terms, when you can consider the story finished, check it off your development to-do list, and move on to the next story. Acceptance criteria will vary in stringency and complexity from story to story, and many stories will have multiple criterions to meet before the story is considered “done.” For example, if a story says that a user should be able to log in through Facebook or through a LinkedIn account, that story will have two acceptance criterions: “I can log in through Facebook” and “I can log in through LinkedIn.”

In Arbor, adding acceptance criteria to your story is simple. If you click on any individual user story, you’ll see a text box below the story with the heading “Acceptance Criteria.” To add a criterion to the story, just type in the criterion and hit enter. You’ll now see it listed below the story. But as with all elements of user stories, the key isn’t just writing it – it’s writing it so that it’s an effective and useful guideline.

Writing Effective Acceptance Criteria

What you want from your acceptance criteria will change with each project, but we’d recommend three key principles as you write them:

  • User-Centric: Acceptance criteria should always be written from the perspective of the user. This means that the criteria should be based on when the user or customer would consider the story complete: it states what exactly needs to happen for the user to derive a benefit from the function, not what you or your team think would complete the story. It’s not about whether the button exists in the software, it’s about whether pressing the button actually accomplishes what the user wants to accomplish.
  • Comprehensive: Each user story can and probably should have multiple acceptance criteria, and some of those criteria may be about qualitative assessments instead of simple functional capabilities. If your user wants to call a car to their location, one acceptance criterion is that the care gets there. But in addition, you’ll probably want to include criteria stating the car arrives within a reasonable period of time, that it’s clean and sanitary, and that the user is greeted cordially by the driver.
  • What, Not How: Similar to the stories themselves, acceptance criteria should always describe what the user gets and not how they get it. To that end, your acceptance criteria shouldn’t say that a modular window pops up with a graphical list of items in the user’s cart, they should say that the user can view all the items in their cart before checkout.

Start Writing Stories with Arbor

Hopefully these guidelines give you some help in using Arbor effectively, and if you haven’t tried it out yet, we’d highly recommend signing up for our Beta program. Keep a look out for more updates on Arbor, as we’re constantly improving it and adding features, and also keep your eyes open for the full launch of the product. Until then, get some practice on writing acceptance criteria!

Over the last few months, we’ve been hard at work improving one of our newest, most exciting products here at Neon Roots: Arbor. Arbor is a comprehensive tool for collecting and managing user stories, which are a key part of effective Agile development, but the concept of user stories isn’t exclusive to software – it can apply to just about any field where work is done in projects. So how do you use it? The process is simple, and it all starts with writing user stories.

User Stories in Arbor & Beyond

Simply put, a user story is a way to describe some function or feature of your product. They’re written from the perspective of the user, and they follow a simple format:

As a <type of user>, I want <some function> so that <some benefit>.

This format describes the user who wants to use the product, the functionality they’re looking to get from it, and what benefit they derive from the product. In one sentence, it gives you all the information you need to know to describe and create an individual feature or functionality in the product.

Keep in mind that different users will want different things from the app, so it’s important to specify just what type of user you’re talking about. If you truly are a one-function app with one user, it may be fine to generically call them “users” – but chances are you’ll also have other parties interacting with the app or the code. When building user stories, think about all the categories of users who may touch your product: general customers, registered users, unregistered users, administrators, maintenance workers, advertisers… The list really could be endless.

This format almost looks too simple, but it’s remarkably powerful. Before we see what makes it so effective, though, let’s talk about what characteristics good user stories have. First and foremost – and this is really the guiding principle of user stories –  a user story should describe the what, and not the how. For example, if you’re building Uber, your user might want to summon a car to their location. That user story could look like this:

As a rider, I want to call a car to me so that I can get from my destination to my location.

Notice that this story doesn’t actually discuss the nitty-gritty details of how the user does this, just the broad-strokes explanation of what happens. The story doesn’t talk about the size of the buttons, the layout of the interface, or special notification system that tracks the car – it just states that a user can call a car to them.

Writing stories into Arbor is pretty simple. First, create a project and give it a name, which will lead you to a blank backlog screen. From there, it’s easy: just enter the type of user, function, and benefit into the appropriate fields and click “create.” That’s it – you’ve got your first user story!

4 Qualities of a Good User Story

As you might notice, user stories are a pretty open-ended format, so there’s something of an art to writing good user stories. While the specific rules will change from project to project, we’d say there are 4 key guidelines for writing a good user story:

  • Independent: Each user story should describe an independent, self-contained function or aspect of the product. Keeping each story about a single functionality allows more accuracy in estimating the cost and timeline of the project later on.
  • Objective: User stories, as much as possible, should be written objectively. They shouldn’t include details or information about the “best” way to do something or the “best” font size because those claims are unsubstantiated and don’t describe what functionality the user is seeking. They should only describe the broad-strokes functionality and benefit.
  • Concise: When writing user stories, it’s important to balance information density with simplicity. In general, you want to write them at the level of complexity that the layperson user would deal with: you don’t have to mention whether something is a modular window or not, only the key information or functionality the user experiences through that window.
  • Valuable: This one is critical – every user story should be there because it’s generating some value for the user. You don’t need user stories for the coloring, transition animations, or font variations of the product because they don’t actually generate use value to the user. Keep your stories about the bare-bones functionalities and how they add value to the user’s experience.

Get Your Hands on Arbor

These guidelines should give you a pretty solid command of how to use Arbor to write effective user stories, but if you’d like a more in-depth look, feel free to check out our video on the subject. If you haven’t tried Arbor yet, we’d highly recommend signing up for our Beta program, which lets you get your hands on the tech before its main release and comes with special perks and benefits. We’re adding new improvements, fixes, and functionalities to Arbor regularly, so keep a look out for updates and for the eventual main version launch. Until then, happy story writing!


In Malcolm Gladwell’s book “Outliers,” he argues for an interesting theory about how consumers find new products. He posits the existence of what he terms “mavens”: avid consumers of products ho make it their mission to discover brands and products, evaluate them, and pass their knowledge along to others. Gladwell’s concept isn’t Earth shattering – in some ways it’s little more than an adaptation of word of mouth marketing (WOMM) or an analog version of the influencer marketing so commonplace today – but it has some interesting consequences for businesses that can be used to further a brand’s reach and appeal.

Building a Trap

The key insight that comes from the idea of mavens is the fact that businesses need to go about hunting them. To take full advantage of the power of word of mouth marketing – and trust us, it’s powerful – you should build maven traps into all of your conversion funnels. So how do you go about this? Let’s look at a few examples.

Questions? Comments?

One of Gladwell’s key examples is the “questions and comments” phone number included on so many consumer products. Does anyone, Gladwell asks, really have questions or comments about laundry detergent? The answer is yes – and that has significant implications for your business.

The only people willing to call a questions and comments hotline for laundry detergent are critical consumers of laundry detergent – mavens. Your job is to catch them and convince them that your product is the best, so they can spread it through their network. Hotlines and email addresses are a great way to do this, and branded websites offer the ultimate maven trap. Social media can also be a high-touch method for this, as it allows reengagement and could even be used to offer specials to mavens, which they could then pass along to their network in a form of DIY influencer marketing.

More Traps

In addition to the simpler methods, there are other ways to build and expand maven traps. User forums serve the double purpose of building a community of users and identifying mavens, and while they’re not suitable for all businesses, they can be highly effective when there’s a fit. Blogs are another way of doing this – tracking engagement on posts can help you understand who’s interacting with your brand and how regularly. Email marketing can also be adopted for this purpose – anyone on your subscriber list who replies to one of your branded emails is likely to be a maven.

Treat with Care

The key to all of this, though, isn’t just how you discover mavens, but what what you do once you discover them. It’s critical to treat any potential maven with peerless customer service, answer their questions expertly, and field their concerns supportively. Leaving a good impression could be worth 5, 10, even a hundred more customers for your business – and leaving a bad one may have serious consequences.

So, tell us: have you had luck trapping any mavens? What has worked well for you, and what hasn’t? And most importantly, how are you hanging on to mavens once you’ve caught them?


Our thanks to Royalty Free for the photo.
Businessman Writing Planning Brainstorming Workplace Concept

Our last post centered on creating the perfect pitch for investors, and one of the points we touched on was creating a story out of your business. It’s hard to underestimate the importance of this tactic. While pitches certainly rely on hard numbers like revenue projections and growth potential, pitching your business is also an emotional process: you’re trying to secure buy-in, on a very guttural level, from potential partners in the project. But how do you do that? The answer is simple: narrative.

Simply put, creating a narrative is the process of taking a series of chronological events and weaving them into a sequence that makes sense on an emotional level. What makes it so powerful? Our brains absolutely love stories. Most people think of their lives in terms of a story, and we’re taught history in the form of one long narrative. In fact, our brains love narratives so much that we actually have to be trained not to fall for anecdotal evidence! You can use this inherent affinity for narrative to elevate your business and secure buy-in from customers, employees, and investors – you just have to learn to turn your corporate history, which is a dry, linear series of events, into a living, breathing story.

Follow the Forms

Thankfully, creating a story out of your business doesn’t mean reinventing the wheel. While there’s some contention amongst critics regarding how many basic plot structures exist, most narratives do have a few crucial similarities. You can think of the shape of your story as a hill with a long, rising slope on one side, a sharp peak, and a falling slope on the other. Narratives generally start with an exposition phase, which sets the circumstances, a rising action, which introduces elements of conflict, a climax, which presents a seemingly impossible challenge, and a resolution, where the protagonist overcomes the challenge. Use the same structure when talking about your business: set the circumstances, describe your own seemingly intractable problem, then tell the audience how you succeeded against all the odds. Exposition, tension, release: it’s an age old formula, but it works.

Embrace Your Failures

While it may seem like people only want to listen to superhumans who never get it wrong, the truth is that people don’t relate to your successes: they relate to your failures. In crafting a story about your business, highlight the times when things didn’t go as you planned just as much as when they did. In addition to adding a sense of conflict and challenge to your story, it will humanize you and your business – a critical part of helping your audience relate to you and your business.

Run Towards Conflict

Narratives almost always arise from conflict, and this often manifests as a sense of inner conflict within the protagonist. As a business, incorporating conflict is easy: what problem are you solving? Why is that important? And, most importantly, how did the problem affect you personally? You can also find conflicts in other places: internal conflicts within your business, conflicts between your business and another business or environmental factor, or conflicts that you faced personally. Just be sure that after introducing a conflict, you resolve it before the story is over. Otherwise, investors may not think you’re headed for a happy ending!

Rely on Pathos

Facts, figures, and statistics are well and good for analysts – but they mean nothing when you’re trying to communicate and elicit emotions, which is exactly what you need to do to secure buy in. At every stage of your story, ask what emotion you want to communicate, then highlight information that supports that emotion. Remember, a linear sequence of events does not necessarily make a good story – an emotional journey, however, does.

Cut the Boring Stuff

The beauty of telling a story about your business is that you don’t have to recap the history – you only have to go over the stuff that matters. It may be that after you got the idea for your business, you spent 6 months locked up in a room researching markets. That’s well and good, but we don’t need a detailed account of every week from that six-month period – just skip ahead to what happened once you found your key insight and started your business. Keep the story moving at all times, and assign narrative weight to different events based on the emotional significance they have, not on the actual amount of time they took up.

Don’t Write the Ending

While novels generally end with a satisfying conclusion and a “happily ever after,” the story of your business shouldn’t. While it’s important to resolve the conflicts you’ve introduced and tie up any major loose ends in the narrative, remember that ultimately, you’re still writing the story of your business – and you should communicate that to your audience. Don’t finish your story with a definitive ending, but instead with the fact that you’ve still got a long way to go and a lot of room to grow. In addition to leaving the audience with a feeling of hope, this will communicate to investors that while you may know how to tell a good story, the story of your business is only just beginning – and that’s just how it should be.


Thanks to Rawpixel for the image.


Pitching: it’s become part of the zeitgeist of not only the startup world, but also modern culture at large. High-profile success stories combined with shows like Shark Tank have made pitching a hot topic for most aspiring entrepreneurs, but unfortunately it’s not as easy as many might think. In fact, an astounding 1 in 2000 startups actually receive VC funding – but that doesn’t mean it isn’t important to work on a pitch. While it’s a longshot, VC is always possible, and even if you don’t pursue or secure VC funding, you’ll likely need to make hundreds of pitches over the life of your startup – to family, to friends, and to prospective partners and customers. And thankfully, there are a few simple tips that you can apply to take your pitch from awkward to Angel-ready.


KVP’s & USP’s – Acronyms That Make a Difference.


Perhaps the most important part of your pitch is your Key Value Proposition (KVP), also called your Unique Selling Proposition (USP). This is your ‘secret sauce’ – it’s the number one thing that makes you and your business special, that puts you above the competition, and that primes your business for long-term success. One thing that’s critical to understand about your KVP, though, is that it isn’t a feature – it’s a benefit. If you’re Uber, your KVP isn’t that you have a map built into your app, that you have social logins, or that you have a real-time tracking function that allows users to see their cars as they arrive. Uber’s KVP is that it can get its customers a ride in less than 5 minutes – at the tap of a screen. When talking about your KVP or USP, always frame it in terms of what benefit it delivers to the customer – not the nuts and bolts features that make the benefit possible.


Projecting Your Assumptions


Chances are if you’re pitching, you’ll need to go over your projections. These are the financial forecasts you’ve made for your business, and they outline how much money you expect to need, how significantly you’ll turn a profit, and – most importantly – how fast you expect to grow. The key here, though, isn’t just having projections for formality’s sake. It’s critical that your projections be based on real data, and when you pitch, you’ll need to know that data like the back of your hand. Any experienced investor will have come across hundreds of pitches with faulty projections before, so you have to be prepared when they try to tear yours apart with questions. Anytime you deliver projections of any kind – user base, financial, or otherwise – always be prepared with what information your projections are based on and how you will achieve those projections.


Write Your Own Story


On one level, a pitch is a presentation of factual – or at least factually-based – information: it’s you telling people about your business. On another level, though, a pitch is a story. For five, ten, or fifteen minutes, you have the opportunity to tell your audience a story about your business. So use it that way! Take the data, the analytics, and the critical thinking you’ve put into creating you pitch, then weave all of it into an engaging narrative. Remember, you’re not just pitching people for their wallets, you’re pitching them for their emotional buy-in – and doing that relies on a convincing, effective narrative just as much as good projections and sound assumptions.


Close Pandora’s Box


Here’s a simple tip that will take you miles in any competitive pitching competition, and it’s ludicrously easy to implement: never, ever, ever, ever, ever use the word “hope.” No matter how true it may be, never explain that you “hope” to reach a certain level of users, that you “hope” to pull ahead of your competition, or that you “hope” to generate a 10x return for investors. Say you believe you will, and more importantly, explain what facts that belief rests on and what actions you’ll take to make it a reality.


While pitching may not be as common, easy, or effective of an endeavor as popular culture leads us to believe, it’s still a critical part of the startup community and a crucial skill for anyone who wants to start a business. These tips aren’t all inclusive, but they’ll help set you on the path to a more effective, engaging pitch – so get out there and get pitching!



Our thanks to Doug Shaw for the photo.

hidden costs

There were just too many hidden costs that can be found in mobile app development to cover in one article. So we’re back with the second half. Last week, we discussed how unexpected additions and unplanned growth can send your budget into the stratosphere. But wait – there’s more! We only unearthed of few of an app’s hidden costs. So let’s keep digging and see what else rears its ugly head.

Testing Tests Your Bank Account

We bet you’d like to think that your app will work perfectly once the last line of code is written. Unfortunately to succeed, your app has to evolve and that means there’s much more code to write. So how do you know everything is functioning properly? You test. You test. And you test some more. These tests, these crucial modifications that come after the initial build, cost money. The cost of testing should always be reflected within your budget and never be an afterthought.

Feeling Secure Isn’t Cheap

Guess what one of the biggest user concerns of the past year was? It was not the color of your background; it’s security. If users don’t feel that their personal information is safe when using your app, they won’t use it. It’s that simple. And it’s not just for individuals. As companies invest in enterprise apps to streamline their business, they have to find ways to keep intellectual property and trade secrets, well, secret. If you only planned on functionality and not security, you’re going to be hit with costs that could sink your app instantly. And keep in mind security issues could arise long after your app has been launched. Will you still have the money to hire a developer to bail you out before all your users dump your app all together?

Seriously, Hidden Costs Don’t Have To Be Hidden

So we stressed this in the last post, but it can’t be stressed enough. These hidden costs aren’t inevitable; they can be predicted and they can be planned for. You just have to have a detail mobile app development plan in place before a single line of code is written. Even if you had an unlimited amount of money to throw at your app to fix any problems that arise, we promise your users aren’t going to stick around long enough to see it finally work.

Photo Credit:

hidden costs

It’s perhaps the greatest betrayal in mobile app development – a vile, unspeakable nightmare crouching in the shadows, waiting to strike. Hidden costs. *cue shrieks of terror* Most mobile app development companies want to keep these costs buried, want to keep them out of their estimate in hopes of not scaring away clients with the true cost of building an application. Rootstrap is here to shine a light on these hidden costs, because when you recognize the danger, you can prepare for it, and when you’re prepared, you save time and you save money.

The Unexpected Additions

Let’s say that you’ve built your MVP. Your app is lean, ready to launch, and ready to collect feedback. You’re in a good spot here. You have a workable app in the hands of users. But… there’s a problem. Your users demand more! More features, more security, more bells and whistles, you name it. You know that cliché ‘the customer is always right’? Well if you don’t listen, they don’t download, and if they don’t download, you’re dead in the water. What they want, these “additions”, are going to cost. Did you plan for this or did you blow your entire budget on the first iteration? With agile development, changes are a necessary part of the successful life cycle of your application. Plan for it.

Risks Of Rapid Growth

This is a close cousin to the unexpected additions. You launch your MVP, send it out into the world, and the best thing happens: it’s a success. Again, that’s good. What’s bad is you never planned for so much success, so fast. In order to sustain the growth, you need to expand the back end of your app. And guess what? That costs money. If you don’t have the funds to make the necessary growth maintenance, your app will crash and users tend to really, really hate that. They’ll leave as quick as they came. So long story short, you need money for ongoing maintenance and customer support. Being too successful is a good problem to have, but you have to be prepared for it.

Hidden Costs Don’t Have To Be Hidden

You don’t have to go into app development alone. If you do, hidden costs and their ilk are always going to cause you problems. That’s why Rootstrap exists – to create an end-to-end plan of execution for your mobile app that takes into consideration any and all issues that could arise and making sure you’re ready for them. Don’t put your wallet away just yet, we’ll be back with more hidden costs that are out to destroy you. *cue shrieks of terror*

Photo Credit:


So you know B2B (business to business) but do you know M2M (machine to machine)? That’s the concept behind the Internet of Things (IoT) – a concept which is much larger than you might think and will get even larger in 2016.

Because devices are much more varied than just your smartphone with the advent of smart glasses, smart watches, and a ton of other smart wearables, all of these devices need to flawlessly communicate with one another without that pesky “human factor” getting in the way. The Internet of Things is the network that allows for it. It’s a network of physical objects (“things”) that are embedded with sensors that allow them to exchange data and be controlled remotely. This could lead to more efficient integration between people and apps in the physical world. So if you’re wanting that smart home to be a reality, IoT is going to play a major role.

So just how big is it?

Gartner has estimated that IoT products could exceed $300 billion by 2020, and the World Economic Forum has said, “Fueling the Internet of Everything is the growing number of people and things connecting to the Internet. There will be more mobile devices and smartphones connected than the total global population by 2015; by 2020, more than 5 billion people will be connected, not to mention 50 billion things.”

So what does IoT mean for the future of mobile app development? Well, it means it’s something that will have to be considered when approaching a new app build. Your app will need to fit into a global network, not just necessarily function well on a handheld device. How could your app work on the iWatch, which has already has sold tens of thousands of devices and will only increase by the end of 2016? So don’t count out wearables just because everyone didn’t immediately strap Google Glass to their faces like we all expected. They’re the future, and you want your app to be a part of it.


‘Twas the night before Christmas, when all through the house
All the children and parents were busy on apps;
All glued to their screens with smiles ear-to-ear
For these four festive apps brought them all Christmas cheer.

Red Stamp (Android, iOS)

This free app allows users to create customized greeting cards with your own text or family photos, and also offers several templates for those not feeling so creative this Christmas. You can’t beat free, but you can get many more options through in-app purchases.

NORAD Tracks Santa (Android, iOS, Windows)

If someone is going to break into your house (even with presents), it would be nice to know exactly when they’re coming. The North American Aerospace Defense Command (NORAD) has brought their annual tradition of tracking the trajectory of Good Ol’ Saint Nick into a handy smartphone app. With a countdown, mini-games, and short articles on the history and traditions of Christmas, NORAD’s app can leave any restless kid assured that Santa Claus is coming to town.

How The Grinch Stole Christmas (Android, iOS)

If you haven’t shared this Dr. Seuss classic with your little ones, you’re depriving them of an amazing story the same way the Grinch deprived Whoville of the Holidays. Don’t be the Grinch. This interactive app allows parents or children to read the book themselves or have it brought to life with bravado through a narrator.

Elf Yourself (Android, iOS)

What Christmas would be complete without plastering your loved ones’ faces on dancing elves set to catchy (if not headache-inducing) music? The tongue-in-cheek nature of Elf Yourself makes for fun content to share on your social media, and because even elves need some cash, there are some in-app purchase to gain additional themes.

A Very Neon Christmas

Regardless of what you decide to download to your phone, the Rootstrap and entire Neon Roots team wish you a Merry Christmas!