How to Define the Features of your App

You’ve created the next Facebook. Billions of users are logging into your app every month to get the latest news and updates from the world — but you didn’t always have this success. What were the first two features that you launched?

Minimizing your feature list is one of the most difficult and critical decisions product owners make in the beginning. What features do you build and what do you forgo? How do you make your Minimum Viable Product, the first version of your app, be completely minimum? At Vaporware, we receive feature list documents in all shapes and sizes, and work with founders to focus a large feature list into the 2 most impactful features. It’s important to start this minimization process, which we opened for your use at, with a common understanding and vocabulary.

What is an App’s Feature List?

feature is a unit of functionality of a software system (app) that satisfies a requirement, represents a design decision, and provides a potential configuration option.

Borrowing from App development Agile methodology, Vaporware defines features as User Stories, that describe what an end-user would see and expect a system to do.

As a <type of user>, I want <some goal> so that <some reason>.

For example, here are a sample of some features for a Photo Contest Marketplace App:

Company hosts photo contest
Users can login through social media
Users upload photos to contest
Users can vote on photos
Users can comment on photos
Company can download all photos uploaded
Contest shows a map of all photos
Contest photos can be ranked by popularity
Users can contact company host for feedback
Users can see a directory of all contests
Users can search for contests
Contest links to other relevant contests
Users get emails when people vote for their photos
Users can flag a photo as inappropriate
User wins contest after a week goes by
Many users can login as a company

Adding Intent

Right away, you will notice that these do not follow the ideal format. While not very detailed, they also skip the reasoning behind the feature. Representing a feature with the story allows designers and developers to understand its context, which launches discussion for solutions.

For example, the first feature

Company hosts photo contest.

is better represented as:

The company admin can host a photo contest on behalf of their company brand so they can get more brand engagement.

Your team now sees the intent behind the requirement. With just 5 more key words the context, intention, and goal is clear. Try adding some extra detail to your feature lists through our DefineMyMVP tool here. When work begins, your developers and designers will thank you for the context.

Breaking down App epics into features

Even the detailed version of this feature didn’t convey the original intent our client had for this feature.

A company administrator can host a photo contest on behalf of their company brand so they can get more brand engagement.

With this technique and level of detail, we learned that this feature was actually an epic, or collection of features, waiting to see even more detail. Here’s an example breakdown list of what this one became through conversation:

The company admin can define terms of a photo contest so that users clearly understand the rules.

A company employee can share and market the photo contest so that more people can find and enter the contest.

A company employee can view all photo entries so that the best photos can be selected and improper photos can be removed.

The company admin can select a winner of the photo contest and contact the winner with details to the winnings so that the contest can end and a prize can be awarded.

Right away we can start to see a separation of user roles within a company, learn about the workflow process behind a photo contest, and find some auxiliary functionality with sharing and managing photos.

Length of Feature Lists

While dreams are beginning to look more like reality, limiting a feature list helps product teams focus on a manageable scope and deliverable. Breaking modern products down with three phases helps us define limitations to high-level feature lists.

For a Minimal Viable Product we recommend focuses on 2 high-level features. For a marketable product, we recommend a list of 16 features maximum. Anything more than 16 becomes more valuable as a suite or collection of products that are separable at some level as they target multiple users and a variety of use cases.

Feature lists are great marketing tools as products target larger markets. Squarespace is a great example of a modern Content Management System (a suite of products) with quite a full feature set. Start defining your feature list with  DefineMyMVP. It’s the perfect process for product owners to focus their MVP (the 2 main features) of a large feature list.


The bottom line

What will my complete app cost for Vaporware to build it?

The majority of the applications that are built today are not inventing new technologies but are using proven technologies to deliver innovative experiences. For these applications, software apps are the core of a User Experience that is highly scalable and therefore profitable. But if you’re looking to build one of these apps, how much should you expect to invest by the time it’s complete?

Startups engage Vaporware for our experience and expertise to provide the best software foundation for their new businesses. But there are a few inherent myths in the question we proposed above.

Bring lessons learned, but a manual MVP is a different product

Vaporware uses the Lean methodology in practice for every client. If you’ve engaged in the entrepreneur ecosystem, you’ve probably heard the term “Lean” several times, but do you know what the Lean startup process really is?

In short, the Lean startup process is a 2-step process:

Step 1. Collect payment with a Minimal Viable Product (MVP)

Step 2. Build/Measure/Learn ad infinitum.

The first step of Lean is creating a Minimal Viable Product. What is the smallest investment a startup can make to create something that will earn money. More often than not, this is something so small and manual that you don’t need anything more than your self to produce. Are you walking dogs? Processing payments? Scheduling appointments? Providing advice? Each of these things can be done and receive payment without writing a single line of code. According to Lean methodology these are technically Minimal Viable Products.

What most startups at this stage don’t see is that the product they’re selling with these manual MVPs are often themselves performing a task. These MVPs are good lessons, but not complete indicators of a scalable business. Their personal reputation and brand needs to be scaled along with the task itself. A personal brand is curated over months and years of relationships. During our Product Design Sprint, we help define what makes the manual MVP (the customer test) successful and align that with the company before ever writing a line of code.

Once the prototype, the deliverable from a Product Design Sprint, is in place, we can build the initial software Minimal Viable Product in about 4 weeks of heavy development. Once the MVP is delivered, the journey to a sustainable company has only begun.

There’s no such thing as complete

The second step of Lean is a cyclical process that is broken into 3 stages (Build, Measure, and Learn). These 3 stages are then optimized for speed to deliver measurable results in as little time as possible. Most clients hire Vaporware to do part 1 of this process, which is to build something measurable. While this build stage is often customizable, we minimize the time impact by delivering results in as little as 1 week. More importantly, we never scope work that would take longer than 1 month.

The hidden impact of this process is that there is no such thing as complete. Even with a set list of features, each feature can often be iterated on thousands of times to deliver better and better results. While the original founders and owners of a product may have an exit strategy, the limiting factor of software development is never quality, and therefore apps can never be finished. Due to market changes, customer requests, investor forecasting, and the unforeseeable there will always be changes, edits, features, bugs, updates, etc.

Lean doesn’t mean cheap

The MVP is designed to be as cheap as possible. Each phase of development and release to users should be designed to be as fast as possible. But the overall process is not cheap. It’s in the investor’s best interest to keep investments as small as possible, so returns are as high as possible, but that should not equate to the business’s mission or the product delivered. Even Amazon, one of the most frugal corporations in existence, has incredibly large investments.

So what’s it like?

If you’ve never built software before, there are a few experiences you may have had that can relate to it. It’s very much like having a child or building a house. You weigh your options, work within your budget (both time and money) limitations, rely on experience, and minimize risks to deliver the best results possible.

All of Vaporware’s advice and work is constrained by time, which we equate to features through estimation. Through a trust-driven client/consultant relationship, Vaporware helps define potentials and identify risks for every feature of development. With a separate budget per feature, we can directly correlate business impact to the feature that we design and build.

Interested in working with expertise? Reach out to see how we can help.

Rails Feature Tests With RSpec and Capybara-Webkit

Using RSpec and Capybara-Webkit provide a great workflow for writing feature tests for your rails application.  This Imageallows you to write automated tests that are simulating page visits, clicks, filling out forms, etc.  This can be extremely valuable in that it is checking every layer of code behind the processes that you instruct it to perform.

Have more confidence in your code

Testing code is an integral step in the workflow developing applications.  It allows the developer to have a certain level of comfort while working, that the tested code won’t be broken by implementing new code.

It can be stressful trying out new techniques and technologies in an existing code base, so having a test suite ensuring that the rest of the code isn’t being broken has immediate benefits.

The tools I use for feature testing are RSpec, and Capybara-Webkit.

RSpec is a DSL(Domain Specific Language) written in and for Ruby.  It is a vastly popular language used for test Ruby code, even though Ruby comes with test::unit built in.

Capybara is an acceptance testing framework, which tests the application as if from a user’s perspective.

The purpose of this post is to give you a basic understanding of how to implement Capybara

Writing the feature test

Before you get started writing the code, I need to make sure that you have everything necessary installed.

One common cause of failure when installing Capybara-Webkit on Mac OS X is the lack of QT.  Since I am using Homebrew, instillation is as simple as entering  brew install qt into the command line, and hitting  return .

With that done, I head over into my project’s  Gemfile and add the following:

Ensure that the Bundler gem is installed  gem install bundler , then simply run  bundle install , and that should install RSpec and Capybara-Webkit.

Head over to the  spec_helper.rb file, and add the following line

Here I am going to be testing the completion of a login form.  I am using Devise for user authentication.


This is the form that will be the victim of this feature test.

Inside of the  spec/features/users/login_spec.rb file, ensure that you include
require "rails_helper".

Since this form is assuming that there is already an existing user that is signing in, a user needs to be created for it to login with.

Now that it has the user, I am going to want to instruct Capybara to  visit  the user login page, in this case this is accomplished using the  new_user_session_path . We now have:

One great thing about Capybara, is its ability to interact with the website as if it were a user.  You are able to use commands such as visit, click_link, click_button, fill_in, and more.  A list of commands can be found on this capybara cheat sheet.

We are going to want to have our test  fill_in the Email text box with the email address we created.  This will be done by entering
fill_in "Email", with: "".  We then do the same for the Password field.   fill_in "Password", with: "helloworld" .  Clicking the sign in button is as easy as  click_button "Sign in" , this is why I love Capybara!

The only thing left for our test to do is to expect that something happens!  In this case, we are going to expect that our message stating “Signed in successfully” is shown after a successful sign in.  This leaves us with:

Now that the test is written, we head back to the command line, ensuring that we are in our project’s directory.

Since I stored this test inside of the  spec/features/users/signin_spec.rb file, I am going to run  rspec spec/features/users/signin_spec.rb .

After receiving the message  1 example, 0 failures , I can walk away knowing that this form works.  Now if a feature is implemented that breaks it, we will know because this test will fail.

Feature tests are meant to test the high-level processes by interacting with the application as if by a user.  Unit testing will go much more in depth, and allow you to test the individual methods being run behind the scenes.

A Focus on User Experience

Here at Vaporware, we’re focused on delivering the right products to markets in short deliverable sprints. All products, including minimally viable ones, require the right team of people coming together in a streamlined fashion to deliver on the business goals.

So far, Vaporware has taken the approach that responsive web is the correct business decision to delivering an MVP to early adopters and testing a business model. We’ve optimized our processes, stripping down design and limited technology scope to deliver functional and usable critical paths for our clients projects over the last 3 years.

Today, we acknowledge that the needs of our clients extend past the MVP and functional iterations. Today, we’re scaling our team to deliver a more complete User Experience service offering.

Until now, we’ve been partnering with some of the best designers and iOS-native developers to take MVP iterations to the next level. While these partnerships will continue for our MVP service offering, we’re on a search to bring the right craftsmen (or craftswomen) from far and wide to the triangle, so we can deliver the best User Experience products with the speed and efficiency our clients love.

Know someone worthwhile? We’re looking for individuals greater than ourselves who want to be a part of something greater. Send them over to our jobs page to learn about who we are, what we’re working on, and where we’ll head together.

An Open Source Project for the Triangle Community

Vaporware is heavily involved in our local community. Free office hours, sponsoring events, and online tutoring are just a few of the ways we’re committed to growing the community that created our company — The Triangle Region of North Carolina.

Over the past several months, we’ve been heavily involved with Innovate Raleigh, the think tank that created HQ Raleigh and continues to bring the entire Triangle Region into the top 5 innovation hubs of the nation. While we’ve co-chaired two committees over these past few months, we’re now busy at work doing what Vaporware does best — creating web applications.

Innovate Raleigh’s Resources committee has started down the path of solving the innovator’s dilemma by creating a Sherpa guide to new startups in the triangle. Targeting these new entrepreneurs, we hope this guide will be a useful stepping stone to accelerate entrepreneurs in the Triangle region. Part local mentorship community and part connector, this resource guide will help highlight the Triangle’s leaders by enabling them to curate (aggregate and distill) their own collections of resources.

While the product was just started a week ago, we’re proud to announce that we’re open-sourcing the entire initiative and welcome Pull Requests from anyone and everyone who would like to improve their local community. Not a developer or designer? You can still help by attending our weekly stakeholders meetings and contributing to the project in one form or another. We have lots of need in all aspects of the project.

Right now the product is in Alpha, targeting HQ Raleigh members, our controlled early adopters, but stay on the lookout for when this product launches — We’ll announce when it’s open for public beta testing and consumption soonTM. If you’re interested in deploying the product elsewhere, let us know! We’d love to see what other communities can do with a tool like this as well.

Let’s change the way we talk about failure


At Vaporware, Failure is in our blood. We consistently deliver the lean startup in practice with our clients, which includes a constant dose of failures. While most of these are small in a controlled environment, sometimes our public failings can be incredibly discouraging to our perfectionist human nature. But with Fail Fest this month, we hope to help change the discussion.

Elon Musk

We find great inspiration from incredible success stories. On the recent launch of Tesla’s Powerwall, we’re reminded of the public perception of innovative risks. But what happens when innovations fail? Musk’s other innovative company, SpaceX, has continued to fail spectacularly in the public eye.

But instead of hiding our failures and only displaying our highlight real, the conversation is slowly changing to one that accepts risk of failure and communicates our mistakes and learnings publicly.

Here at Vaporware, we believe in sharing and celebrating our high-risk endeavors, our capacity to fail, our failures themselves, and the lessons we learn from each experience. Without these experiences, entrepreneurs would be too afraid to move forward, try new things, and risk everything.

To bring this conversation locally and support the risky lives we live, Vaporware is helping bring the inaugural Fail Fest to Raleigh this month. Fail Fest is an event that captures this spirit and continues the conversation around failure. Don’t just share your failures, share the lessons you’ve learned, and come celebrate our collective capacities to continue onward and ever forward.

The Premier #Chat for The Triangle’s Startup Community

Here’s a new experiment — we’re excited to introduce you to a no-shills virtual co-working community for the entire Triangle. While we’re excited to see how it’ll evolve, here’s a short primer on how to get started.

Welcome to The Parkland

parklandWhat is it?

The Parkland is a Slack chat, a virtual-coworking space for the Triangle startup community. While we’ve briefly talked about it before, Slack is the best chat tool that’s catching fire everywhere. It’s an amazing platform that allows members to have an even communication field with one another. Slack communities are experiments for all sorts of topics that open up a single Slack domain to thousands of individuals and organizations.

A virtual co-working space?

Working at a small startup or on your own idea can be incredibly risky and challenging. Welcome to the family that helps you through those hump days of challenges and loneliness.

The triangle has plenty of co-working spaces to offer: HQ Raleigh, American Underground, Launch Chapel Hill, Bull City Coworking, The Frontier, are just a few. Unfortunately, these are all individual organizations that are competing with one another. Until they create a triangle-wide “access pass” (hint hint!), most shoestring entrepreneurs are stuck to one physical space. While we don’t offer beer, we have plenty of Memes and Cat GIFs for any mood. Now you can just login and be connected to your community, no matter what town or suburb they currently hail from. And have you tried driving I-40 during rush hour?

Note: We like competition, and we highly suggest you start a virtual community if The Parkland isn’t right for you. There’s plenty of other Slack and Meetup communities to check out too. Shout out to Triangle.rb’s Discourse Forum and Slack Chat!

Invite Only?

For now, The Parkland is invite only. Go ahead and join the waitlist. If someone who’s part of the growing network vouches for you, then you’ll get invited soon! Moving to the area soon? Share out a tweet and get enough referrals, and you’ll be bumped to the top of the list when you move here.


We’re still working out the kinks and details, but there’s a few things you should know up front:

  1. No shilling. We’re here as individuals supporting our own reputations, brands, and ideas. Talk about events around town, invite others, ask for help, but no advertising.
  2. Ask before you Private Message (PM). Don’t spam or annoy another member, and you’ll be ok.
  3. Anything else, we’ll see what happens. Just be nice to each other, just as you would in person.

We look forward to talking with you in The Parkland!


Learning from Failures and Vaporware’s First Finished Relationship

At Vaporware, we celebrate our capacity to fail. Whether it is the creative nature of development or our constant drive to improve, failure is a key part of our entrepreneurial culture. Learning from failures is one of the underlying principles of the Lean Startup — and a practice we perform with our clients through every phase of development. We’re so passionate about these principles that we also practice lean principles on our own business, including the importance of failure.

Sometimes these failures are simple mistakes, and other times they are quite large. It’s clear that without creativity and the common subsequent mistakes, we are not only losing to our competition, but doing ourselves and our clients a disservice. What separates our failure-based culture from devastation and defeat is our ability to learn from what we did wrong and continue forward with the experience and a professional mindset.

Recently, Vaporware finished our first relationship. Until now, we were incredibly proud of the fact that we continued to engage with all of our clients in some material form. We’ve located an underserved and mismanaged niche of low-funded startups, have developed services that provide immediate value and returns, and have built long-lasting relationships to create a thriving business. But as we strive to fill gaps creatively, we know that some experiments would fail. Unfortunately, the relationship did not end with our client taking large investment and building their own internal team, or a positive outcome. Fortunately, we can learn from this failed experiment and use the experience to improve all of our relationships and pass this knowledge onward to our clients and community.

Mutual Legal Contracts

Our first mistake was signing a non-mutual legal contract. While we heavily value new experiences, we downplayed the advice of our advisors and the industry’s standards, and entered into a relationship solely on equity and an open-ended “deferred fee” profit share — without clear expectations of return schedules. After the first two deliverables were made, it was clear that the basic mutual legalities and expectations were not in place, and we quickly realized we did not share a common culture.

This taught us the importance of legalese and definitions within our contracts. Firstly, everything we sign provides mutual protections and rights. From our basic Non-Disclosure Agreement (NDA) to our Master Services Agreement (MSA), all clauses are written with the clear intent of equality between Vaporware and our client. Secondly, our contracts are now written with the ability for either party to cleanly end the relationship with as little impact and loss as possible. While this is due in part to non-legal reasons, our legal platform provides both parties the safety and assurances to end the relationship professionally.

Starting Relationships

At one point, we experimented with building a business with sweat equity. Our primary full-time jobs allowed us to have flexibility with the projects we took on. Unfortunately, even with this flexibility, there are up front legal costs to set terms in place, since this is a non-standard relationship between two organizations. At the start of this particular relationship, we ended up frequently consulting with a legal advisor which, combined with lengthy negotiations and a lack of respectful conduct, ultimately started the relationship off as an adversarial one.

After this experience, we’ve created several strategies to start a long lasting relationship properly. With all of our contracts, we first enter into an understood “dating” period that tests all of the soft-skills needed to have a healthy relationship. This trial is the ideal replacement for a contracting firm’s sales process or clients’ wildly varying interview processes. We also start all new relationships with definitive goals, providing both sides the assurance that they can walk away with something for their investment. While this idealism seems perfect for a short term (single project) relationship, we find that it also creates long-term professional relationships.

Communication and Expectations

Even after the rocky start, we remained flexible and tried to meet our client’s goals and preferences to communication. Unfortunately, there was a loss of trust and respect in the relationship that could not be repaired by any amount of meetings or communication.

Because of this experience, we have since developed and solidified our preferred communication methods, and have concluded that we are ultimately willing to lose a client if we don’t have the necessary abilities to provide a valuable return on investment. Vaporware’s singular service is the ability to provide a return on investment to our clients — even if that means advising against our own profits and services.

In the compounded failures above, we ultimately were forced to fall back onto our misaligned legal contracts, the industry-standard vehicle that is all that remains for parties in a failing relationship.

The Dark Side of Contract Law

And this is where we truly lost the client. After a year and a half of a mutually beneficial relationship, our client decided to stop honoring our revenue share agreement. In a desire to avoid litigation procedures, we decided to suspend the client’s access from their application. However, and we want to be very clear on this, Vaporware did not steal any assets or information. In fact, despite numerous public accusations of criminal theft, Vaporware has had permitted access to the client’s servers and information since the start of the relationship, and that access remains active at the time of this blog post. We learned that our response was adversarial and pushed the client further away from reasonable settlement terms, instead of providing persuasion to uphold the contractual agreements.

Ultimately, this experience has led us to become more strict on our previous open and trusting nature. We can no longer provide payment flexibilities that gave us an advantage to our competitors. Instead, we take a play from our industry counterparts, and require our clients to meet stricter payment schedules. Additionally, we are now clear in all contracts that clients do not own the deliverables until they are fully paid. And while we may despise the very nature of contract law, we realize its importance in the business place and are striving to improve the mutual terms and protections of our contracts. Interested in helping? We’re looking to open-source our legal contracts to provide the most open and transparent conversation. Have experience with this? Contact us on twitter or in person to help out!

So what did we learn throughout these experiments and failures? First and foremost, investigate the consequences and consult experts and advisors before you take action. Secondly, we’ve learned to recognize failing relationships during a “dating” period and have developed techniques for ending a relationship after this trial. Lastly, even a legal failure won’t destroy you. Get out there, try new things, make new mistakes, continue to be creative, and disrupt markets!

Have failings of your own? Continue this conversation at Fail Fest, an event we’re helping bring to the Triangle that celebrates failures and the creative mindset. Stay on the lookout for more information.

Ongoing Communication, Development Valuation Part 3

To continue the conversation of valuing development, we’re going to explain how we use the expectations (covered in the first chapter) to help mitigate the risks (identified in the second chapter) with the crucial concept of ongoing communication. While this defines a process and mindset that is used throughout the relationship, communication practices are often not discussed or considered at the beginning of a relationship. Vaporware takes great pride in defining communication practices for a healthy relationship up front. If the communication expectations don’t match (or become misaligned) it can often cause rifts in a relationship that fall to a bitter end.

Is this marriage counseling?

Actually, a professional relationship is very similar to a marriage. Even in business, humans are very emotional and social beings. You don’t have to look farther than the largest capitalist entities, like the NY Stock Exchange or Apple Inc., to see how social and emotional our personal relationships to “corporate” entities are So how, like marriages, do we keep development relationships healthy? We communicate frequently, in great detail, and with respect.

Frequency and detail


In order to maintain a relationship, communication must be frequent. While frequency is a blurred spectrum, it’s often better to over communicate and risk annoyance than under communicate and miss vital information. Just as the Lean Startup defines customer communication as vital to a product’s success, we as developers desire to communicate frequently with our clients. The key is balance and healthy moderation, and with varying levels of detail.

Since different levels of communication come in different frequencies, it’s important to define which frequency receives what detail. If you’re constantly communicating the overall goal of the project, it could seem redundant and a disrespect of contributors’ time. Also, if big-picture topics are continuously brought up for discussion, it often can be perceived as indecisiveness and churn instead of clear execution. No matter how you like to communicate, it’s important to create a culture around a common understanding of these expectations and practices.

How Vaporware communicates

We use 4 different levels of communication at Vaporware to effectively communicate frequently. Starting with the rarest level of communication:

  1. Monthly Estimates and Reviews. This communication usually comes in the form of signed documents. These short (1 page) documents define how the last phase went and how we expect the next phase of work to happen – defined as bullet point goals and high-level time estimates. A signature on these documents shows that the topic was discussed and many individuals had input into the overall process. These documents and review sessions are the perfect time to discuss major pivots, reprioritization of work, and cost effectiveness. We often bring on or wrap up contributors here as well. Note that in our experience these documents don’t line up with the regular (weekly or monthly) invoices, as they review “sprints” instead of delineated time segments.
  2. Weekly Face-to-Face. These meetings are designed to keep people socially comfortable with the entire team of contributors. Since we’re social beings, we require some physical face-to-face contact. While these meetings are scheduled weekly, projects and schedules flex, so they realistically happen every 1-2 weeks, depending on the relationship health (length of relationship, trust, or other immediate issues). This 1-2 hour meeting is more about connecting on an emotional level with all the participants. Due to remote working, we’ve found that Google Hangouts is an acceptable solution for most meetings.
  3. As Needed (Daily) Task-Specific. Persistent communication over Asana and Google Drive allow each contributor to rope in another as-needed on individual task issues. This ‘unblocking’ exercise is persistent enough for the whole team to keep chatter to a minimum and on topic to particular issues. Asana also doubles as an overall project health list which allows stakeholders to view the status of projects during weekly face to face meetings. Pro tip: we also use the completed tasks to help recap what was done the previous month.
  4. Constant IM/Group Chatter. Up to the minute messages build culture and enhance happiness. Even though it’s easily muted, funny GIFs or slack “pings” are enough brain release to allow a remote or part time team to be effective. It’s vital that this is flexible for remote/part time workers, that documentation and larger discussions can fall back to persistent communication tools, and decisions are made with appropriate stakeholders when necessary.

How to Stick to Plans and Continue Shipping

When working in a collaborative (always connected) environment, it’s difficult to split your time between communication and productive work. While our experience in Corporate America definitely had too many meetings, we’ve found that constant communication heads off problems and road blockers before they cause cascading problems. We’re also strong believers that everyone is a contributor (more on our open allocation approach later).

In an always connected environment it’s important to develop a culture where interruptions aren’t constant, as it’s detrimental to other contributors productivity. For example, when using an always-on video chat tool like Sqwiggle, it’s effective to instate a policy like headphones mean do not disturb. Or with Slack, we reserve the right to use notifications to levels of responses. When everyone understands the consequences of their interruptions, communication becomes more concise. This is especially noticeable in a co-working environment, where open walls, loud environments, and headphones are standard.

While there are a few opponents to this physical-space approach, the underlying truth is that each team behaves and interacts differently. We’ve found that everyone in the same room needs to be working towards the same goals, or minimally, the same client.

bmlProbably less common, but more important, is the impact of frequent meetings from decision makers with extra time on their hands. Without a decisive project lead, it’s easy to constantly second-guess and revisit past assumptions or ideas. If these assumptions are too loose, then work can churn without forward progress in one direction.

For those familiar with the Lean Process: if the entire loop (including the measure and learn stages) is not completed, then the work that was performed can be considered waste.

Communication is (paid) work

A much longer discussion that we will have in another post, but communication is part of the work that we do, and part of what our clients pay for. I recently got a $500 bill for playing phone tag with a lawyer. Outrageous situations like this are avoided through our communication methods above, as we’re often able to communicate effectively in hand with high returns work (coding, designing, training).


The final piece to communicating effectively is in the way you treat others. We use key phrases like “How Might We” and “Not Now” to soften passionate topics. Humor and sarcasm, carefully placed and mirrored, often lighten the mood when things get tense.

People will forget what you said, people will forget what you did, but people will never forget how you made them feel.

How might we respect each other when communicating in all of these different environments? Each medium has a different feel and efficiency, but respect is vital to all methods and platforms of communication. It’s important to realize that everyone has an off day and makes mistakes. Things get passionate, ideas can be born or killed, and people can get hungry! Stay focused, stay positive, and be respectful.

Find your communication soulmates

At the end of the day, you’ve used processes to get things done. Maybe you can adapt to another, or are still searching for the best one yet, but you’ll be comfortable with at most two forms of communication. Be sure to evaluate this up front to make sure your development team communicates best through your languages. If not, be sure to estimate for longer communication sessions. Time, common understanding, and respect will assist in bridging the gap.

Want to see if we’re communication soulmates? Come meet us in person during my HQ Raleigh Office Hours or request a time to meet.

Now That’s an App

There are only 24 hours in a day and that never seems to be enough time to get everything done. Plus there are lots of articles telling us that we need to take breaks from technology and unplug. But while we are still plugged in, what are the best applications to help make the most of our time each day?

We have put together a list of our favorite applications. Being a tech startup, we use a lot of applications – way too many to list all of them here. Therefore, we are going to break our list up into shorter posts. The first part is some of our core applications that all of our team uses.

1. Asana

asana-logoAsana is used to plan and manage different tasks, almost a todo list on steroids.It helps us provide constant communication with our team, all contributors, and external clients. Best part? No more email.

2. Slack

Slack logoSlack is an application that is used for immediate communication between team members. We like the super simple interface, but fell in love with the integrations and countless endpoints. Pro tip: it integrates with all the other tools here.

3. Google Drive

Google_Drive_LogoGoogle Drive is the core store platform for the Google Apps for Business suite. It allows us to easily store, share, and collaborate on documents, spreadsheets, and diagrams. We use it to brainstorm different ideas together and store just about every aspect of our business. Google Drive helps to keep everyone on the same page at all times.

4. RelateIQ

RelateIQ_LogoRelateIQ is a relationship management system that pulls information from your e-mail, calendar, and other sources automatically. We use it because it allows for everyone on the team to help coordinate the complex playing field that is relationship building and lead generation. We were previously using Asana, but fell in love with the conversion system and automatic email/calendar integration. Oh and it reminds you about all the relationships you’re tracking.

5. Bufferbuffer

This application allows users to manage different social media accounts, including Twitter, Facebook, and LinkedIn. We use Buffer because it makes suggestions of content for users to post to their social media. We suggest picking it up because of the simplicity and scheduling aspects.

There are definitely more apps on our list, which we will share in later blog posts. In the meantime, we would love to hear some apps that you can’t live without. Reach out to us on twitter or in person to start a conversation.

Balancing Risks for Development Valuation

This week, we continue our ongoing conversation about the best way to value development projects. To recap, our 4 steps center around setting expectations, balancing risks, outcome analysis, and ongoing communication.

Hopefully at this point, we’re on the same page with some of our default expectations with every relationship we build. Have any expectations or questions we didn’t answer? Reach out to us to continue the conversation on twitter.

Even after expectations are set, there are still risks in every relationship. If you’ve been in a development relationship before, you will probably recognize a lot of this information. For the client, the risk evaluation can take a lot of different forms, usually with negative sleep-dampening questions:

What if the developers don’t understand the requirements?

What if the developers deliver late?

What if they never finish?

Will this fall in with my budget?

What if there are tons of bugs?

What if I lose my user’s information to a security hole?

What if we don’t jive well together?

All of these questions are completely valid and should be asked at the beginning and throughout the relationship. There’s also a lot of risk entering a new relationship on the developer’s end. Since we’ve done this so many times, we have a very specific set of pointed risk-evaluation questions we ask:

Will we be able to provide a strong ROI for this client?

Will the client be happy? Will we be happy?

Is there any risk of getting compensated for our work?

Other development teams may have a lot of risk-analysis questions they need answered before starting a new relationship, including:

Will our scope creep throughout the relationship?

How little can I work to make the most money?

When will this relationship end so I can move on to the next one?

Hopefully you’ll notice some themes here that we’ve already answered. Fortunately, most of these risks are offset by the expectations we set previously. For example, some developers look at scope creep as a risk, but we’ve already set the expectation that scope creep doesn’t exist in our world. If we weren’t as flexible and dynamic, many more risks would exist.

For those risks that we don’t address with expectations and an optimized process, we examine who is at risk and what tools we can use to offset those risks. Most of the time, it comes down to 3 points: project success, relationship happiness, and budget alignment.

Luckily, we’ve already come up with great answers for these 3 problems.

Will this project be successful?

Commonly, this is successful in a profitable sense, butthere are many other metrics of success like user growth that may matter. At Vaporware, we look at the earning potential to measure our potential impact, and relate that to a range of potential investment. We’ll discuss the details of this process next week, but it’s safe to say that this is a risk owned by the client and needs to be offset by Vaporware as much as possible.

Will both parties be happy?

This is a crucial analysis for new relationships, and is often like an interview. We don’t believe that the answer can be found until the relationship starts. While some people may believe that you can have a gut-feeling driven answer within the first few minutes, we strongly feel that people may have off days, come from toxic previous relationships, or just need a little communication and understanding.

We’ve been most successful at starting each relationship with a trial period (usually under 100 hours of cumulative work). This model allows the client to walk away from Vaporware without any loss, since the scope is for a functional piece of the project, standard deliverables are easily transferrable to a different development company, and the capital required is for only a portion of the overall project. For Vaporware, this gives us the ability to gracefully remove ourselves from a potentially long-term toxic relationship, as everyone understands that we’re testing the waters before we begin. This is a risk that’s owned and needs to be offset by both parties throughout the relationship, through ongoing communication (more on this later).

Will this project remain within budget?

Probably the one question that isn’t answered with dynamic payments and is how to stay on budget. Budgets, like scopes and plans, are arts of divination more than scientific methods. While Vaporware would rather ignore budgets, our clients with classic business training do not.

To overcome this risk, which is owned by the client and offset by Vaporware, we break projects down into small iterative pieces that can be budgeted as a run rate, sometimes referred to as burn rate or velocity. This way, clients know exactly when they can expect funding to run out, and watch overall progress as we move through each stage of development. This process enables the development of products the market will use, which is much more valuable than a predetermined budget.

During project valuation, it’s key to focus on the risks of keeping the returns high, relationship healthy, and budget on track. At Vaporware, we use financial tools such as trial periods, low upfront investment, and dynamic rates to offset these risks. We also keep our process and deliverables in line with finances to minimize risk in projection and assumptions. Without these tools or methods the risk and expectations can often become misaligned quickly and the project can stagnate.

I hope this has been a helpful introduction to some of the risks you may face during development relationships and our approach, including the tools and processes, that we employ to overcome these challenges. Check us out next week for details on how we can minimize risk through ongoing communication as we continue this series of valuing development. And as always, reach out to us on twitter or in person to continue the discussion.

Setting Expectations for Development Valuation

Last week I introduced vaporware’s process for valuing products we work on, a four step process to determining how much we charge for a product. You already know the outcome, that we charge a weekly rate depending on the effort for a project. But let’s get into the details. The first step to valuing development is setting expectations.

It may seem strange, but our relationship with our clients starts way before we meet. It starts before both parties even know that the other exists. Everyone has preconceived expectations of how relationships work, and consulting is no different.

Your first business relationship may have been a lemonade sale on your block corner, no matter if you were the one with the idea, the one that made the sign, the seller, or the one who stirred the juice. And that’s just the start! You’ve had years of experiences since then — and the expectations have been set, reset, and adjusted ever since.

A consulting agreement is just one approach to a flexible business relationship. One with strong expectations, inherent risks, ongoing communication, and incredible potential. Without proper joint effort to communicate and set expectations, the relationship will fail.

In vaporware’s technical line of work, we see several recurring themes of how these expectations start. From the casual coffee discussion of a cool idea to an official Request for Proposal document, there is no set answer on how to start a consulting relationship. That said, we think we’re a pretty stellar team and take pride in optimizing this process and so far, we’ve been incredibly successful.

Technologies, markets, and societies are constantly changing, and we constantly change with it. We can pretend to be experts of these things, and don’t get me wrong, we are very good and efficient at select pieces, but we’re even better at adapting. Instead of focusing on a long-term plan of what we’re going to do, we focus on how we’re going to do it. We start with determining how we are going to set expectations with our clients from the beginning:

  1. In a way, our proposal contains very little of the actual tasks that are going to be performed. Instead, we listen to our clients expectations, and share our own.
  2. There are tasks that we perform efficiently and tasks that take us a long time. We’re confident in what we do well and where we’ve had experience. If we can’t do it well and quickly, or we don’t know, we let you know and help you find a solution (or team) that can do it better.
  3. We always adapt to changes. There’s no such thing as scope creep. If things need reevaluation, we do it without hesitation.
  4. We ensure that we are clear about what we are working on…Advising, analyzing, architecting, branding, communicating, debating, documenting, designing, developing, evaluating, marketing, measuring, meeting, planning, prioritizing, testing, and thinking are all part of what we do.
  5. When we make mistakes, we own up to them. More importantly, we make sure to learn from our failures and fail faster next time.
  6. We question everything we do. Is this the right time to add this feature? Will our client see a return on this investment? Who will be happy with this change?
  7. We over communicate. Everyone can see the smallest of details of the entire picture at any time.
  8. We focus. One thing at a time per person. Done? Next.
  9. We back up our decisions with data. While experience and assumptions can take you far, it’s always measurable.

Ideally, with this early pre-relationship communication and continued communication, we are setting the stage to build a long-term, trusting, and respectful relationship. Without expectations and joint understanding, it simply won’t work.

But what does this have to do with payment and valuation? Hopefully you noticed a few key themes to our expectations. For example, scope creep does not exist in our world. It’s an outdated concept that means that the goals and payment have become misaligned. You’ll also notice that we question everything we do, all leading back to the fundamental question of “is there a return to this investment”. No matter the investment, no matter the business model, no matter the payment model — we make sure that we can provide a return on our client’s investment.

To that end, these expectations are the first core step of our dynamic pricing model. When work and payment are aligned, work gets done efficiently and effectively. Therefore, we ensure to set expectations correctly from our first interaction with our clients.

Now that the expectations are set, there’s still a long way to go. Check back next week to read how we demystify, balance, and offset the risks in the industry and dynamic payment valuation.

Postscript: These expectations do not setup the perfect process for every project, we don’t recommend going to the moon on the lean model, but they work incredibly well in custom web application development.

Development Valuation, or “Why Vaporware Uses Dynamic Pricing”

Being in the consulting business, we’re approached by clients in a variety of ways. But out of all the possible backgrounds and variations, one thing is static: Payment. Investment can come in all shapes and forms. While companies have traded in very unique return structures — including equity, education, connections, licenses, credits, and legal documents — the most successful and standard is cold hard cash. This societal blank check is the universally understood and demanded purveyor of progress.

Philosophical discussions aside, there’s plenty of long term discussion from thousands of experts on the Consultant-Client relationship and payment practices. You can even read summaries of summaries of discussions from all points of views. There’s even some wacky hybrid models that muddy the waters of pricing and payment.

Instead of being yet another text entry debating the pros and cons of fixed bids and hourly rates, we’re interested in demystifying our thought process. We will explain how we evaluate and price projects we work on. This process ultimately decides the clients we build relationships with.

We’ve distilled our pricing process to four core principles or steps:

  1. Setting Expectations
  2. Evaluating and Balancing Risks
  3. Ongoing Communication
  4. Outcome Estimation and Analysis

Each of the steps towards valuation is firmly dead center between a science and an art. So they each need more detailed discussion, which we will post in follow up entries. But to prevent suspense, and to set an expectation, we’ll share the outcome.

Ideally, we want to establish a long term relationship with each client that contains a combination of two models of payment.

  1. A weekly rate scaled by the number of people on the effort that week.
  2. A flexible maintenance contract at a fixed fee.

Spoiler alert, we’ve been operating under a much more flexible manner as we scale up our operations, which requires a flexible pricing model. Therefore, we currently operate on an hourly basis where each task is evaluated for inclusion, and we hold execution as the first and upmost priority.

Follow along to truly understand the thought process behind how we set our prices. If you want to read more about our company and what we do, visit our website. You can also sign up for my office hours, which I hold at HQ Raleigh.

How to Invest in Development

Is your development team an expense? Thinking about hiring developers or building an application? You’ve probably already considered how much money you’re willing to spend. You may have even looked at a few companies and gotten proposals to fit your budget. But where did your budget come from? Was it money on hand, how much of a loan you could get, or something else?

I’ve often been approached by companies that have a set budget and don’t want to exceed that dollar amount. Unfortunately, while this appears to mitigate risk by locking in the scope before the project starts, it’s directly creating risk by miss-aligning the solution from the investment.


When considering a project, I first take a step back and look at the core issues and goals behind the development. From there, I’m able to propose a lean approach to solving this problem at 3 different budget levels. I look at the target budget and determine: what do I feel I can do with 100% of the funds. Then I look at 2.6x the funds, what does the ideal solution look like at this level. Then, finally, I look at the far goal of 500% and let my imagination run wild.

While I never start on 5x the budget, I design the project in an iterative fashion that enables the eventual goals of a larger budget. Using this model, I’m able to successfully drive immediate value with prioritization on features at the static budget level and then expand outwards through combined success.

Throughout this process, it’s important for your development team to view your budget as an investment and not an expense. Does it really make financial sense to add this feature now? Will this feature provide a positive return? Anchor each development step against the returns. Does your development team factor your returns into their decisions?

Here at vaporware, we build returns through custom web-based applications. We never want to be an expense to our clients, so we’ll turn down jobs that we cannot provide a positive return on. If you want to read more about our company and what we do, visit our website. You can also sign up for our office hours to learn how to steer your development back on track.

Job Application Sweeping NC

Over 10 years ago Morris Gelblum was cleaning an office in Raleigh. When he was finished, Morris found a way to replace himself – he invented Sweeps – a company that matches college students with jobs posted by clients.

Won the 2013 Chapel Hill Business of the Year Award!

In the beginning, it was just Morris and his mother. Once Morris went to college, he discovered lots of college students were trying to find whatever work they could. To get the job-seekers together with the job offers, Morris started Sweeps with a website and e-mail.

Following the true Lean Startup model without realizing it, Morris simply “duct-taped” a lot of off the shelf software together to run the high demand of a job matching marketplace. Starting with a static website he coded himself, he added some manual forms, email and SMS functionality, and ZenDesk for managing the jobs as “tickets”. While this lasted several years, sustaining his business and optimizing his business model, he realized that he needed a customized software solution to scale to the next level.


“vaporware significantly reduced the time needed for our team to process jobs and applicants, allowing us to continue to grow.” – Morris Gelblum, Founder of Sweeps

Having grown up in Raleigh, Morris already had a tight knit group of contacts, but still was looking for a quality app development company. His previous efforts to internalize development with college students had proved too challenging. After connecting with HUB Raleigh (now HQ Raleigh), he got a recommendation to reach out to vaporware’s cofounder, Dan Moore.

After a brief introductory meeting and a requirements session, it was clear that vaporware and Sweeps were a great fit. Morris wanted people that were not only able to do the job, but also people that he would have fun working with.

Over the course of four months, vaporware developed four different iterations of the Sweeps application:
  1. The first iteration focused on the most critical piece of the Sweeps workflow; the process for posting a job. Removing an outdated User Experience for the simplistic process in place today, now customers can quickly and easily post a job from any device.
  2. The second iteration focused on the much needed external marketing content, including static informational pages, an external blog, and dynamic SEO landing pages specifically designed for specialized search targets. With this content in place, the system was launched as an minimum viable product. There was no real “system” yet — just a backend database that centralized the data before further improvements could be made.
  3. The sweeper management backend was introduced in the third iteration along with a customer portal. With the old systems, customers never had a login or any way to follow up on their jobs outside of email. Now they could see their entire order history with Sweeps all from the same system.
  4. Finally,  the last iteration had the capability to process payments, invoice the customer, and provide analytics for financial data all at the same time.
 While there’s still plenty of work to be done, Sweeps was now armed with an excellent application and groundwork to hire internal talent to continue development. While vaporware and Sweeps were sad to split ways, a smooth week of training and transition has enabled the app and continued development to prosper.
sweeper yeti

Hired a Sweeper to dress as a Yeti at the CED Tech Venture Conference for SnapYeti.

Since 2010, over 500 college students have used Sweeps to work over 3,000 jobs. And job posters on average give a 98% satisfaction rating to the Sweepers.Hundreds of hours have been donated and volunteered for an assortment of worthy causes.

Morris is very happy with the work that vaporware has done with Sweeps. “It all starts with quality… We are pleased with the results of our project with vaporware and learned and improved as a company as a result of the partnership.”


Bad UX Design – Can it Kill You?

Recently, we read an article about how bad design had killed a little girl. Three nurses had missed an alert that was not clear in the new software. Death is always sad, but when it could have been avoided it is downright heartbreaking. Everything that can be tested, should be tested. If someone had taken the time to test the UX of the hospital’s new software, a young life could have been spared.KONICA MINOLTA DIGITAL CAMERA

Technology is meant to make our jobs easier.However, chances are that none of those nurses would agree. So what went wrong in the story discussed in the article above? We may not know for sure, but there is a good possibility that no one tested the new software with the nurses that would be using it.

When creating something new, no matter what it is – software, a consumer product, etc – you should always have the end user in mind. However, thinking about the end user is not enough – you have to test what you are making every step of the way.

Our philosophy is release early and release often. This can be said another way – test early and test often. Each time we release an iteration of an app, we have already tested it with a preliminary user base. Upon release, we watch the end users closely to see if there are blaring problems, like the one mentioned above. We then put our learnings into prioritization for the next blowing-child-dandelion-790iteration of the application.

Typically our apps are not life threatening, but what if everyone treated UX as if it was a life or death situation? There would be a lot less bad UX in this world – and possibly it would save lives. Here’s to saving lives… one good UX at a time.

Startups + Costumes

The Triangle region in North Carolina is an up and coming area for startups (listed as one of eight emerging tech hubs by TransferWise). The creators of Startup and Play knew this to be true even before everyone else caught on.

The idea for Startup and Play came about over coffee one day in early 2012. The april_imageconversation was about how startups in Silicon Valley and New York City are so successful at product launches. It was decided that the success was due to the community surrounding those cities. The people in and around these cities get excited when there is a chance to try a beta app and are willing to provide feedback. This community will also actively promote the latest version of a product or something entirely new.

Why can’t there be this type of community in the Triangle area? Cue Startup and Play, a quarterly event aimed at creating a supportive community in the Triangle region. “We want to connect all of the cool, young companies directly with the community at large and with each other,” explains Will Hardison, a Co-Organizer of Startup and Play.

SUP Spooky is the fall social for Startup and Play, an event where people come1174967_429007557207626_1392729400_n together to celebrate entrepreneurship. Will describes the event as an “adult science fair for entrepreneurs.”

Here at vaporware, we are passionate about startups and getting involved in the local community. Therefore, we decided that the Startup and Play event would be a perfect fit for our first event sponsorship. The event is free, but registration is preferred. Get your ticket here.

Oh and did we mention there will be costumes? Come see what the team at vaporware dresses up as while networking with startups in the area. Now the only question is… what is your costume going to be?

What’s in a Name?

The irony of our name is lost to most people outside of the tech industry. You know that friend you have that knows how to talk the talk, but can’t walk the walk? That is what the term vaporware is known for in our industry. It is software that is promoted early and often, but then never released. We see this as the old vaporware mindset – making public promises before knowing if you can deliver on those promises.

Now you might be thinking – why decide to SONY DSCname your company after something with negative connotations like that? However, we see vaporware as something with great potential, but previous vaporware failed at the execution stage. From the entertainment industry’s Duke Nukem Forever to Enron’s Bandwidth Marketplace scandal, there are plenty of great ideas without proper execution. Vaporware is an outdated mindset that’s primed for refactoring.

We believe in quickly releasing features, which means walking instead of talking. However, we also believe in vetting iterations and features before releasing them. Each iteration is small and targeted, tested and manageable. Quickly releasing and testing a released feature with real users provides us with data and the ability to make informed decisions on what to develop, improve, or prioritize next.

blooming-flora-flower-398This new vaporware mindset is very public. We create a product and release it to production before the public waits on or even hears promises. This certainly doesn’t take the place of marketing – you still have to manage expectations. This new approach also does not excuse missed deadlines and/or erroneous customer expectations of progress.

By setting the public’s mindset that you’re releasing changes and always improving, you are being very transparent. Therefore, you will hit their expectations every time. Unfortunately, that’s true not for every customer, but fortunately we have a solution for this – customer segmentation. But that’s a post for another time.

Do you want to adopt the new vaporware mindset? Are you ready to stop talking and start walking? Then you have come to right place. Here at vaporware, we build custom web and mobile-based applications. If you want to read more about our company and what we do, visit our website. Or you can visit us at our office hours at HQ Raleigh (310 South Harrington Street) every other Thursday from 3 – 4 pm.

Website vs. Application

If you’re new to the web development industry or are looking to hire a contractor to develop a website for you, you might not quite understand the difference between web applications and websites. How are these different? Are there different technology skills required for each? Until I started working at vaporware, I didn’t quite understand the difference between the two. Not all websites are applications. But all web applications are websites. Confused yet? Let’s see if I can clear it up.

chair-media-old-1225A web application is something that is interactive. It is more than simply presenting information. An application allows a user to be involved, either by providing their own content or performing a transaction. Some examples include: Facebook, eBay, Twitter, and GitHub.

A web application is much more involved in the development. While front-end design, like User Experience (UX) and User Interface (UI) design and copy writing skills are involved, the bulk of the time is spent on functionality and features, which include backend server and/or frontend application development in technologies like PHP, Rails, and JavaScript. A web application is very comparable to software engineering. While you may find a self-taught HTML developer working on web applications, a deeper understanding of algorithms , systems, and software architecture is quickly required as applications grow in functionality or scale in use.

A website, on the other hand, is simply informational. It contains static content that is changed when the owner of the site decides. A user can navigate through the website, but cannot provide any input to its content. A website does not have much as much functionality behind it. Some examples include the NY Times, HQ Raleigh, and even our own portfolio.

A static website’s development often encompasses fewer technologies, with many sites building on existing platforms – like WordPress or Drupal – or even totally static sites where files are being edited on a file system – with raw HTML and CSS. There are a slew of technologies to speed this up and improve on the decades old system of static Internet webpages, like HAML, Sass, and CoffeeScript, and even new armies of web hosting technologies and platforms like cPanel, Shopify, Wix, GitHub, and Middleman, but the core concepts of website development are still the same as they were 10 years ago. Let’s display some content on a website.

One way of explaining the difference is that a web application is a website where users have the control. And let’s face it, in this day and age, users are demanding more control. So it shouldn’t be a surprise that they are getting what they want.console-controller-games-498-825x550

Today the majority of websites are a combination of the two. For example, Instagram merges a simple website with an application. When you first enter the site, your main choice is to simply log into the portion of Instagram that everyone is familiar with – an application. But at the bottom of the page are different static pages, like an about us page, that reads like an informational brochure – a website.

Here at vaporware, we build web- and mobile-based applications. This is what we find both exciting and challenging. Our services do include a little bit of website content work, but our passion is in creating custom applications from scratch. If you think that your company is in need of a custom application, don’t hesitate to contact us. Or you can visit one of our co-founders Dan Moore, who holds office hours at HQ Raleigh (310 S. Harrington Street) every Thursday from 3 pm to 4 pm.

Meet Our Latest Team Members

We are on a mission to test theories through lean measured applications in order to create extraordinary products. To help us to achieve this mission, we have found some great people. We want to introduce our new hires and talk about their past experiences.

Professional Photo-1We brought on Annie Pearce as our Brand Strategist. Annie recently got her masters in Integrated Marketing Communication from Northwestern University with a concentration in branding. Her last role was the marketing coordinator for H&R Block, where she created a grass roots campaign in Fayetteville, NC. Annie would describe herself as a creative marketer, who always has the brand in mind. In her spare time, she enjoys riding horses, reading, and taking photographs.

Aaron started with vaporware in late summer 2014. His customer facing experienceAhender VW headshot in sales, operations and project management roles made him an ideal fit to come in and help grow the business. He started his professional career in Web sales and marketing back in ’97 for local city guide startup CitySearch and spent time in jobs ranging from software project management to sales operations. Aaron would describe himself as someone who enjoys technology but never loses sight of “what’s in it for the customer.” When he is not out drumming up new business, he enjoys family time, skateboarding and attempting to play bass guitar.

As a company we care about hiring the right people – not just people that are qualified, but also people that fit with our company culture. We are excited to bring Annie and Aaron onto our team. And we look forward to having other self-starters who are passionate about our mission.

From the Mountains of North Carolina

Just like millions of people do everyday, Justin Beard uploaded some photos to Facebook (of a place that he was renting). The landlord happened to see them and offered him Ski tickets and free dinner in exchange for the use of his photos on the landlord’s website. This was Justin’s “a-ha” moment. There are plenty of companies doing photo contests, but not a main hub for companies and customers alike to go to create and enter these contests. The idea for SnapYeti was born.


Voted 1st of 8 breakout mobile startups by NCTA.

Now that Justin had the idea, he wanted to bring it to life. But without the skills to build an application, he had to find someone else to do it for him. And so the search began… Before finding vaporware, Justin had looked far and wide for a solution to his application needs. He had gotten quotes both from companies in the US and internationally. “I looked everywhere… I was tired of it all.”


Won the NC IDEA grant!

In May 2013, Justin ran into Dan and Jeff at HUB Raleigh (now HQ). Justin was prepared with mockups and project specs. So they had an informal meeting then and there. Right away, Justin could tell that Dan and Jeff would be able to create what he was looking for. After some conversations and Justin doing his due diligence (checking into vaporware’s previous clients and work), SnapYeti became a vaporware client by June 2013.


Over 120 business have created Snapfests!

In three months, vaporware completed three iterations of the SnapYeti application. Each iteration was tested with beta-users. The first version of the application was a photo contest where only the administrator could create contests, but others could log in via Facebook or e-mail to upload or admire the photos. The next stage was allowing anyone to create contests and adding in a feature that shares to Facebook anytime that you admire a photo (as suggested by some of the beta-testers). The last iteration before launch was a mobile-responsiveness review and update to the core application that prepared the platform for the onslaught of more than 50% of its users being mobile.


Accepted into the accelerator program in August 2014!

In September 2013 SnapYeti was launched! In the first month, the application had 1,200 users. Today that number has grown to over 33,000!

Justin could not be happier with the results. “We could not be where we are today without vaporware making our technology platform extremely easy to use and scalable… They are hands down the best team I have ever worked with.”

The (CSS) Journey is Better than the Destination

Whether you’re a developer or designer, one unique property of the technology industry is our access to master’s thoughts. Today, we’re treated to not only the outcome, but the entire thought process behind @fat‘s CSS evolution process that was once internal to his head and Medium. While we have this great style guide for CSS as a product (included below) we also have the process and evolution, including his past pitfalls and future challenges to consume and build upon. We highly recommend the entire read, even if you only have 20 minutes.

Road to vaporware

Have you ever sat with a couple of your friends talking about ideas and how you can make things better, then have the realization, “We can do this!” That was the start for vaporware. After that conversation, it took four of us only one week to start the company.

dan-largeAs part of the first vaporware meeting, I bought everyone Eric Reis’ book “The Lean Startup” and told them this was our bible. We started using it on our own products, launching Drafts to early adopters right away. Even when our company started to change, we continued to use the lean process.

We started vaporware as a Managed Cloud Hosting Provider. It wasn’t tough to chose our name. We wanted a challenge. Everyone in our industry knows what vaporware means – we wanted to defy that.

In four months, we came up with a prototype for a lean cloud model. But once we got to the funding stage, we realized this was not the arena we wanted to be in. We sat down and had a conversation about where to go from there.

jeff_gravatarAfter that conversation, two of us emerged. Both Jeff and I have software development expertise. We started working on some projects internally that excited us. But we were beat to market by another company on one of our ideas and ultimately decided not to pursue it. And the other idea is on our back burner. We still have future plans to create a tool for our clients, to streamline our work with them.

In April 2013, I reached out to Brooks Bell to talk to her about doing business as a startup in Raleigh. She suggested that I get involved with HUB Raleigh (now HQ). We joined and met Justin Beard, the Genius and Founder behind SnapYeti.

Justin had a great idea for a social photo marketplace where companies created contests, users submitted and ranked images, and the highest rankings won prizes. (Watch out for our next blog post where will talk about how this partnership grew!) With an extremely small budget and 200 hours of work, we launched a prototype rails application within 3 months. And just recently, SnapYeti was accepted into The Startup Factory’s accelerator program.

After working on SnapYeti, we discovered that we love this line of work and the passion that comes from working with startups. Our expertise lies in creating applications from scratch. I specialize in product, APIs, and algorithms. Jeff specializes on the user experience (UI/UX) and SQL optimization.

If you think that your company is in need of a custom application, don’t hesitate to contact us ( Or you can visit me during my office hours at HQ Raleigh (310 South Harrington Street) every Thursday (except next Thursday, September 4th) from 3 pm to 4 pm.