The new year is a great time to focus on new customer features in a mobile or software application, set some goals for user acquisition or put some new processes and systems in place to grow your business. Today, we’re introducing you to some resources that will help you set a plan for user (customer) acquisition, whether it be for a new mobile application or even a service business.

Running is one of my favorite hobbies. Lace up your shoes and run in the wee hours of the morning type running. A headlamp is required because it’s still dark. I’ve developed a habit around it, but sometimes a habit will plateau. The gains eventually taper off and the methods of training used over the last year may not take me to the next level of fitness. The same goes for your product, your team and your company. How do we get over the plateau?

In terms of fitness, I set a goal to beat a certain pace on a specific distance. Then I sign up for a race, and find a training plan (I’m using the free one) that will force me to do workouts to drop my pace and set a new PR (personal record). This year, I’m taking advantage of technology and have programmed my running watch for the actual workouts in the plan. That means I can’t slack off without a very loud warning from my watch. We can do the same thing for products, teams and companies. Internally, at Oak City Labs, we’ve been more strategic about quarterly goals, annual goals and long term vision. We set goals, we’ve written down a plan and it has forced us to make some uncomfortable choices. Ultimately, having that plan written down and doing things that are uncomfortable will help us grow to accomplish our goals.

We can also apply the same simple process to user acquisition and product growth. Much like the sales and revenue targets, your team needs to go through the exercise of setting a goal – whether it’s 100,000 downloads in 6 months or 100 new users in 6 months. Set the goal and work backwards. If I need to have 100,000 in 6 months. How do I get those users? How much will that cost? Where do they come from? How many can I get in January, February, etc

Ryan Gum does an excellent job of giving you a plan, or at least a format to follow and would be a great place to start.

Other resources to dig a little deeper into customer acquisition include:

It’s also important to realize that your plan is going to change depending on your target market or ideal customer. Customer acquisition costs will also differ from customer to customer. Christopher Janz outlines different strategies by type and size of customer. Make sure to read his follow-up post on brontosaurus and whale hunting.

To help you get you moving, here’s a quick checklist to guide your thinking:

  1. Define your ideal user. This should be a detailed description of who they are, where they are, what they buy, what they think and how they buy.
  2. Set a goal(s) for user acquisition. How many ideal users do you need? When do you need them? Is it a realistic number and time frame? And write it down. Print it out and hang it up next to your desk.
  3. Work backwards. Knowing how many you need to acquire, starting asking some tough questions about how you’re going to get them? How much will it cost? If you buy Facebook ads in January, when do you expect those to convert and at what conversion rate? Use the sites linked to in this article to dig into the “how.”
  4. Define your plan. Write the plan down. For example, in January we’ll call 200 people. In February we’ll spend $10,000 on Facebook ads. Make sure to include a reminder with each of your actions to evaluate the performance and make tweaks. Review the plan monthly to make sure you’re on target.
  5. Execute. Just do it, follow your plan. Make adjustments as you go and don’t let analysis paralysis keep you from testing small acquisition campaigns.

I hope this helps get you started on putting a process around your customer acquisition strategies.  If you happened to really like this article and want to read more about this or another topic please contact us! We’d love to hear your feedback!

At Oak City Labs we love that we have the privilege of working with clients at all different stages of business. From the quintessential start-up, to long-established businesses, and those all in between, we have a history of helping folks at any stage.

Regardless of your business size though, it’s often a good strategy to consider developing a Proof of Concept (PoC) or Minimum Viable Product (MVP), before diving deep into a full-fledged app. A PoC illustrates the ability to solve a core problem, but often is not ready for users and may not be feature complete in terms of usability. An MVP is similar in that it is a bare-bones version of your app, however, it is feature complete in terms that it can be used to accomplish a certain task or tasks. Additionally, the MVP’s goal is often to appease external users – be that outside investors, early adopters, etc.

Today, I’m sharing a few of the benefits of investing in an MVP or PoC for your next mobile app or web app.

Mitigating Risk

PoCs or MVPs are an excellent way to mitigate the risk involved with creating a new app. The goal? Maximize value, minimize costs.

Depending on your organization’s business practices, introducing a new app to the masses can be a scary thing. What if it doesn’t integrate well with your current operations? What if your team has a hard time implementing it? Before investing your entire budget into a full-fledged app, consider creating a smaller PoC and rolling it out to a subset of your users. In doing so, you can perform acceptability testing or secure buy-in from key stakeholders. By gaining feedback from them at this stage of the game, you can adjust and iterate on your idea before rolling it out to a broader audience.

The same goes for an MVP. Oftentimes, even if you do your due diligence and perform market validation for your app idea, building out a full-scale app can be a costly investment that still doesn’t hit the mark. Consider the value of an MVP to bring the app’s most basic functions to life. Then gauge your users’ interests, likes, pain points, etc. before moving on to additional features.

Time and Money

Time is money. Smaller projects like MVPs and PoCs mean a quicker turnaround. And while we always implement an agile process for all of our projects, these smaller projects will (obviously) get to you quicker than full-scale build-outs. With a working product in-hand, you’ll be able to move on to your next business goal faster – be that testing the market or acceptability testing with your internal users.

Smaller scale projects also lend themselves to smaller-scale budgets. By building out out an MVP or PoC, you’ll spend only a fraction of your total budget, then spread out remaining costs over time as you iterate on the concept.

Influence Funding

Finally, MVPs and PoCs are a great option to build out in an effort to influence funding. With a working demo in hand, you’ll be able to sing the praises of your app to key decision makers that hold the company purse strings. If you’ve struggled to explain the concept of your app idea to them or are looking for a way to gain critical buy-in, consider jockeying for a smaller budget to be used to develop a PoC. Alternately, an MVP is an excellent option for sharing with potential investors and partners that may be interested in funneling capital into your business as you build out a full-scale product.

What are you waiting for?

So where are you in the process? Could you consider building an MVP or PoC for your next app idea? If so, let us know! We’d be happy to help.


The Small Business and Technology Development Center (SBDTC) recently held a symposium on the Small Business and Innovation Research (SBIR) and Small Business Technology Transfer (STTR) programs through the government. For new and established businesses, these programs can be excellent sources of grants to fund research and innovation. Today, I’m going to highlight key points from the symposium that are helpful when considering your different funding sources for a mobile or software application project.

First, if you’re unfamiliar with the SBDTC, they are a fantastic resource for North Carolina based companies that need solid business advisors, whether just starting out or working through more complicated matters such as international trade and exports. I highly recommend learning more and applying to chat with an advisor.

Don’t judge an agency by its name

Now let’s dig into the SBIR and STTR programs. The main difference between the two is that SBIR grants typically do not require collaboration with a research institution, while STTR grants do. In the Triangle area that could be NC State University, Duke University or the University of North Carolina. For the purpose of this article, and the content at the symposium, I’m going to focus on SBIRs. There are several different agencies that participate in the program outlined on the SBIR website. One key point made at the symposium is that we shouldn’t judge an agency by its name. Often times your project might line up perfectly with the Department of Energy (DoE) but could also qualify for support from the Department of Defense (DoD) or the National Science Foundation (NSF). With the DoD, there are 13 components, meaning the Army, Navy, etc. all have different topics. The important part is to adapt your project submission to the fit the agency need.

Don’t miss the deadline!

Each agency operates on different grants cycles and with different topics of interest for each cycle. For example, the DoD just released the latest round of topics ready for review and submission. While the USDA solicitation period for Phase I has already happened for this year, Phase II is open and available until March 2, 2018. Again, it’s very important to learn and understand how the agency operates so you don’t miss key dates and requirements.

Read all the things

Get to know the agency, their mission and goal for each topic. Read all the way through the solicitation, topic AND any possible submission guides. For example, the USDA has the SBIR solicitation on their website with specifics and guidelines in the RFA but there is also an application guide that lists all of the necessary application requirements. Each agency is different and may have different guides, so break out your search Google skills and scour the sites to learn more. A Google search for SBIR samples will also help guide your submission. Be sure to include the agency name when you search in order to find the most relevant examples.

Register on all the sites

Your first step should be to register on It’s required and it takes time to get approved. From there you’ll need to register on, but is the very first one you need to get going. Do not wait until right before the deadline or you won’t have time to be approved. We recently went through the SBIR process and registering ahead of time and familiarizing ourselves with the required documents for submission helped us meet the deadline. We also started the application well before we had anything to submit. By doing so, we learned everything needed by way of trial and error. Do not skip this step and make this your very first one.

Other resources

The site is also a good place to search for previously awarded SBIRs and STTRs. This will give you an idea of awards, topics and types of companies that have received funding in the past. The actual search function on the site isn’t the best and may take some trial and error to get relevant results.

For NC Business, there is a program called One NC Small Business from the NC Department of Congress. It provides a match on SBIR/STTR awards but is currently not funded. Consider contacting your legislature to have this program supported in the future. There are also great stats on the site about awardees and previous funding.

Did I mention the SBDTC? They are very focused on helping NC companies succeed and are particularly good and providing advice on the SBIR/STTR programs. There are also resources within local universities, consider reaching out to them or finding companies that rely on SBIR/STTR programs for continued innovation.

The SBIR/STTR programs can be arduous, however, the process will force you to think through a business plan, commercialization and market research. The worst that can happen is you don’t receive the grant but you can always try again next year!

We recently took part of our team to All Things Open in downtown Raleigh. It’s a great, affordable conference for developers and super inexpensive if you live in the Raleigh area. There were over 3,200 attendees, and the crowd has grown significantly since the first year. And so has female participation and speakers. Kudos to the crew that runs ATO for their efforts on diversity. If you weren’t able to attend, here are musings from my viewpoint:

Conference Takeaways

  1. As mentioned, the conference has grown significantly, from 750 in 2013 to over 3,000 in 2017. I’d love to see the geography stats for attendees to see how many are local to the Raleigh area versus out of state.
  2. There’s a little something for everyone. The tracks range from DevOps to UX/UI and Business. Check out the schedule and consider paying for only 1 of 2 days if you’re still unsure about both days.
  3. IMHO, the best sessions hit the high-level bits but then also gave practical advice and tactical actions for implementation. Craig Keirsten on Postgres Performance for Humans was one of my top 3 favorites. For those on MySQL, Valerie is a database rock star and covered a high-level approach to database upgrade testing. If you’ve never upgraded a production database, you haven’t lived life on the edge. You should follow her for all things MySQL.
  4. Kubernetes is the hotness this year. We heard it so many times it left one of our teammates rocking back and forth muttering it to himself over and over.
  5. It’s an incredible opportunity to learn at a high-level about other technologies that you don’t use day in and day out. For example, we’re dedicated to native app development for all of our mobile projects, but it gave us the opportunity to check out React Native and other frameworks. It didn’t change our minds, read more here about what we think about cross-platform.
  6. Machine learning interest continues to grow, and there was a dedicated track to it, however, most content was high level. The best teachings on machine learning came from a 15 minute conversation with Dave Anderson at Oracle (aka NetSuite aka Bronto). He has incredible hands-on experience with Spark at scale. Hopefully, he’ll submit a talk for next year. Dave echoed the teachings of another local machine learning expert John Haws: keep it simple. Don’t use things like Spark until you really need it. Most things can be handled with basic algorithms. Just guessing, but I imagine the same goes for Kubernetes.

And finally, ATO is like a mini-reunion where I was able to see some of the best developers and engineers I’ve worked with over the course of my career. It was also a refreshing reminder of how blessed I’ve been to work with those, like Dave, that mentored, taught and supported me as a young systems engineer to where I am today. We plan to attend again next year and hope to see you there.

As of 2016, about 28% of the internet was running on websites using WordPress (source). That’s a lot of websites! While there are countless ways to make a WordPress site unique, page builders have emerged as an up-and-coming force in the WordPress scene. Many page builders promise the ability to design a website without needing any code at all (hint: big promises are difficult to keep). Most page builders are drag-and-drop tools built on top of WordPress that allow users to place elements on pages. In this post, I will break down page builders into categories and cover their ups, downs, ins, outs, and everything in between to allow you to decide if using one is the right move for you.


At the end of the day, the most common question you’ll get asked when building a website for a client, your company or yourself is “how much will this cost?” That leaves you with essentially four options:

  1. Learn code and design skills and build it all yourself (Free)
  2. Hiring a developer to custom-build the site for you ($$$$$)
  3. Find a pre-built WordPress theme (Free/Paid)
  4. Use a WordPress page builder (Free/Paid)

Bottomline, unless you’re paying for custom development, WordPress is going to be cost-effective. Most themes and page builders have a relatively small, one-time costs, and those that don’t use affordable annual rates.

When deciding between these options, remember that most websites change their design every 2-3 years. Having a page builder allows you to change the design without paying for any other content, whereas with a premade theme, you may have to purchase another to match your new design.


Elements are the custom pieces of the website like social media icons, newsletter signup forms, and images. Most page builders have every kind of element you could possibly need on your website. Additionally, page builders come with an immense collection of options for you to customize. Usually, this includes most typical CSS options as well as some custom sizing and animation options.

Customization is where page builders both shine and suffer; while a number of options provided is often enough, sometimes it simply isn’t. In the cases where more customization is required, you may need to add custom CSS or even a child theme to arrive at the intended style/behavior. Depending on your skill level, this may be out of your wheelhouse and will require you to look for external help even though you may have tried to avoid it by using a page builder in the first place.

So, should I use one or not?

As usual, it depends. Here are some quick descriptions of each type of development to determine whether doing it yourself, finding a pre-made theme or building the site using a page builder is the best option for you.


The monetary and time cost of doing it all yourself depends entirely on your background. If you’re a web designer and developer by trade, maybe this option suits you best. You’re only limited by the speed at which you can develop and design all that you need. This route gives you the utmost customization, as you can determine from the ground-up every piece of the site. In order to create your own WordPress theme, you need at least a rudimentary knowledge of PHP, CSS, HTML, and JS.

Pre-Built Theme

Using a premade WordPress theme is incredibly common practice. Why design your own when you can find a theme that does everything you want and looks great? If you don’t have a design in mind, or you find a theme that fills all your needs, purchasing a theme someone else made is often the most cost and time-effective option. There are thousands of themes already made out there. This list only scratches the surface. Some themes are free, some themes are paid. As you would expect, you get what you pay for with free themes.

Page Builder

Let’s say you have an idea for a website but you can’t find an existing theme that meets your requirements. Or, maybe you have to build a website with a specific design, but don’t have the coding know-how to complete that task. Maybe you have the ability to custom build a website, but you want your less development-savvy team members to also be able to customize the look and feel of the site. In all three of these cases, using a page builder may be the best option for you. The combination of customization, low cost and saved time makes page builders an appealing and expanding, option for creating websites.

Some things to keep in mind

WordPress is WordPress. What you get out of the box is what WordPress is intrinsically built to do. Anything beyond the base feature set puts you at risk of falling victim to the various idiosyncrasies that come with going beyond intended behavior. The following are some issues people talk about when discussing page builders:

The “Lock In” Effect

WordPress evangelist Chris Lema wrote a blog post titled “If you use the Divi theme with WordPress, it better be forever.” Divi is a popular page builder (and also a theme that comes with the page builder). Divi makes use of a WordPress feature called shortcodes that, while useful in customizing a site, are specific to that theme. If you ever want to move away from that theme, those shortcodes will no longer work. While his blog post is a bit dramatic and not entirely true (there are ways to get around the shortcode issue), it is a good read for getting a grasp on one of the major pitfalls of using a page builder.


If you’re an experienced WordPress user, you understand this well. While speedy at first, every plugin and theme you add to your WordPress site adds up, and if you’re not careful, can have drastic negative effects on the load time of the website.

Plugin Conflicts

Most WordPress plugins are built in conjunction with the base, unmodified version of WordPress. By using a theme or a page builder, you risk incompatibility with certain plugins. For instance, maybe your blog page doesn’t conform to the design WordPress uses, and an infinite scroll plugin that works for the usual WordPress design wouldn’t work for your blog. Luckily, many themes and page builders come with a set of plugins made by the same developers for use with those programs specifically.

Final Thoughts

When deciding whether to use a page builder or not, remember to keep the following in mind:


  • What kind of SEO tools does the page builder allow for?
  • Is SEO built-in or will you need a custom plugin?
  • Is the built-in SEO sufficient?


  • Are all elements you need available?
  • What kind of plugins are compatible?


  • Are you building according to a design or designing as you go?
  • How much customization will you need from the features the page builder provides?
  • Do you need to add custom HTML? (Remember: if you do, use a child theme)
  • Does the page builder have a frontend or backend view, or both? (This allows you to preview/change how the site looks from the WordPress viewpoint as well as a user viewpoint)

There is no doubt that technology is the way of the future in the healthcare space. From calorie counting and fitness apps, to digital pharmacists and the ever popular EPIC electronic health record (EHR) software (read: MyChart), technology is moving away from analog and swiftly toward digital solutions. According to some figures, there are 165,000 health-related apps in the Apple App Store and Google Play Store and it’s estimated that by the end of 2017, those apps will have been downloaded 1.7 billion times, leading to a predicted $21.5 billion in revenue in 2018.

But moving toward an all-digital landscape of healthcare solutions (now called m-health) presents its own unique challenges – namely patient confidentiality, security and compliance in a day in age where hacking is commonplace and devices (not people) are doling out recommendations and diagnosis all too often.

At Oak City Labs, we work with clients in the healthcare space and know the importance of software compliance. Today, we’re providing an introduction to the two main types of compliance you should be aware of as you begin the process of building a mobile app or web app in the healthcare space.

FDA Compliance

First, is your mobile or web app considered a medical device? Just because your app relates to the health field doesn’t necessarily mean that it is considered a medical device. The FDA provides thorough documentation of what is considered a medical mobile app on their website.

If your app functions as a medical device, an accessory to a medical device or if it intends to diagnose, treat or prevent an ailment, then it will likely be regulated by the FDA. Earlier this year, the FDA announced sweeping changes to how mobile medical devices will be regulated. This article does a great job at outlining the details, but details are still unfolding.

There are three types or tiers of regulation on medical devices (including mobile medical apps) by the FDA: Class I, Class II and Class III. Beginning at the bottom, Class I medical devices are low risk and are considered non-invasive to patients. Class II devices pose a moderate risk to patients and/or are invasive in the short term. Class III devices pose a greater risk to patients and are inherently invasive. Class I and II devices require a 510(k) premarket notification. Class III medical devices must do the same, as well as undergo pre-market approval with the FDA before they see the light of day.  

One thing to keep in mind with the FDA — the review and approval process is incredibly long and drawn out (admittedly something the new regulations announced back in July are trying to address). In fact, when asked if the Apple Watch would make a bigger play in the health space, Tim Cook said he was leary of the Watch becoming a “regulated, health product” due to the long review and lead time required by the FDA and the ways it would hold Apple back from innovation.


If your mobile app collects, stores and transfers any type of personal patient information, read on, because it’s likely that HIPAA compliance is something you should be aware of. Even if your app isn’t considered a medical device, it still may need to follow HIPPA guidelines. For instance, EPIC, the prominent electronic health record (EHR) software, is not considered a medical device (and therefore not regulated by the FDA), but it is subject to HIPPA guidelines.

Introduced in 1996, HIPAA stands for Health Insurance Portability and Accountability Act and it covers protected health information (PHI) privacy and security.

The privacy portion sets forth what is considered PHI and therefore needs to be HIPAA compliant. PHI ranges from your name, address and social security, to billing information, biometric identifiers like fingerprints, family names, your tests results or scans and more. If your app stores or transmits any type of PHI, it could be subject to HIPPA compliance.

Under HIPAA, you’re considered either a “covered entity” (healthcare provider, health plan or healthcare clearinghouse) or a “business associate.” Both covered entities and business associates are liable to follow HIPPA and as such, both would be fined in the event of noncompliance. Ignorance is not an accepted excuse and the fines levied are hefty – ranging from $100-$50,000 for just a single violation.  

Now that we know what is covered under HIPAA compliance and who is liable for covering it, let’s talk about security. Security covers three areas: administrative safeguards (have a privacy officer, review policies and procedures, go through training and more), technical safeguards (automatic logoff, authentication, encryption and more) and physical safeguards (facility security, workstation security, access control and validation and more).

It’s important to think through these details from all aspects of your app – push notifications, emails, lock screens and what to do in the event that a device (such as a phone) is lost.

The above details on FDA and HIPAA compliance are just a small glimpse into both worlds. If you are thinking about creating a mobile medical app or entering the digital health space, be sure to thoroughly research compliance requirements before you begin building out your product. Not sure where to start? Oak City Labs would love to help! Drop us a note.

One of the most common questions to pop up when we talk with potential clients (besides “How much?!”) is “What technology can we use that is already out there?”. Regardless of budget, it’s always a good idea to evaluate what technology components you can buy or borrow versus building custom. It could be as simple as using an open source component for a date picker in an iOS mobile application or something a little more complex like a search engine.

Often, our clients do not have in-house software developers, a CTO and/or the time to dig into the technical details. Others may not know it’s even an option in software development to use something already out there. Today, I’m going to walk through three steps for evaluating the build versus buy decision for the non-technical folks out there.

First, make sure you’ve prioritized your product features. If you’re having trouble narrowing them down, and we all do, I highly suggest following one of the three buckets models described by Slava Akamechet or Adam Nash. Slava’s three buckets are best for early-stage products and Adam’s model will fit those that have paying customers. Both will give you the mental framework to break down a giant backlog of features.

Once you have freshly prioritized feature stories in your backlog, try these three simple steps:

  1. Ask – Do we really need to custom build this feature? Possible answer: This feature is our super secret sauce and it’s critical to our business. In that case, seriously consider building from scratch. And even if you build from scratch there’s a good chance you can use open source projects to help speed up the process. Make sure to check the project is using an appropriate license for your business model. If you’re OK buying versus building, move to step 2.
  2. Research – For example, one product’ you might like to include is a built-in analytics dashboard. That would be a large undertaking to code from scratch. Let’s start with a Google search. Searching the term “analytics” will give you more results than needed and won’t necessarily be helpful. If you add “for developers” on the end, then we start to get results with different software and API options. When one result looks like a possibility, choose it and search for alternatives or competitors to get a list of options. Either learn about them yourself or just understand that, yes, there are options and building from scratch may not be necessary. The developers can take it from there.Analytics for Developers Oak City Labs Raleigh Durham Mobile App Development
  3. Analyze – At this point in the process, it would be a good idea to have a developer evaluate the list of possible options with you, but it’s not completely necessary. Next, make a list of features needed. This could include things like price, features, support, scale, popularity, community support, etc. It’s also important to consider what features are missing that you would need to acquire from another product or build from scratch. Dropping all of this info into a spreadsheet will keep you organized.

This might sound really simple, but I promise you – the mental exercise of prioritizing and then doing #1-3 could save time and money in the long run. And when working with a software development team, you’ll have a foundation of knowledge when it comes to making decisions. If you need help, we’re always happy to set up a coaching session and be your CTO for a few hours. Give us a ring.

We screw up at times, and it sucks. Here’s how we handle it at Oak City Labs.

A few months back, we were working on a large client project and deployed a change that escaped our testing process. Fortunately, it didn’t cause a huge impact but it was embarrassing and we corrected the error. And we told the client we screwed up.

Early in my career I learned the importance of root cause analysis and reporting through the chain of the command. In our case, our chain of command ends at the client. In a large organization, this might be a much more complex notification chain. In all cases, it helps to have some structure around the process and also the information shared. Here’s a brief look at what we provide our clients for those (rare!) major screw ups:

  • Root cause description
  • Short term fix – How we stopped the bleeding
  • Impact – Affected users and systems, length of time, anything we can share to help message the outage to users
  • How it got past testing – This is usually brief and then revisited during a retrospective or post-mortem
  • Long term fix – A brief description and then revisited during a retrospective or post-mortem. We mostly want to answer: How will we keep this from happening again? If we’re unsure, we might provide a date/time for further discussion.

This is fairly standard practice in engineering, manufacturing and healthcare and we believe it to be an important one for software application developers too. It’s part of our process and something you should ask any developer on a project, whether outsource or an internal development team. For anyone growing a software company you might want to ask yourself these questions:

  • What does your company do for root cause analysis?
  • Do you have Systems Engineers, DevOps or Support teams that handle the communication?
  • What does it look like when something goes terribly wrong?
  • How do you communicate that to management and then to your users?

It’s an incredibly humbling experience to tell someone you were wrong or that you screwed up. We’ve been fortunate to have clients that understand the precarious balance between speed and bugs introduced because of that speed. For that, we are thankful. For the patience and forgiveness, we are humbled.

We could have 98% test coverage, which means that we have tests that check everything at the code level. We could have a team of QA people that manually test every possible inch of an application. And we could still find ourselves facing some bug, a memory leak or something that goes wrong somewhere in the stack. It’s a fact of life with software development and not for the faint of heart. It’s also incredibly difficult to find the right balance between what the client can afford and the amount of testing we build into an application.

At the end of the day, people and businesses are trusting us to build and solve problems that are critically important to the growth of their business. Would you want a developer that tells you when they screwed up? Or would you want one that finds a litany of reasons why something is not their fault?

We’re not perfect, we’re human. Having a process in place to handle those human errors can help guide your team, keep stress levels in check and ensure good communication between you and your customers.

If you’ve ever found yourself seriously thinking about building a mobile app, but have no idea where to even begin, this post is for you! In a world where it seems like everyone has an app idea, the truth of the matter is that there is plenty of room for innovation and new ideas in the marketplace. But to take your idea and make it a reality, you’ll need to keep the following in mind.

First: Market Research

At Oak City Labs, we’re passionate about market research and strongly believe that it is the key to your success. Before writing the first line of code, it’s important to make sure that your idea is fully thought through. And while market research is definitely the most strategic route to take when your app is still just an idea, it’s also the route that can end up saving you money in the long run.

To take that first step in getting your app idea off the ground, begin by doing some free research. That’s right: FREE! Using everyone’s trusty friend Google, you can find information showing you what your app idea’s total addressable market (TAM) could be. Along the way, you’ll find competitors and possible features. You’ll also start to refine what your app idea is and what makes it unique. We also encourage those in this stage of the process to talk to people and conduct Voice of the Customer surveys and, ultimately, create a value proposition statement. The goal with all of these steps? To help you refine your app idea, discover what makes your idea unique and set you up for success as you begin the process of building the app.

Next: Partner

After doing your fair share of research and being confident in your decision to move forward with building your app, it’s time to find a partner that can help bring your idea to life. When looking for a development company, we encourage you to prioritize the following:

  1. Reputation: How experienced is the development team? How many apps or custom software projects have they led or developed before? What do their clients have to say about them?
  2. Relationship: How are they planning to communicate with you throughout the project? Will there be weekly check-in calls? Will they help you flesh out your idea strategically, advise of feature prioritization, consult with you on growth strategies and more?
  3. Results: Are they going to be able to solve your problem? Is this partner able to help you achieve the results you’re looking for?

We created Oak City Labs to answer a lot of these questions – to give you the missing pieces to transform your app idea into a real, quality product that makes a difference. Our team has spent decades in diverse roles across multiple leading tech companies. From this experience, we understand how to deliver on all facets of the app creation process – from the technical considerations, to project management, to product-market-fit, and all the important questions you might not think to ask. We’ve learned these lessons so you don’t have to.

We know how all of the pieces of development fit together so we bring a fully informed approach to your final product. By building strong client relationships – guiding you through every step, valuing your feedback, and collaborating on the process with you – we craft the well-designed, marketable app that you want to build.

Then: Build

Assuming you’ve properly validated your app idea and selected the best strategic partner, it’s now time to begin building your app. The process involved can include everything from wireframing and user testing, to visual and interaction design depending on your specific needs.

At Oak City Labs we make sure to have a full feature list in place before beginning development. Then we prioritize the feature list to ensure that the most important things are built first. If budget or time becomes an issue, we always want to ensure that your high priority needs were taken care of in the beginning.

As development proceeds you should expect lots of testing through frequent beta builds provisioned by the development company to your device. And you should expect lots of testing on their end too.

Don’t Forget: Marketing

It would be easy to wrap up this post with the next step and call it a day. But the truth is that successful apps won’t take off and have a hope of succeeding if there isn’t a marketing plan in place. While your app is in development (and, quite honestly, long beyond that), you should be working on and executing your marketing plan. From a website to social media, and even press kits, your marketing plan can make or break your app’s chances for success.

Finally: Launch (& Rinse and Repeat)

It’s the finish line! Well, sort of. At the completion of the build and testing phase of the project, it will be time to launch your app and we’ve created a whole checklist to make this process successful here, here and here.

Once that first release hits the store, you should celebrate! What an accomplishment! But keep in mind that it’s really just the beginning. Following the launch, your app will need to be nurtured on an ongoing basis if you hope to grow your audience (and therefore your business!). You’ll need to address bugs, add new features, adapt to new technology challenges and much more.

As with any business idea, there’s a lot that goes into going from an idea to a bona fide product. At Oak City Labs, we love helping entrepreneurs make their ideas a reality. If you have an idea and think we’d be a good partner for you, we’d love to chat!

Following the success of our last workshop in April, we’re excited to present this workshop again – this time at The Frontier in RTP on July 11.

If you’re considering building a mobile app or are embarking on a custom software development project, we’d invite you to join us for a free workshop next month. We’ll be discussing the most important, yet often most overlooked, step as you begin your project: market validation. We’ll also talk through technology and why it matters.

You’ll have full access to the entire Oak City Labs team for this engaging and interactive presentation, as well as Q&A and networking following the workshop.

We hope to see you there!

July 11, 2017
The Frontier (The Classroom)

  • Registration & Continental Breakfast – 8:30 – 9:00 am
  • Workshop – 9:00 – 10:30 am
  • Q&A and Optional Networking – 10:30 – 11:00 am