Agile is more than just a fancy buzz word thrown around to make software development sound cool. As a startup founder, it’s important to understand the intention of the Agile Methodology to fully realize the value. The good news is, this may be easier to understand and apply than you think! In fact, you are probably already applying agile concepts without even knowing.

Do you create cross-functional teams to develop your products? Agile!

Do you meet regularly as a group to discuss progress? Agile!

Do you gather feedback from end-users early and adjust design? Agile!

The Origin of Agile

Almost two decades ago, a group of software developers frustrated with the ineffectiveness and inefficiencies of traditional development methods got together for a weekend to define a new framework. Their intent was to establish a framework that satisfies customer needs while:

• Reducing the burden of documentation
• Increasing collaboration and the value placed on people
• Establishing a continuous feedback loop that allows for iterative development of applications

These thinkers understood that if you build a team of highly motivated individuals, deliver quality software frequently, gather user feedback sooner, and eliminate waste from re-designs or downtime, your chances of success will increase. As a result of the meeting, these concepts were documented through twelve principles published in under 200 words and titled “The Agile Manifesto.”

Realizing Success with the Agile Methodology

“Ultimately, the goal of modern software development is to reduce the size and increase the frequency of installs or releases while improving the overall quality of the product delivered to the customer.”

The authors of the Agile Manifesto provided experience-based recommendations on how a company can be more successful with their software development. Since being published, agile concepts are taught in schools and implemented by companies large and small around the globe.

Many companies apply a blended approach of traditional and agile methodologies for software development. On the flip side, some new methods based on agile concepts have branched out. There have also been attempts to further simplify the concepts of agile, efforts to expand the scope beyond software development, and in some instances, attempts to create more prescribed approaches based on the original principles.

Ultimately, the goal of modern software developments to reduce the size and increase the frequency of installs or releases while improving the overall quality of the product delivered to the customer. While agile isn’t one-size-fits-all, startup founders who understand the principles are able to scale agile development principles to fit their business needs and collaborate more effectively with developers.

Putting Agile into Action

Developing software using agile methods involves teams of designers, developers, product owners, and other specialists. Requirements for a new or modified product feature are defined and developers work with their product owners to determine the criteria for acceptable completion of each. Once a feature is developed, testing against the acceptance criteria is performed, changes are made as needed, and finally, the feature is launched into production based on scheduled release dates.

At Code Hangar, agile methods are applied from ideation to implementation leveraging agile-based 2-week sprints. These sprints effectively allow for quick changes to design based on customer feedback. At the beginning of a project, we work with our clients to set expectations and develop a roadmap that is broken down into two-week sprints.

During each sprint, we meet with our clients to review what was completed in the previous sprint and discuss intentions for the upcoming release. Over the course of a sprint, our clients can expect to review progress, verify intentions, and discuss opportunities to adjust strategy based on customer feedback, identified risks, or potential delays. To learn more about sprints read our blog post titled “Why Sprints are Key to Successful App Development.”

Startup founders are using agile methods every day to create successful products. Knowledge of the Agile Methodology makes it easier for developers to turn ideas into reality. As companies have become more comfortable with the concepts and expectations of agile methods, the focus has shifted on reducing the size of a product feature being developed while eliminating release schedules and allowing for real-time delivery.

Whether you are just getting started or you’ve worked through several releases, now is as good a time as ever to review your processes and find new ways to apply the agile principles. We’d love to talk to you about how we can partner with your startup. Feel free to contact us if you want to learn more about our approach to application development or the benefits of our services.

The Vulcans had it right with their saying “infinite diversity in infinite combination.” Because when you don’t limit your scope of potential combinations, the possibilities are endless.

To be the best at what we do, we want to build a company that values diversity. While discussing diversity can too often seem like a superficial corporate initiative, it’s very significant to us.

At Code Hanger, we believe it is important to be intentional about surrounding ourselves with diverse groups of people. It’s not just going to happen on it’s own.

Most importantly, the biggest reason we think it’s important to be inclusive and foster diversity, is it’s just the right thing to do. Everyone has a right to exist in this world with the same opportunities and freedoms as the next person regardless of their gender, race, sexual orientation, or religion. This is the world we believe in and want to live in, so it’s only natural we would do what we can to foster that within our own company.

It is reasonable to feel most attracted to like-minded people who look like us, and it’s difficult not to build a self-reinforcing echo chamber because of that tendency. To combat that, we know we have to intentionally surround ourselves with people we don’t automatically understand or relate to. Otherwise you just get yes men and stagnant traditional processes.

Intentionally building a company that values diversity takes concerted effort, but the benefits are worth it — and not just for us, but for our team, our clients, and for society at large. Here are just some of the most impactful ways we know that diversity benefits our company’s performance directly.

Diversity Fosters Creativity and Innovation

Teams that have a more diverse staff are measurably more creative and innovative. Homogeneous groups will tend to have overly similar points of view. Their spheres of knowledge will overlap, backgrounds and skill sets will be comparable which can lead to the same strength or weaknesses in a team. They can also share unconscious biases or normative presumptions of how the world works. Therefore, they will often reach similar conclusions.

In contrast, when there is a significant diversity of perspectives based on different lived experiences, teams can find a wider array of solutions to the problems they’re trying to solve.

This is because more perspectives lead to more ideas. When there are more ideas shared collectively, people are better able to tap into more innovative and creative approaches to problem solving as they connect new and interesting possibilities.

Exposure to only limited experiences and points of view can stifle ideas and stultify business processes — and, by extension, creativity — in employees over time. Of course it’s important to continually get stronger at various core skills or specialized areas of expertise. However, it’s also important to continually take in new ideas and ways of thinking and apply them in ways that can help us grow as professionals.

When there are a lot of varied perspectives on our team, we become better able to collectively see problems differently. We can mix and remix solutions proposed by different people and find ways to better serve more diverse customer bases. We collectively share our ideas with each other. This allows us to more efficiently pool them together in order to find creative solutions that hadn’t previously occurred to us.

Diversity Builds Company Confidence with Engaged Employees

We know that we all will do better collectively if we have a team of engaged individuals who work together towards our goals. That’s why we value transparency and openness at Code Hangar. However, in order to foster that transparency, we need to create a team where everyone feels like they have a voice.

One of the most important reasons for keeping an eye on fostering diversity on our team is to avoid echo chamber traps. When a company builds a culture of limited perspectives, it creates a space conducive for everyone to uncritically agree and validate each other, perpetuating status quo practices whether they’re as effective as they could be or not.

Yes, we all love that awesome feeling you get when you are validated. However, it doesn’t always lead to superior quality work. We want to offer the best solutions to our clients.

When everyone who surrounds you isn’t able to offer any significantly different perspectives because theirs are mostly the same as yours, it’s easy to assume that how things have traditionally or recently been done in the past must remain correct or adequately optimal. However, an echo chamber isn’t representative of the entirety of the real world or concerning any potential customer-base. Serious problems can too often result if incorrect assumptions are made in either business or personal relationships.

Disagreements aren’t a bad thing!

Differences are important and often offer crucial perspectives regarding more diverse ways to see and engage with the world. When we automatically choose to reject or exclude opposing points of view, this leads to ignorantly presumptuous and limited thinking.

Instead, we want our team members to feel confident that their points of view are valuable to the success of the team. When employees know their perspectives will be listened to and considered seriously, even if they’re not always agreed with. This way, they’ll feel much more able to be open and share potentially innovative ideas freely.

Diversity Attracts Better Talent and Builds a Better Team

It’s really important for us to build a company that values the people who work for it. However, we also want to attract the best talent we can in order to serve our customers as efficiently and effectively as possible. However, these two ideas are connected rather than at odds.

Hiring a new team member gives us the opportunity to bring a new voice onto the team. These new perspectives help remind us that there is more going on in the world than just what we see in our everyday bubbles.

A big benefit of diversity that affects Code Hangar directly right now is our team’s diversity of location. We have team members scattered all over the country and even the world. Because of this, we are able to see outside of our Central Florida and even America-centric bubble to provide a more global perspective to the work we do, and even our personal lives.

What these varied perspectives help remind us is that social issues don’t play out identically everywhere in the world. Costs of living, culture and customs, and even values vary. These perspectives are valuable and can strengthen our team when a new member joins.

New perspectives can push teams to grow. When we face differences in perspectives, we can become more self aware of our own behavior and how it might affect others. This allows everyone to build better relationships by becoming more empathetic regarding differences between us as well as overarching similarities across cultures.

This also means we always remain open to finding the best talent anywhere — so we don’t limit our searches due to misguided preconceived notions regarding who a new hire needs to be like.

Diversity Solves problems Faster

People with different backgrounds bring more varied ideas to the table. When a diverse staff is in a meeting trying to problem-solve solutions, different perspectives help more efficiently spot flaws with proposed solutions to problems or superior alternative approaches we might not have initially anticipated.

This can include big and obvious things like a new feature idea that helps significantly improve a product. But it can also include more subtle things like having better understandings of the current market or how users might more ideally interact with a piece of technology in ways that might have otherwise gone unnoticed and underserved.

Homogeneous ideas lead to greater possibilities of missing more ideal solutions a problem. In reality, it’s not just that diverse teams are preferable because of an ethic of diversity; they’re preferable because they’re more likely to come up with superior solutions to problems at hand more quickly.

This means that we can build stronger apps faster. Otherwise, a lot of extra time could be wasted releasing limited or presumptuous ideas to the market and waiting on feedback from a diverse group of users. Instead, a more diverse staff can better catch flaws or defects well before significantly more time would need to be invested in building features that ultimately don’t work as well as they should and finding out via customer feedback.

A Diverse Team can Avoid Mistakes Based on Lack of Perspective

A cautionary tale in this regard that always sticks out to us is the mistake and PR nightmare that HealthKit (produced by Apple) caused because they lacked adequate diversity on their team. While the HealthKit allowed users the ability to track health indicators like steps, height, and blood-alcohol content, it lacked a basic menstruation tracker. This missing feature in the design of their product left out a crucial health indicator for a huge percentage of the population, which meant that they weren’t being offered a product by Apple that actually met their needs as promised.

And the biggest reason for this hugely problematic oversight in design? It was because there wasn’t adequate representation of a diversity of people in the design phase of the project.

An important lesson can be learned from Apple’s public mistake where they lost out on potential customers due to such a glaringly missing product feature. While the mistake might seem obvious to some, it wasn’t when they designed the product. However, if Apple had better prioritized putting together a diverse design team, they wouldn’t have been in danger of producing a one-sided solution.

A Wider Customer Base is Serviced Better by Diverse Teams

We believe diversity is important: not just at Code Hangar, but in all of society, when it comes to better problem solving. It’s important to not deny the needs and viewpoints of marginalized people — or presume that the only important or most profitable priority is to serve what might be considered the normative point of view.

To us, it’s not good to build systems around edge cases or situations that don’t occur often. On a homogenous team, marginalized voices could be seen as these edge cases that don’t need to be addressed. Instead, on a diverse, open team, their points of view are valued as part of a broader and more pluralistically representative normative point of view where they also need to be centered.

It Makes the Most Business Sense to Build a Diverse Company

The simplest and most straightforward answer regarding why diversity is valued at Code Hangar we saved for last. Honestly, it makes the most financial sense to value and build a diverse team.

We highlighted this earlier by pointing out how time can be saved by avoiding onerous and costly mistakes — and how a stronger app can be built faster by having a wider variety of perspectives to offer creativity and innovation.

However, we also know that more diverse companies have tended to be more profitable, overall — especially those companies which have a lot of diversity among directors and other high level management positions.

With more diverse ways to get the job done considered, discovered, and implemented when warranted, we can learn how to be much more efficient in the work that we do. We can more easily access a wider pool of the best and brightest ideas and apply them to our company’s practices and technology stacks. We can design superior workflows and iterate toward all the best increasingly efficient techniques and approaches we can find.

That means we’re able to be more flexible, more effective, and to respond better and faster than the competition. This is a straightforward win for everyone: including our customers, our employees, and Code Hangar as a company.

Want to get started working with a software team that values diversity and transparency in order to build stronger products for you that can reach and appeal to a wider base of potential customers? Check out our 8-week MVP program or get a custom quote for a project today!

One of the most important aspects of maximally effective app development is to release software features early and often. No matter what stage of app development you’re in, the sooner you can get essential feedback from your target users, the stronger the product you will ultimately build.

Releasing early and often is an iterative process wherein repeated cycles of agile operations work toward continuously refining and enhancing the user's experience using your software. With each iteration, development moves forward by achieving incremental benchmark goals within each cycle. We accomplish this at Code Hangar through sprints that typically last two weeks .

This process is best facilitated by regular feedback at each stage of development, even beginning stages when you may only have a prototype. We encourage start-ups to test every assumption with potential customers at every stage of the process — even if, at first, that might be through initial feedback from founders, potential investors, or friends and family.

The goal is to create a feedback loop that allows you to test whether your assumptions are actually on target. If they are not, your company can more easily pivot and adjust priorities as quickly as possible, or as soon as the next sprint begins. This allows the development process to be ongoing without wasting time building and rebuilding features which ultimately costs a lot more money and doesn’t serve your customers' needs as well.

Release Your MVP Quickly

Once you’re ready to build your app, it’s critically important to get a Minimum Viable Product into the hands of your customers as quickly as possible. At Code Hangar, we specialize in rapid design and development of version zero software applications for lean tech startups. We accomplish this through iterative sprint cycles of agile development — and our most popular specialty is our 8-Week MVP package.

In just eight weeks, we produce a release-ready full-stack application with common features like user accounts and profile management, plus one or two high-impact customized user workflows. Within eight weeks, the product is ready to be used to gather initial feedback from users.

We believe that releasing an app as an MVP at the earliest possible iteration is crucially important. Once feedback is received from actual users, augmented feature updates and timely bug fixes can be much more efficiently focused.

This process allows the development team to more effectively leverage users’ feedback to determine what work most urgently needs to be done in the next sprint. We know from experience that this ultimately builds a better app at lower costs than more traditional methods.

Regular release schedules establish impressive customer service expectations early and build authority with users.

App development is never completely finished because applications are not static. Apps are usually seen as tools to help users accomplish something in a new or more effective way. You want users to happily return to your app over and over again. When you release early in the development process, you’re able to gain valuable feedback from your most active users, many of whom are savvy power users for your app — and can help you better understand the long term needs your app can solve for them.

When you’re able to create new features and fix the most pressing problems identified by your most vocal customers in a timely manner, they’ll trust that they will be able to enjoy using your app for years to come.

The efficiency of this process is a crucial customer service benchmark. Because your users will see that you’re continually working to refine and enhance your product and taking their feedback into consideration to make something that is tailored for them, you will better earn and keep their trust and confidence.

One of the most important things you can do as a start-up is to quickly build this sort of relationship with your user base. To do this, you need to rapidly deliver targeted solutions based on the most pressing needs or wishes they express to you. Then, continue listening to them to provide even greater enhancements and build an app comprehensively designed with their feedback and experiences in mind. This creates efficiently constructive feedback loops that will help much more rapidly build a network of customers who love your app and enthusiastically recommend it to others.

Releasing updates early and often allows you to create positive feedback loops that consistently communicate to your customers that you’re actively listening and rapidly responding to their needs and preferences. The best way to do this is by releasing the highest impact features as quickly as possible. By doing this, you show your most loyal customers that you value them. In turn, they’ll continue to use and share your app at higher rates — becoming your most effective and authentic cheerleaders and spokespeople.

In conclusion, we hope we’ve helped you understand why testing your assumptions with real market feedback early and often in the development process is so important. Ultimately, being able to test your assumptions with real users earlier will allow you to build a stronger product in less time, and with a smaller budget.

If you’re ready to get your app released to market as quickly as possible, check out our 8-week MVP service! Or we can help you plan a customized development package to fit your needs.

Startups need to stay competitive and use their limited resources in smart ways. We believe that is best accomplished through an agile framework that takes an iterative approach and develops software incrementally. Because the software development process is an ongoing one, sprint cycles create that agile framework that allows teams to pivot much more easily in order to respond to a number of changing priorities.

However, a sprint based pricing model versus a project based price for development can be confusing if you are not familiar with it. Project based pricing may seem more straightforward because you can define all the software development features you will recieve for a fixed price. At the end of the project, you would ideally receive exactly what you envisioned and paid for.

Project based prices are easy to understand. However, they can be too rigid for maximally efficient and agile modern software development. Luckily, sprint cycles can accomodate the needs of modern ongoing software development.

Why Sprint Cycles are a better investment.

At Code Hangar, we encourage our clients to release value-creating software as early and as often as possible. This approach is based on Lean Startup Methodologies and what has worked best with our clients. This way, stakeholders and developers can test their assumptions about the app much earlier, get feedback from users, and pivot or scrap misguided priorities if the original plan doesn’t quite ideally suit the needs of the users it serves in actual practice.

This degree of flexibility and adaptability isn’t possible with longer-timeline traditional “waterfall” project scopes and releases. With project large scopes, delays or changing requirements at any stage of the process can compound and impact subsequent stages. This can lead to extended release dates and longer periods without market feedback.

More importantly, financial resources could be wasted on building features that customers never actually use.

Instead, with sprints, agile teams are able to respond to market needs quickly and create a service model that allows their most valuable users to feel heard. In turn, this interaction facilitates the development of an overall better product more quickly and at a lower cost than would be possible with traditional project based approach.

What is a 'sprint'?

According to Scrum.org, a sprint is:

“A time-box of one month or less during which a ‘Done,’ useable, and potentially releasable product increment is created. Sprints have consistent durations during a development effort. A new sprint starts immediately after an old sprint.”

At Code Hangar, we have found a two week sprint cycle to be ideal for most projects. This ensures that app users get a steady stream of new features, updates, and bug fixes.

We determine what work will be done and delivered by the end of the sprint before we start the cycle. In order to provide the most value, the requested features and enhancements are broken down and prioritized into one of four categories:

• Priority 1: High Impact, low effort investment
• Priority 2: High Impact, high effot investment
• Priority 3: Low impact, low effort investment
• Priority 4: Low impact, high effort investment

Large workflows and features can be planned out over multiple sprint cycles

while simultaneously working to deliver smaller features at the end of every sprint. This way, even if a larger feature takes three or four sprints to accomplish, we never let too much time pass before a value-creating feature or enhancement is released to users.

For clients who only have a prototype and have no software yet, we plan out multiple sprint cycles that will build a Minimum Viable Product (MVP) as quickly as possible, usually within 8-weeks. This way, founders can begin to test the market regarding assumptions they made with the initial design and build a user base ASAP.

We invite founders, or whoever is closest to customers, to participate in our regular sprint reviews and planning meetings as they will offer valuable perspectives. In the early stages of a startup, founders are often closest to customers and can offer feedback at those stages. As the customer base grows, we will also address that feedback in sprint reviews.

Why We Sprint at Code Hangar.

Sprints are best suited for ongoing development where it is difficult or unfavorable to define what “done” looks like. With a regular release schedule, feedback can be gathered from users and new design features can easily be scheduled into future sprints to respond to arising needs. This also allows much greater flexibility to pivot toward unexpected priorities if the market demands it.

In contrast, longer project scopes delay releasing new or updated features to customers. This also delays gathering invaluable customer feedback to inform ongoing development.

However, in sprint-based development, each sprint represents the smallest scope that can viably be released to customers in a short period of time. This ensures development is closely aligned with customer needs.

Purpose of Sprint Review & Planning

It’s important for sprint cycles to include review and planning meetings with the development team and founders or stakeholders. Meetings will review design and development deliverables from the most recent sprint. With feedback discussed in the meeting, adjustments to deliverables in the upcoming sprint can be made.

As features are delivered to customers, their feedback will often be surprising, and founders may learn things they didn’t originally anticipate. In sprint planning meetings, we’re able to constructively discuss what we have learned from user feedback. That information will either confirm that our plan for the next sprint is on target. Or we will adjust if priorities have changed.

How Sprint Review and Planning Process Works at Code Hangar

Sprint Review and Planning is typically a one hour meeting that happens at the end of one sprint and prior to the beginning of the next sprint. These meetings are not only valuable for sprint cycle review, but it also keeps communication open between us and the start-ups we work with. With a sprint model, stakeholders are guaranteed to have an in depth discussion about ongoing app development worked into their pricing structure about every two weeks.

We hope this gives you a better understanding about the benefits of our agile model for app development using sprint cycles. We work exclusively in this model because we believe that it provides the best value to our customers’ long term investment needs.

Plus, unlike traditional project scope pricing that requires large deposits (sometimes 50% of the total cost) up front before work can begin, sprint pricing is billed to clients after every sprint. This way, the customer actually pays for both work performed and development that is maximally useful to their users and responsively prioritized.

Are you ready to dive into your first sprint with us? Contact us about our eight-week to MVP or custom development packages. We’d love to talk to you about how we can partner with your startup.

A software prototype is a necessity for anyone who is in the early stages of an app development process. It will help you understand your own product better which will allow you to communicate your vision more effectively to software developers, future users, and even potential investors. In this blog, we’ll break down the five steps needed to take your idea for an app to a clickable digital prototype.

1. Define the App’s Users

The first step in early app development work is to define the core users of the app. While you might have a long term vision to help a large general audience, at first, you need to define who the early users are and why they need your app. It’s also important to think about how they’ll find out about your app and the steps they’ll take to use it.

Even large companies like Facebook and Amazon started with a small defined goal. Facebook wanted to create an online college database of student profiles while Amazon created a digital bookstore. They were only able to grow and expand to a larger audience because they first designed a product for a narrowly defined group. Only later did they expand their target users.

Just like those big companies solved a narrowly defined problem at first, you also need to define a specific problem your app will solve for the core users you want to serve.

There are two categories of users your app might support: either providers or consumers. A provider is someone who offers a product or service through your app. A consumer is someone who uses the tools or services or buys product from the app. Some apps will connect providers and consumers to each other. However, your app might only be a tool for one type or the other.

However, some apps might need to be a tool to both types of users, even from the beginning. If that’s the case, both types of users will have different goals and needs the app will need to address.

For example, Etsy has both providers and consumers. Consumers have certain screens they can search for and purchase products. Providers screens will include ways to post products and interact with customer questions.

2. Define the Goal for the App’s Users

Once you know who the users are, define the goal they want to achieve with your app. This will be the problem they want your app to solve for them.

If you have multiple users, each user type might have a different goal. In the Etsy example above, the consumer’s goal is to buy a one of a kind handmade piece. While the provider’s want to find an audience who will buy their artisan wares.

The app is the tool to help the users meet their goal. In the next step you will map out the steps to make that possible with your app.

3. Identify how the user flows through your app

Now that you have defined your users and their goals, you will need to map out how your app will achieve them. To do that, you will need to write out each step the user takes through your app until they reach their ultimate goal.

To think about each step more concretely, think about each screen a user will navigate through. Screens depict the actual visual front-end part of your app. However, each screen will have functional aspects, like buttons and menus, that help navigate each user to their goal.

The visual design of the screens is not important in this stage, instead it’s more important to design the process the user will take and what the function of each screen will serve. Typical screens will include login, profile, or checkout.

Here's an example of Code Hangar's profile screen on Instagram

The simplest way to write out this process is to create a bullet list of screens the app needs to achieve the user’s goal. If there are multiple users types, you will need to consider what screens each type of user will need and how they are connected to each other.

As an example, if you made a list of a popular app like Instagram, the home screen for your bulleted list might look like this.

• Home screen
• Direct messaging button
• Add to your story button
• Instagram stories from other users
• Feed of regular posts from other users
• Home button
• Search button
• Add new photo or video button
• Notifications button
• Profile Button

Each subcategory in the above list will lead to a new screen that will have its own elements to define also in it’s own bulleted list. The next step will help you define how each screen is connected to each other.

4. Create a product map with relevant screens you will need to make

After you create your bulleted lists, it’s time to create a product map or a wireflow. This is now the time to start connecting visual aspects with the functionality of each screen.

A wireflow connects the visual aspects of each screen with how they are all connected within the app. At the end of this process, the wireflow will be your visual blueprint that you will eventually hire a software developer to build.

Use your bulleted list from the previous step to help lay out the visuals of each screen. Remember elements that will be on every page such as menu bar and logo. Next, identify each functional aspect of the screen that will lead someone to another screen. Then draw out how you imagine that screen will look. Connect screens with arrows to show how a user will go from one screen to the next one.

Below is a drawing of a wire frame from a previous project we did for Florida's Pycon Conference.

You can see how both the visual aspects of each screen is shown along with where each button will lead the user and what they can do. It can easily help you visualize what a finished paper prototype would look like. Of course, you could create this on a computer too if you would rather use design software.

Wireflows will most likely include some decision trees too that might give users multiple results depending on the user’s action. For example, on a login screen, if the user types in the wrong information, instead of taking the user to their home screen, it will take them to a forgotten password screen.

Remember, at this stage the paper prototype doesn’t need to be perfect. In fact, it doesn’t even have to look that pretty! With an ugly prototype, you can reach out to developers who can help you realize your vision in a working app. The next step in the process will allow you to add design elements to your wireflow in order to build a more visually appealing prototype.

5. Design a graphic representation of the app

The final step in your prototyping process is to create a clickable graphic representation of your app. This will allow others see what your finished product will eventually look like.

The simplest way to make a clickable prototype is to create a powerpoint slide for each screen from your paper prototype. Use internal links to connect slides to give the impression of what it will be like to use the eventual app.

A few other prototyping tools we recommend and require no coding are Sketchapp, Invisionapp, and Bubble. With each of these tools, you can build various slides that will have some design elements and clickable buttons to give the prototype some frontend functionality.

Going the extra step to create a clickable prototype will help you more easily convey your app’s vision to the eventual developers you work with. With it you can also start testing the market with your targeted users and pitch investors to raise capital to build the app.

We hope this helps you to better define your idea and create an app that has a strong foundation. Once you have your clickable prototype, we would love to know more about your project. We can help you build an app with our 8-weeks to MVP or a customize ongoing package. Contact us so we can learn more about the project you want to build.

You’ve reached the stage in your startup where you need to hire a software development company. The developer you work with will build the foundation of your app which will dictate decisions possibly for the life of your company. Plus, it’s easily one of the largest first expenses for a startup which means you need to choose who you decide to work with carefully.

Ian and I founded Code Hangar because we understand the important partnership between development companies and startups. That’s why we really want to develop good working relationships with the companies we partner with. We like the transparency because it helps everyone to achieve the goals as one team once the project starts.

It’s also why we encourage you to take extra time and consideration before you hire a software development company. The team you hire needs to communicate with you effectively and help you deliver results in order to show progress to your investors. Most importantly, though, they will build an app that can continue to grow well past your working relationship.

Before you Hire an App Development Team

When you search for a development company, it’s important to find one that meets your needs. This includes the technical aspects, communication style, and that they understand your overall vision. All these components will help build a strong relationship that will help you meet your technical and business objectives.

Before you start your search for the ideal software developer, make sure you consider the following first:

Give yourself enough time

Start your search for a dev team early. Don’t wait until you have investor timelines to meet. Give yourself at least three months before you need to start the project. This will give you time to really evaluate different companies and make a well-formed decision instead of a rushed one.

Shop with an expert

If you don’t have a technology background, it might be hard to know what technical offer is best for you. Not every technology works for every problem.

A developer’s job is to understand the client’s needs and recommend the best way to build your app. This might mean they even recommend another company that specializes in the coding language that would be the most effective. However, not every company might be that transparent.

So, if you don’t know how to determine what coding language is best for your project, find someone you trust who does. This can be a friend or family member. A mentor from an incubator program would be a good resource too. Whoever it is, find a person who will look out for your best interests.

Shop around and meet multiple times with the right people

When you start your search months in advance, you give yourself enough time to meet multiple times with potential dev teams. This gives you the ability to ask questions over time as they come to you before you begin work.

You’ll also want to meet with all the team members who will work on your project. If the team your meeting with needs to refer to another team member to answer a question, request an additional meeting with that person included.

Be wary if a company is reluctant to meet with you more than once before you invest. Consider what your working relationship might be like. This is a big investment and a large component of your business.

Dig deeper than the success stories and ask the uncomfortable questions

Everyone can easily share a success story. However, the companies that are willing to be transparent in how they conduct business, deal with conflict, and grow from mistakes will paint a clearer picture of who they are.

However, to get there, you’ll need to ask hard uncomfortable questions in the interview process. Don’t be afraid to ask companies questions they would rather not answer, especially if it could affect your final decision.

Now, what exactly are some of the questions you should ask potential software development companies before you hire them? Here is a list of questions we suggest you take to your meetings.

13 Questions to Ask App Development Companies:

1. What does your ideal project look like?

Make sure you find out what kind of projects the dev team wants to do. Does that sound like what you need? If not, you might not be happy with what you get from that company. Usually, their ideal project will give you an idea of the type of work a company wants to do or is good at.

For example, imagine you need to build a communication app but you interview a company that specializes in apps for banks and the financial sector. Because of that company’s knowledge base, they might not be able to service your needs as well.

2. What does your ideal client look like?

Ask this question for similar reasons to the last one. If a development team usually works with small businesses, but you are a large scale entreprise, the team might not be familiar with the needs of an organization the size of yours. Try to find a company who’s ideal client aligns as closely as possible to your business to help reduce friction and learning curves.

3. What does project management look like?

There are a lot of moving pieces in app development and organization is vital. Learn how potential dev teams manage the overall project from big goals to small details. Make sure you find out how they communicate goals, get approvals, send you information, and even how quickly they’ll answer you back.

4. How will we communicate?

Technology is awesome and it allows us to communicate in a million different ways. However, the communication method needs to work for both you and the dev team.

Varying aspects of the project might need to be communicated differently. Quick questions might go through informal channels while formal requests are put into a project management system and email communications.

For example, at Code Hangar, because we work in sprints, we communicate with our clients constantly and have goals laid out for each sprint. Some of the communication tools we use are:

Slack - Real time, daily communication. We also integrate with code repositories to send out notifications anytime we push a code update.

Email - Formal communication and requests.

Trello - Task tracking.

Invision - Design feedback.

There is no right or wrong way to manage communication but it is important to make sure that you are getting all the information that you need in a way that is easy for you to keep track of.

5. What would the day to day look like when we work together?

Ask this question to get some insight to the daily work process of the dev team. You want a team that will be transparent in their work process. It gives you greater insight into how they’ll work on your app with you and whether they are capable or interested in adapting to your needs.

6. What is your development stack?

This question refers to the type of coding languages, libraries, and services your app will be built with. The development stack you choose can have a big impact on the future health of your product.

However, it is up to you to decide the development stack for your project. Eventually, you will need to hire an in-house development team that will need to know the technologies your app is built with.

Questions you might want to ask yourself are; is there longevity in the language? Or are software developers with the skills in this language easy or hard to find? The languages you build with can determine the price of development. For example, if you want native iOS development, costs are expensive, whereas web development tends to be cheaper.

At Code Hangar we use the React Ecosystem on the front end which is a popular framework maintained by Facebook. On the backend we use typically use Node.js + Postgres, or Firebase which is maintained by Google, depending on the needs of the project.

7. Describe your most successful project.

It’s important to deliver results to your investors. This question lets you find out what success looks like for different dev teams. Are their successes what you want to achieve when you work with them?

8. Describe a recent unsuccessful project.

This is a difficult and uncomfortable questions to ask. That’s okay, in fact, that’s the whole point. When you ask uncomfortable questions you start to see how the development team might handle stress and conflict.

A good team will have insight into where things went wrong. They will also give solutions on how they’ve worked to fix those problems since then. This can give you insight into the potential weaknesses of the team you choose.

9. What if we need to pivot mid-project?

Projects don’t go perfectly and in the world of technology startups, pivots happen. However, the way pivots are dealt with can vary between dev teams.

Ask potential developers if they have a process for pivoting. Don’t be afraid to request an example. How they responded previously will give you a clue of what it might be like on your project.

For example, we like to work in 2-week sprint cycles here at Code Hangar. This allow us flexibility with goals and long-term deliverables. If we need to pivot, we try to do so at the beginning of a sprint cycle. However, if it needs to be sooner, we will explain all the implications the pivot will have on the project. That way our clients can make the best decision for their company and investors.

10. Do you charge above or below market price for your services? Why?

Prices for dev teams can vary wildly. Which can make it hard to know if the price you’re being quoted is fair.

The way around this is to ask the potential software developer to be transparent about their business model by explaining their pricing. Yes, this is another uncomfortable questions but will tell you a lot.

At Code Hangar, we are very open about our pricing model with our clients. This gives many of them a chance to see what pricing looks like for development, possibly for the first time. Because we appreciate how important the investment for our work is, we want our clients to know they made the best decision for themselves when they choose to work with us.

11. How does billing work?

Development projects can be priced in a variety of ways. There is no real standard, but common arrangements include hourly, sprint-based, or project-based pricing. You might even consider joint ventures or profit-share.

A project-based price is usually set around a defined goal. However, this can make pivoting harder since needs can change in the middle of a project. Plus, once the goal is met, you might have to work out another contract with the developer which could unintentionally lead to delays in continued development.

At Code Hangar, our preference is a sprint-based model. Product development is never truly done and a sprint-based model assumes that the work will be ongoing. This model allows us to set up a development pace and billing cycle that will work within a clients budget, and most importantly, allows us to change priorities with your business as you gather new feedback and insights from your customers.

12. What does handoff look like?

This should help you be flexible. You don't want to get stuck in a situation where your intellectual property is held hostage. A good app dev team understands this and has a process in place to handoff the project to you when they are no longer involved in the build. At Code Hangar, we give our clients full ownership of all code and assets from day one. This helps us build relationships based on quality and trust.

13. How do you know when a relationship with a client or partner is over?

Another hard question but you need to talk about how the business relationship will end at the very beginning. Eventually, you will need to build an in-house team. Or, you may simply outgrow the type of work the development company specializes in. You’ll want to find a company that is prepared to release you when it is time for you to move on, even if that is years down the line.

At Code Hangar, we are great at working with startups in the beginning phases of their app development. Our goal is to build software that helps businesses grow. Once a business has matured to the point that an in-house team is needed, we proudly help founders train their own team to take over development as we transition out of the project.

So, are you ready to start the search for the perfect dev team? Contact Code Hangar today about our 8-week MVP or Full Service packages and we’ll answer all these questions for you (even the hard ones) to see if we’re the right team for your project.

Orlando has a vibrant startup community and there are many organizations in Central Florida that are integral in providing resources for the community. Luckily, one of those resources are incubator programs which help tech startups who have little money but need access to resources like mentorship, coworking spaces, staff that can help with business models, intellectual property laws, and advice on funding and building teams.

While there are multiple programs to choose from, they all offer different resources and focus. Some programs are for entrepreneurs who are just in the ideation stage while other programs are geared towards scaling companies that already generate revenue.

If you already have seed funding and are ready to move towards your first fundraising round (series A), a better option would be to hire a development company like ours at Code Hangar who can be your technical team as you scale your business.

However, if you aren’t ready for that yet, we want to offer you a list of startup incubator programs in Orlando that can help propel you to the next level!

Starter Studio

Starter Studio is located in downtown Orlando. It actually has two incubator programs. The first program is the Ideation Stage Accelerator which will help companies go from nothing to an MVP.

Ideation Stage Accelerator:

• Full-time 12-week program offered twice a year in the Fall and Spring
• Coworking space at Canvs
• Demo day for companies to pitch to local leaders and business owners
• Mentorship

The Seed Stage Accelerator focuses on early stage growth, capturing market share, and getting companies investment ready.

Seed Stage Accelerator:

• Part-time six month program
• Mentorship lead
• Free program
• Invests between $25,000 and $225,000 in each company accepted into the program
• Investor showcase at end of program

Venture ScaleUP

Venture Scale up is run out of Catalyst and is geared towards companies that already have a viable MVP in place along with some paying customers.

• Part-time with two programs a year in Fall and Spring
• Mentorship community
• Coworking space in Catalyst
• Investor pitch event at end
• One-on-one sessions with seed and early-stage investors

UCF Business Incubator

The UCF Business Incubator program concentrates on building companies that can build long-term employment opportunities in Central Florida. The incubator program is for companies who already have proof of concept, however they do also offer a preincubation program if you’re in the ideation phase.

• Full time program up to three years
• Mentorship
• Access to UCF’s network of resources
• Lease options at a nominal fee or small monthly fee for off-site companies

Upstarts

Upstarts is the incubator program offered through Blackstone at UCF. This program is exclusively for UCF students (unlike the UCF incubator program which is open to all businesses in the region). Student companies must be revenue generating for at least six months and have a minimum of two UCF student team members.

• Part-time program that goes throughout the academic school year
• Mentorship
• Access to UCF Business Incubator for successful upstarts
• Up to three credit hours offered for time spent

Burnout Game Ventures

Burnout Game Ventures helps video game, simulation, and VR/AR companies scale. The program is free but asks for revenue sharing to market the game via their own network and resources.

• Industry specific mentoring
• Development costs covered
• Education and industry specific resources

Goldstein Accelerator

The Goldstein Accelerator is an incubator program located in Oviedo. Their incubation program works with companies who have less than two million dollars raised. Their focus is to help startup teams who want to be acquired within 18 months.

• Part-time six-month program offered in fall and spring
• Mentorship
• Coworking space provided in Oviedo
• Provides access to $100,000 in seed funding

Guidewell Innovation Center

Guidewell is an incubation program in Lake Nona that will serve the healthcare tech startup community. This is a new program in Orlando but Guidewell is partnered with UCF, the City of Orlando, and Florida Hospital amongst other companies interested in economic development.

• Access to office and wet lab space
• Mentorship

Seminole Technology Business Incubation Center

The Seminole Technology Business Incubation Center, located in Sanford, offers a long-term incubation program to companies that are already revenue generating but needs access to resources and space in order to accelerate the business’s growth.

• Full-time long-term program
• Mentorship
• On-site training
• On-site office space available for rent
• Quarterly goal setting and benchmark evaluations

If these programs don’t seem like the right fit for but you’re ready to take your app to the next level, contact us about our 8-week to an MVP or full service packages.

So you’ve just thought of the perfect app, great! Once you have an awesome idea for an app, you’re going to have to actually build it. However, there are a lot of challenges you might face in this endeavor as a startup company such as limited access to resources, multitasking many different types of work in early stages as a founder or solopreneur, limited funds, lacking extensive technical experience with at least some aspects of your build-stack, etc. — all of which can feel like a lot to overcome on your own.

Luckily, an effective app development process will ideally be tied to your fundraising efforts. This way, you can build your app in stages as your available funds allow. Below is our guide to help you navigate this process while simultaneously raising money to finance your development:

How to Build an App — Stage One

App Development: Envision your Prototype

Fundraising: Self-Funded

You don’t have to have money at the first stage of a successful app development process — but you should definitely at least start your research efforts as soon as possible. Then test the market and start to build out a prototype app yourself. By doing this, you’ll be able to better communicate your idea’s potential to entice future developers or investors.

Programs like invisionapp.com will allow you to easily create clickable images so you can design the initial look and flow of your app. Even without a technical background, and without writing a single line of code, you’ll be able to easily prototype a conveniently accessible and presentable visual representation of your future app.

As soon as you can, at this stage, you should start to gather constructive feedback and test the market. You’ll want to see if there is widespread support or an already existing or prospective customer base for the app you want to create before you or others can confidently invest in it. The app will probably change a lot from your initial conceptions as you get helpful feedback from the marketplace or experienced developers, and that’s okay! During this phase, you should think carefully and fundamentally about what needs your app means to fulfill; plan out “user stories” describing its core functionalities and prioritize which of these are the most crucially important and which could be eventual stretch-goals or enhancements that would be nice to have but are not absolutely necessary.

How to Build an App — Stage Two

App Development: Software Prototype

Fundraising: Self-Funded



Now it’s time to invest some money into your app and develop the first coded demo of your app. If you aren’t an experienced developer, hire a freelancer who can develop the app further. In fact, this freelancer could turn into a valuable team member as you grow your company and need an in-house technical team.

Eventually, your app will need both front-end and back-end development. However, in this phase you’ll probably only need to develop the front-end side of the app — which is the client facing side and deals more with the visual presentation and aesthetics. Connections to servers and databases are back-end features and can be saved for future stages or temporarily mocked with placeholder “data” for initial demos.

Don’t worry if you have to eventually throw away this entire version of your app in the next stage. You need to have something to show in the early phases for investment and marketplace testing even if its UI/UX ends up looking and flowing completely differently later on.

With a minimally functional but hopefully polished looking demo in hand, you can present your idea to investors to attract seed money for phase three. Continue to release to customers if you can manage some alpha or beta releases for research purposes and get their feedback too, as this will only help you develop a stronger app long term.

How to Build an App — Stage Three

App Development: Fully Functional MVP

Fundraising: Seed Funded



Congratulations, you’ve reached the point where you have some seed money thanks to a few investors who understand your vision and recognize its potential! Now you’re ready to build a fully functional minimum viable product (MVP) on a single platform such as the web (or perhaps whichever mobile platform it was initially developed for if you focused in that direction).

Once you’ve written the code for your app at this stage, it’s not a throwaway or hardcoded product. You’re building the permanent and dynamic infrastructure of your app. This means that you’ll not only have client facing front-end features but also back-end features that persistently save, store, and recall users’ data — but that customers don’t interact with directly.

One freelance developer probably isn’t enough, at this stage, because of the expanded skill set needed to achieve a finished product of this sort, unless you can afford an extremely talented full-stack developer. So, you’ll want to hire a development company at this stage, like Code Hangar.

A Development company will get you a technical team quickly and help you understand what it’s like to work with one. Plus, they can help you navigate who will serve you best in your eventual in-house team you will need as you continue to grow.

You will still need to release early and often at this stage so you can continue to test the market and get feedback. How quickly you can develop a full-stack app depends on your development company and how well they know how to leverage modern DevOps technologies — but, at Code Hangar, we can build an MVP for you in just eight weeks!

Once your MVP is in hand, you can reach out to venture capital companies and start your fundraising rounds (series A, B, and C).

How to Build an App — Stage Four

App Development: Continued Feature Enhancements

Fundraising: Series A, B, or C



While this is the final stage of the app development process, it is never truly finished. That’s because, at this stage, you’ll inevitably be in some type of continuous release operations and maintenance mode with options to build out new features and expanded functionalities. It’s also time, at this point, to think about scalability and maximizing the security and cryptographic rigor of the app (if you haven’t already).

It’s best to release updates in sprint cycles of 1-2 weeks. Sprints allow you to fix bugs and add features as you respond to continuous customer feedback at an agile pace.

Using your initial VC funding, start to invest in your in-house team. This lets current and future investors know you are serious and you want to build a company that is in it for the long haul.

Typically, successful small-scale in-house software teams consist of a project manager, designer, front-end developer, back-end developer, and quality assurance (QA) tester. Remember, it’s also important to build a strongly collaborative culture of teamwork within your organization. The most successful teams are ones where open communication, at least some cross-training and shadowing, and constructive feedback are valued — and cross-functional teams set agile goals to increase velocity when sprinting toward larger milestones.

Finally, you want to recreate your success by establishing repeatably effective processes over the long term. Then you can continue to reliably release work in efficient sprint cycles as you scale, fix bugs quickly to keep your app stable, and address continuous feedback from your customers in a timely manner.

No matter what stage of the app development process you’re in, it’s important to remember that you should release updates early and often in order to get feedback from both users and investors. This allows you to develop a stronger app over time that responds to the marketplace and features introduced by any competing apps quickly.

If you have an app that you’re ready to take to the next stage of development and need to bring on a talented and experienced development team, Code Hangar can help you. Contact us to learn more about our eight-week to MVP or full-service packages!

In October 2017, the first-ever Florida PyCon Conference was hosted in Orlando, FL. With 4 tracks, 20 speakers, and about 200 attendees Florida’s first and only regional Python language conference was a smashing success.

Goals & Challenges

Being a multi-track conference, FL PyCon organizers realized as conference day approached that it would be super helpful if attendees could easily find out which talks were happening when and where. While the full Florida PyCon schedule was posted on the FLPY website, experienced event organizers know that you can never rely on stable WiFi access at conferences and the PyCon organizers wanted to make certain that attendees could access the information they were looking for. In addition, they thought it would be great if attendees could build their own personalized FL PyCon schedule and take notes on the talks they attended.

For these reasons, FL PyCon Organizers asked Code Hangar if they could build an app that attendees could use to access the conference agenda and cache it for offline use in the case of poor internet. We were happy to donate our design and development services for the cause.

Process

With only a few weeks until the conference, we knew we would need to work quickly and efficiently. We also knew that the conference organizers were already super busy organizing the conference (in addition to working regular day jobs), so we would need to be as flexible and proactive as possible to work with their schedules.

We decided to build these apps using React Native so that we could maintain a single code base and deploy to both iOS and Android app stores.

Design & UX

Within a few days we outlined the user flow for the MVP and got it approved by organizers.

We quickly translated these flows into high fidelity layouts based around the Native Base UI Kit for React Native. This saved us a lot of design time and reduced most unknowns around layout development feasability.

Development

As mentioned above, we decided to build this project using React Native so that we could easily deploy to both iOS and Android while maintaining a single code base, and because we have been building web applications using React since we began our company in 2015 so it just made sense.

A bonus that came with using a tool called Expo for React Native, is that we were able to push UI updates to both platforms without needing to go through the app store update submission process. This meant that we could remain flexible and push out updates on the day of the conference if needed without requiring users to manually update the app.

Outcomes

After the conference we checked the download numbers for iOS and Android. We had about 200 downloads, indicating that nearly every Florida PyCon attendee downloaded the app. Conference organizers were extremely pleased with the outcome, sharing their excitement and gratitude on Twitter.

Community tech events hold a special place in our hearts here at Code Hangar and we are so honored to have had the opportunity to contribute to make Florida PyCon a success.

Download the Florida PyCon app for iOS and Android to see an example of what we could build for you.

ReQLPro is a desktop RethinkDB GUI Client for Mac OS X, Windows, and Linux. If you’re not sure what RethinkDB is, check out their website to learn more about what makes it “the open-source database for the realtime web.”

Download ReQLPro

What’s New in this Release?

Persisting Connection Passwords and SSL Certs

While ReQLPro has had the ability to add connections with passwords and SSL Certificates for a while, we haven't been persisting them to the filesystem. We wanted to wait until we had a secure method of saving passwords first, and now that is here! Passwords and SSL Certs will now be saved and persisted via:

• Keychain on Mac OSX
• Credential Manager on Windows 10
• Passwords & Keys on Ubuntu.

NOTE: We found have saving passwords with the Linux build to have mixed results on different systems. If ReQLPro 0.2.1 is not saving passwords for you please let us know your Linux distro version. Installing libsecret on your system may help.

Data Explorer - Table View: Expanded object contents

For cell whose contents represent an "object", we have replaced the placeholder "{Object...}" string with a JSON.stringify() of the cell contents.

Save Record Keyboard Shortcut

When Adding or Editing a Record: Use Cmd+S or Ctrl+S for quickly saving the record

Fixes:

• Reset pagination and query settings after selecting a new table

We hope you enjoy the latest release of ReQLPro! We are always happy to receive feedback from our users so please let us know what you think!

Download ReQLPro

The Minimum Viable Product and Why it Matters to Startups

App development is almost as much about speed as it is about quality or cost. While it's vital to create an awesome app that represents your business, products, and services in the best possible way, your startup also needs to get it launched, fast. That means getting a minimum viable product (MVP) designed, tested, and delivered.

Speed to market is one of the biggest competitive advantages you can have — whether it's due to competitors in the marketplace, to coincide with your product roadmap, or another external deadline. That’s why we created our “Eight Week MVP” service offering, designed to get your startup’s app from concept to working product in just two months.

There’s a huge benefit to being first — better promotion, more word-of-mouth, greater uptake, and refocusing resources into other areas. As we’re one of the fastest application development services in the industry, Hobbygoblin decided to work with us to bring their smartphone app to life. Here’s how we went from concept to completion, while ensuring quality and giving Hobbygoblin maximum value.

Read on to see how our Eight Week MVP service could benefit your business.

The Client — Hobbygoblin, a Gaming Startup

Hobbygoblin is a startup business supporting the board game and roleplaying game hobbies, allowing gamers to find each other, connect, and support their local, friendly, independent gaming store. Games like Magic: The Gathering, Dungeons and Dragons, Pathfinder, Warhammer, and more are becoming increasingly popular. These games are much loved by the people that play them, and these customers tend to be very loyal to independent gaming stores who host events and sell the games.

Hobbygoblin’s aim is to get more gamers into stores and buying games from them, rather than online. It does this by providing an easy way for gamers to connect with each other, build communities, find events, and support their friendly, local gaming shops. This will help to keep the tabletop and roleplaying game industry thriving, for the benefit of gamers, retailers, and suppliers.

The Challenge — Moving from Concept to Demo-Ready MVP in Just Eight Weeks!

Hobbygoblin had a big ask — get a working, high-quality demo smartphone app ready in time for Origins Game Fair in less than two months! Here at Code Hangar, we knew we were up to the task. Success would depend on working closely with our client, a rock-solid plan, and fast, agile, precise execution.

The Plan — Eight Weeks of Features, Form, and Function

We got to work straightaway. Here’s how the plan shook out:

• Concept and collaboration — working with Hobbygoblin to establish the key functionality and features the app needed to have.
• MVP Product Strategy — understanding exactly what we needed to do at every step.
• UI design and layout — creating an easy to use, appealing, and beautiful user interface (UI) and user experience (UX).
• Lead capture pages — allowing Hobbygoblin to capture vital data from demo app users.
• Front end app architecture and backend database and APIs — interfacing with other parts of the app and supporting platform to provide a fast, responsive, seamless experience.
• Responsive web development — the app needed to look great across any device, operating system, or browser.

This was all achieved through using the Lean / Agile project management methodology. This is a rapid, iterative, collaborative development process that involves the client from start to finish. It allows for rapid prototyping, improvements, testing, and development, as part of an ongoing cycle.

Discovery — What Hobbygoblin Wanted from Their MVP

The first part of any MVP process is to understand exactly what the client needs. Hobbygoblin had a few key requirements:

• Allow any user or gamer of the app to connect with other game players and retailers.
• Filter gamers and stores by location, game type, and game title.
• Enable registered gamers to chat with other gamers and setup games.
• Have a profile system so other gamers can seek you out.

We gathered detailed specifications for each of these areas and built them into our MVP delivery cycle.

Wireframes — Prototyping Requirements and App Screen Flows

We needed to ensure we were understanding Hobbygoblin’s requirements properly, and the best way to do that is to provide examples and context. That meant building a simple wireframe prototype of the app that simulated what each screen would look like, show how users would move from screen to screen, and demonstrated user interactions, inputs, and outputs.

We went through a couple of iterations to perfect the screen flow and user interactions, then built a bare-bones, mobile-first, web-responsive app in the first week. This early version of the app allowed Hobbygoblin to onboard alpha users early, letting them capture leads from both the gamer and local gaming store marketplaces. This let Hobbygoblin start lead capture while the rest of the app was in development.

Design and Development — Bringing the MVP Application to Life

We worked on perfecting the user interface and design of the app while simultaneously creating the back-end platform. Once we understood the user flows and functional needs of each interface, we could create and implement front-end views, a lean, flexible database, and a comprehensive API to allow for easy integration.

The design of the app was completed using industry best practice for UI and UX. That meant being led by Google’s “Material Design” principles, regular user testing and feedback, and ensuring the app itself was easy to use, intuitive, responsive, and fast.

Search

Local Game Stores

Real-time Messaging

Milestone Reviews — Ensuring all MVP Development is Aligned with Hobbygoblin’s Needs

We worked alongside Hobbygoblin throughout by holding weekly milestone reviews. This is a flexible review process that lets us quickly react to changing client needs. This was extremely useful as Hobbygoblin prioritized development of their chat functionality about halfway through the development process. We were quickly able to shift development focus to get the chat part of the application in place.

Delivery — Bringing Hobbygoblin’s MVP App to Life

Despite the short timeframe, we never missed our weekly goals and delivered to Hobbygoblin’s requirements week after week — we even managed to squeeze in a few stretch goals! We deployed the app one week before the Origins Game Convention and used the lead time to make sure everything worked for the official launch at the convention.

The launch was a big success and we received lots of useful user feedback. Hobbygoblin is now one of our full service clients and we are continuing to enhance the app and launch new features based on all of the great customer feedback.

We know that getting an app developed can be daunting. That’s why we always focus on understanding our clients and developing awesome MVPs. We believe that through close collaboration with you, we can learn about your business and needs and deliver amazing, beautiful applications that will delight your users and help your business thrive.

-David Nicol, Founder and CEO of Career Fair Plus

When it comes to developing the best mobile applications, it's vital that they work across any device, browser, or form-factor. User needs are changing, and native iOS and Android apps aren’t always enough.

That’s why when we were approached by Career Fair Plus to develop their native mobile apps into a fully-optimized, responsive web app, we were ready. Here at Code Hangar, we specialize in creating web-enabled apps to help our clients succeed. On one hand that means cutting-edge technical skills and experience, on the other, it means developing close, collaborative partnerships with our clients.

We developed this case study to show how we work with organizations like yours to open up the development process, involve you every step of the way, and make sure you get a finished app that will delight you and your users.

We’re here to take the mystery out of application development. We know finding the right agency to work with can be tough — it’s why we pride ourselves on putting you and your needs first, then developing an awesome application to help you meet them.

Read on to see how we worked with Career Fair Plus, and how we could work with you.

The Client — Career Fair Plus

Career Fair Plus is a mobile app designed to connect University students with businesses interested in hiring them. It does this by allowing students to research companies, navigate job fairs, and get event alerts from their mobile device.

The app is successful with over 700,000 students signed up, 700 career fairs listed, and over 17,000,000 search queries to companies. The app is used by students from prestigious universities worldwide including Stanford, Tufts, NYU, the University of Oxford, and universities from across the US and around the world.

Their business model relies on providing exposure for the employers listed in the app, so that part of the experience needed to be seamless and friction-free.

The Challenge — Transforming a Native Smartphone App into a Fully Responsive Web App

Career Fair Plus decided to develop a responsive web version of their native smartphone apps for several reasons:

Greater reach — Career Fair Plus wanted to reach more students through increasing their “device footprint” — the easiest way to do that was to develop their native mobile apps into a fully responsive web app.

Speed to market — deployment for responsive web apps is instantaneous. New functionality and features can be added immediately and the app doesn’t have to go through a lengthy approval process each time it's updated on the Apple or Google Play app stores.

Scalability — adding capacity and features to responsive web apps is fast and easy.

Responsiveness — responsive web apps work across all devices, formats, screen sizes, and form factors; they do not need to be specially configured for individual devices.

User experience — redevelopment into a web app allowed us to offer students an expanded desktop experience they were previously missing in the native iOS and Android apps.

The Requirements — Enhancing the Form, Functionality, and Features of the App

Career Fair Plus expected an optimized, easy-to-use app that delighted end users. That included:

Beautiful design — the web-optimized app needed to look perfect across every device.

Effortless navigation — the app should be intuitive and easy to use.

Built for speed — getting information into and out of the app should be friction-free.

Easy to maintain — further development, support, and maintenance should be effortless.

The Relationship — Working Together with Career Fair Plus

Naturally, when a business trusts us to develop their web application, it’s vital to nurture that relationship and ensure they get exactly what they need. We did that in several ways:

Using a collaborative development process — we worked closely alongside the team at Career Fair Plus and gave them complete insight into our transparent development process.

Proactively communicating — communication is at the heart of trust. That's why we actively communicated throughout the process so Career Fair Plus knew exactly what was going on.

Expert project management — developing an application is a complex task — concept, requirements gathering, development, client approval, testing, and deployment. Our expert project managers worked hand-in-hand with Career Fair Plus to deliver to their exact needs.

Integration with their team, business, and infrastructure — working with us is like working with a trusted internal development team. That means complete integration with business processes, team members, stakeholders, and existing infrastructure.

The Development Process — Building, Testing, and Deploying the Career Fair Plus App

Here’s how we worked together with Career Fair Plus to deliver the perfect responsive web app.

Initial Engagement

In 2015, Career Fair Plus decided to expand their reach by redeveloping their successful iOS and Android app into a new, fully-responsive web app. They hired us to replicate and enhance their existing user experience and tailor it for the web.

The first step in our process was to work with the Career Fair Plus team to prioritize which features from their native mobile apps were critical for launch and which could be developed post-launch.

Planning the Application and Product Roadmap

We worked closely with their leadership team to create a complete product development plan and charted a roadmap of essential features. We put together a concept for a “minimum viable product” (MVP) so their team and stakeholders had something tangible to look at. We wanted to optimize speed-to-market and get them access to a working beta as quickly as possible.

After agreeing the core set of features and requirements for the MVP, we put together a roadmap of Features, testing, and initial release target dates.

Collaborative Development

We worked very closely with their development lead using an “Agile” project management method. That allowed us to deliver a bare-bones application and then iteratively build on it based on their feedback. At every stage we knew our deliveries were aligned with their requirements. This gives us the flexibility to integrate new requests and respond to changes in the priorities of Career Fairs Plus.

During planning meetings we collectively reviewed and modified the roadmap and adjusted to changing priorities. This allowed us to incorporate feedback gathered from the internal team of Career Fair Plus and selected external customers. It also lets us ensure we consistently complete each milestone on time.

User Experience and User Interface Design

Whether users are interacting with a web application through their smartphone, tablet, laptop, or desktop monitor, the user experience (UX) is key. The user interface (UI) has to look and feel “right” and flow flawlessly from screen to screen.

In our initial design phase, we focused primarily on the desktop experience to optimize the app for the extra screen space that laptop and desktop screens provide. We used Google's Material Design Principles to build an app layout that organizes everything into one cohesive, robust, intuitive user experience.

Employer List, Details, and Filters — Desktop View

This is the heart of the application and shows the benefits of having a full desktop view. It allows students to select their filtering options, watch the employer list filter down in real-time, and view the details for a specific employer without having to perform any navigation to separate screens.

Responsive Web Development

Desktop interfaces don’t work well on tablets and smartphones — there’s just not enough screen real estate. Rather than try to break down and replicate the desktop interface, we completely redesigned the UI to optimize it for mobile. This means we feature each panel in its own separate mobile view, which is a much better UX. We achieved this by using a development framework to dynamically change page styles, functionality, navigation, and user flows depending upon the screen size.

Employer List

Employer Details

Employer Filters

Choosing the Right Development Framework

There are several good options when it comes to front-end web development framework. Among our considerations for the best choice was a framework that Career Fair Plus already had experience with that would also let us convert the existing native mobile application into a responsive web app. The framework should also support Material Design, for a better UX.

We shared information comparing three popular frameworks with Career Fair Plus. Our proposal covered various areas including: overall popularity, render speed, associated tooling, server-side rendering, Material Design integration, and native mobile compatibility. Ultimately, the “React” framework was chosen.

Quality Assurance, Browser, and Device Optimization

Although development is the most essential part of delivering a great application, quality assurance (QA), user testing, and device optimization are vital. Towards the end of the build process we focused strongly on QA, testing, and browser / device bug fixes. We carried out rigorous and thorough testing including unique use cases, automated testing, unit testing, integrations, and more.

Delivery and Deployment

The most critical part of any development process is deployment. We worked closely with Career Fair Plus to deliver the app seamlessly, resulting in a smooth transition for all users — students, employers, and people promoting job fairs.

Ongoing Development, Maintenance, and Support

One principle we use is to always produce beautiful, optimized code. We always write the best, most readable code we can. This makes ongoing maintenance, development, and support much easier. Our developers and coders from other organizations can easily figure out what the code does to make further enhancements fast and easy.

Working with the Career Fair Plus team was a delight and we are honored to have earned their trust and friendship.

We know that hiring an application development team can be daunting. That’s why we always focus on understanding our clients first, and developing awesome applications second. We believe that through close collaboration with you, we can learn about your business and needs and deliver amazing, beautiful applications that will delight your users and help your business thrive.

To find out more about Career Fair Plus, visit their website and take their new web app for a spin.

It’s always nice to have a friend who can help you out once in a while. It’s even nicer to have a friend who can help you out 24 hours a day, who never gets tired or bored or sick, who is focused 100% on helping you do what you need to do.

Slackbots can be such friends for you. Setting up a slackbot is easy, and we will show you how to build your own helpful slackbot in 7 simple steps:

1. Get your Slack API Key
2. Add a New “Bot User”
3. Setup Your Project
4. Import Dependencies
5. Handle Slack Messages
6. Recognize Users (and the Bot)
7. Give Your Bot Some Personality

Let's get started!

Step 1: Get your Slack API Key

The first step in creating a slackbot is to create a new Slack app - Slack apps can do and be a lot of different things (such as be a bot in our case), but all of those things require a Slack API key to function.

To get an API key, first go to the Slack apps management page.

If you aren’t signed in, click ‘sign in to your Slack account’ to manage your team’s apps.

Once you’re signed in, click the ‘Create an App’ button in the middle of the screen.

(If you’ve created a Slack app before you’ll find the button in the upper-right corner). Give your app a name, such as “Example Bot”, and choose the Slack team where you want it the app installed.

Once you click ‘Create App’, you’re good to proceed! We’ve just generated an API key so that our slackbot can interact with everything that Slack has to offer. The next thing to do is to create an actual bot user, built with the API key we just generated, and add it to our Slack team.

Step 2: Add a New ‘Bot User’

To add a new bot user, select ‘Bot users’ under the features heading on the left-hand side navigation of the app configuration page.

Click the ‘Add a bot user’ button and give it username, such as @example_bot.

Keep the ‘always appear online’ slider in the off position (we want our slackbot to appear offline if it crashes) and then click the add bot user button.

Finally, we have to give our slackbot access to slack with our API key. Select ‘OAuth & Permissions’ under the features heading on the left-hand side navigation of the app configuration page and click the ‘Install App to Team’ button.

After you authorize the slackbot, you will then have access to the OAuth tokens - click ‘copy’ next to the slackbot user OAuth token to get the token on your clipboard!

Now we're ready to begin coding!

Step 3: Setup Your Project

Create a new directory where you’d like to put your code. Open a Terminal (be sure to have node.js installed), navigate to this new directory, and run

npm init

to create a new Node.js project. Then, run the following

npm install @slack/client --save

to install the necessary dependencies.

Next, in the same directory, create a new JavaScript file called ‘bot.js’ and open it up in your favorite text editor or IDE.

Step 4: Import Dependencies

The first thing we need to do is make sure that we import all the dependencies that our slackbot will need to do what it needs to do. Let’s do so by adding the following lines of code.

const RtmClient  = require('@slack/client').RtmClient;
const WebClient  = require('@slack/client').WebClient;
const RTM_EVENTS = require('@slack/client').RTM_EVENTS;

const bot_token = 'your-token-here';
const rtm       = new RtmClient(bot_token);
const web       = new WebClient(bot_token);

Here’s what the code above is for:

RtmClient is the real time messaging client for slack - we’ll use it to do things like send and receive messages.

WebClient is the web client for slack - we’ll use it for api calls that don’t have to do with sending or receiving messages in real time.

RTM_EVENTS contains the events that the rtm client will interpret and respond to. We’ll get to examples shortly!

bot_token is where you specify the api token that you generated at the beginning of the tutorial.

rtm andweb are the actual clients that we’ll be using for our slackbot, both initialized with our api token.

Step 5: Handle Slack Messages

Let’s take a look at how to handle some messages. Write out the following in the same manner as above:

rtm.on(RTM_EVENTS.MESSAGE, function handleRtmMessage(message) {});
rtm.start();

rtm.on , the response function, attaches an event handler to the real time message client.

RTM_EVENTS.MESSAGE indicates that a message was received, and handleRtmMessage(message) allows you to process and respond to that message.

rtm.start() starts the slackbot.

Next let’s flesh out the response function a little bit. Modify the above code to look like the following:

rtm.on(RTM_EVENTS.MESSAGE, function handleRtmMessage(message) {
    if (message.type === 'message' && message.text) {
        console.log(message.text);
    }
}

Now the function will check and make sure that the message is of ‘message’ type (as opposed to a gif or another api call) and that there is text in the message, and if both of these conditions are met then it will log the message to the console.

Right now our slackbot is just logging incoming messages to the console, which isn’t very interactive. Let’s make things more interesting by having the bot echo messages back into the channel.

rtm.on(RTM_EVENTS.MESSAGE, function handleRtmMessage(message) {
    if (message.type === 'message' && message.text) {
        rtm.sendMessage('You said: ' + message.text, message.channel);
    }
}

rtm.sendMessage is how the slackbot sends a message to a particular Slack channel. Remember to invite the bot to the channel you want it to participate in.

rtm.sendMessage takes two arguments - the message to send, and the Slack channel to send the message to. The Slack channel can be found in the message.channel property.

For Code Hangar’s Goldenboy, we use colons to specify a command. For example sending a message saying

issue: goldenboy needs more personality

will create a Github Issue saying that Goldenboy needs more personality. This is because the slackbot recognizes the colon, reading the text preceding the colon as the command and the text after the colon as the value for the command.

Here’s what that looks like in the code:

const allCommands = ['issue', 'command2'];

function executeCommand(command, args) { // this function processes commands
    console.log(command, args); // for now it just logs them to the console
}

rtm.on(RTM_EVENTS.MESSAGE, function handleRtmMessage(message) {
    if (message.type === 'message' && message.text) {
        if (message.text.indexOf(':') !== -1) {
            allCommands.forEach((command) => {
                if (message.text.indexOf(command) === 0) {
                    const args = message.text.substring(command.length);
                    executeCommand(command, args);
                }
            });
        }
    }
});

Here we have allCommands, which contains an array of the commands that our slackbot will recognize.

The function executeCommand takes the command, and it's following text as its argument and then does something with that command - for now it just logs it to the console, but you can add logic to it to make it much more interesting.

With message.text.indexOf(':') !== -1, the slackbot checks to see if the message contains a colon (and thus a potential command). If it contains a colon it then checks the full list of commands to see if they are present.

Step 6: Recognize Users (and the Bot)

The next thing to do is to make our slackbot self-aware, responding to its name and making sure that it doesn’t respond to messages that it sent itself. Slack assigns users a unique id, and the api uses this id rather than the usernames themselves. So, in order to make it so the bot can recognize users (including itself), we’ll have to get the user ids from the channel and associate them with their respective usernames.

We’ll need some new functions to do this. Add the following functions before your rtm.on function:

let users = [];

function updateUsers(data) {
    users = data.members;
}

function getUsernameFromId(id) {
    const user = users.find(user => user.id === id);
    return user ? user.name : 'unknown member';
}

The first function, updateUsers, updates our global users variable from a web api call that we’ll define below.

getUsernameFromId takes a user id and gets its associated username from the users variable.

Next, add the following after your rtm.on function and before rtm.start:

web.users.list((err, data) => {
    if (err) {
        console.error('web.users.list Error:', err);
    } else {
        updateUsers(data);
    }
});

web.users.list is a web api call that lists all of the users in the channel. If successful, it returns a JSON object that gets passed to updateUsers, a function that we wrote.

updateUsers assigns this JSON object to a variable so that we can use it within the slackbot itself.

Finally, getUsernameFromId is called whenever we need to look up a username that corresponds to a given id.

Let’s see these in action.

const robotName = 'examplebot';

rtm.on(RTM_EVENTS.MESSAGE, function handleRtmMessage(message) {
    if (message.type === 'message' && message.text) {
        const userName = getUsernameFromId(message.user);
        if (userName !== robotName) {
            if (message.text.indexOf(':') !== -1) {
                allCommands.forEach((command) => {
                    if (message.text.indexOf(command) === 0) {
                        const args = message.text.substring(command.length);
                        executeCommand(command, args);
                    }
                });
            }
        }
    }
});

Here robotName is the name of the slackbot. The code then checks to see if the incoming message was NOT sent by the slackbot, getting the message sender’s username with the getUsernameFromId function specified above.

Step 7: Give Your Bot Some Personality

Now, we can make it so that the robot gets a little feisty when its name is mentioned.

const robotName = 'examplebot';

rtm.on(RTM_EVENTS.MESSAGE, function handleRtmMessage(message) {
    if (message.type === 'message' && message.text) {
        const userName = getUsernameFromI'xoxb-138883194769-WyyoRghxFHNhqPs9DVpIk24U'd(message.user);
        if (userName !== robotName) {
            if (message.text.indexOf(robotName) !== -1) {
                rtm.sendMessage('Hey ' + userName + ', I heard that!', message.channel);
            }
            if (message.text.indexOf(':') !== -1) {
                allCommands.forEach((command) => {
                    if (message.text.indexOf(command) === 0) {
                        const args = message.text.substring(command.length);
                        executeCommand(command, args);
                    }
                });
            }
        }
    }
});

The new code makes it such that the slackbot will recognize its own name and respond!

Here’s what the code looks like all put together:

Our Goldenboy operates by these basic principles! To check it out for yourself or to install a full-featured Goldenboy of your own, go to Goldenboy’s Github page and click ‘deploy to Heroku’.

Let us know if you have any questions in the comments below! Thanks for reading!

When you first join a new dev team or contribute to a new open source project, getting started can be a little daunting. Often times, familiarizing yourself with an existing code base can feel like being thrown right into the deep end of a pool. Your team might give you a brief tour of the project, and you might have some background knowledge to put to use too, but you still won't really know your way around until you actually dig in for yourself.

In this post I'll candidly describe my experience fixing my first bug in an existing project that was brand new to me. I hope my experience and the techniques I used can be useful to other developers who are likely to find themselves in the same position at some point in their careers.

My Task

The project I was walking into for the first time was the code base of ReQLPro, a native desktop app built with React and Electron. The app is used to help manage RethinkDB databases, many of which contain tables that have multiple pages, and the bug that I needed to fix was basically a pagination issue. The problem was that if a user navigated to the last page of a table with 10 pages, then switched to a table with only 1 page, it would cause the app to end up in a weird state. I needed to make sure the page of the last table didn't influence the state of the next table.

Getting Started

I set out knowing that navigating to a new page in the current table would somehow cause errors when changing tables. Knowing little else about how the database connections were handled, I started out to simply see how ReQLPro was storing the current page number, then figure out what it did with that information when the table was changed. I figured that the first place to look was the display, so I started by looking for strings where the page number was presented to the user and then looked for those strings in the code.

In the ReQLPro app, I dug around the tables that were available to me until I found one with multiple pages. I then used the bottom panel to navigate to another page. I saw the current page number displayed as below:

I figured that the numbers would be variables and couldn’t be directly searched for in the code without knowing their names, so I started by searching for what I figured would be a static string, i.e. “(Page”.

This proved to be a success, leading me to the currentPage variable in ExplorerPagination.js

However, currentPage seemed to be taking its value from a variable (table) that wasn’t defined anywhere in that file. I figured that PageDetails, its parent component, was being called from elsewhere and being supplied with the table variable from there. I searched the project for PageDetails to get more information. This just led me back to the same file, where I saw that PageDetails was being called from the ExplorerPagination container which was itself exported and being used elsewhere. So I then searched the project for ExplorerPagination.

This led me to ExplorerFooter.js, which I saw was defining table from the state:

I continued the search for selectedTable. This led to a ton of search results, but after some digging I came to setSelectedTable in a file called core.js.

It looked to me like calling this function would set the query page to 1 (line 94). I figured that this function was being called when a new table was being selected, but that somehow the query wasn’t getting its page changed.

I searched for setSelectedTable and found it in main.reducer.js.

Now I'm on to something...

Based on my limited React/Redux experience I figured that SET_SELECTED_TABLE was being used to set the selected table, so I continued the search with that.

I found it DbTable.js.

I figured that once the table was clicked on, then SET_SELECTED TABLE would be called. What happened next? It looked like the default query (i.e. setting the query page to 1) would be used only if selectedTable was undefined at the time of the click (in the ‘else’ condition on line 44). If selectedTable was defined then selectedTable.query would be used.

I then figured that the problem was occurring because navigating to another table would use the query from the current table. If the current table query was set to page 2, then the next query would be page 2 as well. The user would have to navigate back to page 1 on the present table before navigating to a smaller table to guarantee that the next table query would be for page 1 itself.

Fixing the issue

I fixed the issue by adding the following to the condition (line 42):

This ensured that the current table query would be used only if the user clicked the same table on the side panel. It did so by checking that the next table name was identical to the current table name - if it is not identical then the default page of 1 would be used for the selected table query. This, as near as I can tell, resolves the reported issue.

In summary...

I didn’t encounter any glaring technical faults as I went - my primary challenge was unfamiliarity with the codebase, and I hope that my account here helps elucidate what a new user would encounter as they begin work on this project or any new project.