5 Tips on Starting a Business

So you want to start a business. Great! But where do you start? It certainly won’t be easy, but with a lot of drive, a little luck, and some savvy, you can maximize your chances of turning your dreams into a successful entrepreneurial endeavor. Here are our top tips for starting a business as smoothly as possible.

1. Choose your co-founders carefully.

More carefully than you would choose a spouse. You’ll be spending a LOT of time with your co-founders (probably more time than your actual spouse), and if things go sour and you find you simply can’t work it out, a business divorce is even worse than a regular one. You can’t split the custody of your startup.

2. Invest in a good lawyer, a good accountant, and good contractors.

You may be hesitant to spend a lot of money on these when you’re first starting out and cash isn’t flowing yet, but having professionals on your side from the get-go will save you headaches in the long run. A quality lawyer and accountant will help you set up your business properly and legally (and save you money on taxes), and quality contractors will ensure that your work gets done right the first time. (For more tips on saving money in the early years, check out our article on keeping costs down.)

3. Start small!

A business is a risk, so don’t invest too much too early. Come up with a hypothesis and test it with a small product that solves the biggest problem, not every problem. If your experiment has lackluster results, figure out why and be honest with yourself about how fixable the issue is.

4. Create a detailed plan.

Work out the kinks now, and be realistic about what you can get done. Simply believing that everything will work out isn’t enough; plot out exactly what success will look like and the steps you will need to take to get there. But! Make sure you’ve done tip #3, because creating a detailed plan for a sprawling project is a recipe for never getting started.

5. Don’t reinvent the wheel.

Instead of trying to invent an entirely new category, improve upon something that already exists; it’s often easier to be successful this way. Keep it simple.

What do you think? Have any tips of your own to add to the list? Leave them in the comments! And as always, feel free to drop us a line with inquiries, suggestions, and/or love notes. We’re always happy to hear from you.

,

Mobile App Startups: Tech Stack

Thryv gets many questions about this, especially from startups who are still looking for technical co-founders. Where should you start? What technologies are easiest to recruit for, and what are their tradeoffs? Well, this article should give you a good starting point.

Server

Your server is where you store all the data that needs to be displayed. Almost every startup will need a server.

The in-vogue thing to do at this point, especially if you’ll be building both a website and an app, is to build a JSON API that sits on your server. JSON is a common format for communicating between different types of applications, and an API is a set of capabilities that an outside application can utilize.

With that in mind, the question is often this: what’s the best way to build a JSON API? There are several options.

Ruby on Rails

Ruby on Rails, or simply ‘Rails,’ is a very common and reliable technology. Rails has the advantage of being quick to setup. It’s generally pretty easy to add features to a Rails API, and there are tons of developers who know how to use Rails. The disadvantages generally come as you get larger; Rails does many things for you, so doing more specific things can start being more trouble than it’s worth. That said, the speed you gain at the beginning can often outweigh the costs down the line, and many prominent companies use Rails at scale.

Node.js

Node can be a very advantageous technology to use, especially when the developers who are helping you work primarily on the ‘frontend’ of your website/app. Node uses javascript, which is a vital frontend web technology, but it uses it on the ‘backend,’ meaning that developers who generally work on one can easily get up to speed on the other.

Python (Django or Flask)

Python is a beloved programming language in many circles. Building websites and APIs in Python is enjoyable for many developers because it is so easy to work with. It also has some advantages in raw speed without sacrificing much in the way of development velocity. However, it doesn’t have quite the same developer pool as javascript, and it can be a bit more work than Rails to get something up quickly.

Database

The most common database format at this point is probably PostgreSQL. Postgres, as it’s colloquially called, is robust and professional, and belongs to a family called ‘relational’ databases. It can be a little tricky to setup, but it’s the workhorse of many modern server applications.

For specific types of problems, a non-relational database may be preferable. In those cases, MongoDB is probably the most popular choice.

App

When building an app, there are tons of choices. In Thryv’s opinion, though, there are only three good ones.

Going Native

This means programming in Objective-C or Swift on iOS, or Java or Kotlin on Android. Going native gives you the highest potential for a quality app. iOS and Android phones are built and optimized to run native apps well, so they’re always a safe bet, especially when you’re targeting only one platform to start. However, it can be difficult for small teams to rapidly iterate on two separate platforms, in which case it may be wise to consider a cross platform approach.

React Native

React Native is the latest in mobile development from Facebook. It allows you to quickly build native looking apps on both iOS and Android at the same time. Moreover, since it’s in javascript, you have a large pool of developers who can work on your app. There are, however, downsides. React Native does not match native performance, and there are certainly things that are difficult to do with it. Additionally, since it’s a part of the javascript ecosystem, things move very quickly, which means they break often.

React Native, in our opinion, is a classic high risk/high reward technology.

Flutter

Flutter is a new cross platform framework from Google. There are some large technical differences between Flutter and React Native, but they break down to two things: speed and styling. Flutter apps, due to Flutter’s architecture, will run smoother and probably be easier to build than React Native. That said, Flutter limits you stylistically: if you like Google’s Material Design then it will be a fast, easy to use option for you, but if you want to deviate from Material Design, you may want to consider React Native instead.

Web

There are so many options for building a website today. Most startups generally need at least a landing page, but if that is, in fact, all they need, there are a myriad of solutions that they can use: WordPress, Wix, Instapage, Squarespace… and many, many others. If you need to build a dynamic website, there are a few technologies people generally use. All the technologies mentioned in the Server section apply here, but it can be difficult to make them work with an API as we described. As a result, we recommend React for your dynamic website needs. React is the foundation on which React Native is built, so if you’re building your app in React Native, you maybe able to share code between them. Otherwise, you may also consider a framework called Angular. Both allow you to build beautiful, modern websites with the highest level of flexibility.

Infrastructure

Where should you host your web properties? There are two places we generally use (and, in fact, one is built on top of the other).

Most startups eventually move to Amazon Web Services (or AWS for short), and any tech person you talk to will have heard of it. AWS offers a lot of flexibility, and is excellent at helping you keep costs down. Unfortunately, it can be hard to setup, and there are so many knobs and buttons to tinker with that it can be quite intimidating.

For this reason, we often recommend that startups start out using Heroku, a Platform as a Service (PaaS) offering built on top of AWS which takes care of most of the configuration for you. Your developers will be able to easily deploy your code with few tradeoffs when it comes to performance and cost.

Need help?

Do you need help deciding what kind of tech stack you should go with? Then contact us! We’ll be delighted to chat with you about what you need, and help you get it done.

Keeping Startup Costs Down

Whether you’re funding your business yourself or seeking investors (for more on the pros and cons of each, check out our article on the subject here), it’s always a good idea to keep costs as low as possible when you’re first starting out. Here are our tips for saving some cash so you can get the most out of your business in its beginning stages.

 

Don’t hire employees until you absolutely have to.

In your first year, do as much of the work by yourself as possible. This will allow you to get to know your business inside and out, so by the time you do hire people, you’ll know exactly what you need from them. Many of the specific tasks you’ll need help on won’t come up often enough to occupy the time of a full-time employee, so hire contractors for those tasks when they do come up, or hire one multitalented person who can take care of many tasks. But don’t hire out the hard parts of your business until you’ve figured them out for yourself–if you pass these tasks off, they could be fixed inefficiently and you’d be none the wiser.

 

Work remote.

Online businesses often don’t need a physical location (especially when it’s just you), so you can save money on office space by working from home or anywhere with an internet connection. Doing this will give you a lot of extra cash and an edge on your less-frugal competitors.

 

Don’t cheap out on contractors.

As the saying goes, “If you think experts are expensive, wait till you hire an amateur.” If you’re going to hire someone to get something done, get it done right the first time, rather than many times cheaply. Sometimes cutting costs means investing in quality work up front.

 

Get a good lawyer and a good accountant.

Lawyers are always going to be expensive (use them only when you need them!), but again, investing in quality will end up saving you money in the long run. They can save you hassle by keeping you on the right side of the law as you set up your business, can write contracts to protect both you and your employees, and, when used in conjunction with a good accountant, can structure your business in a way that can save you a lot of money on taxes.

 

Follow these tips, and you’ll be well on your way to entrepreneurial financial freedom. Best of luck! And if your business needs an app, give Thryv a call–we’re happy to help.

7 Mistakes People Make Trying to Find Technical Co-Founders

Finding a technical co-founder is hard, and every startup is different, so it’s difficult to say what you should do to recruit one (although we’ll be trying in a different article). On the other hand, it’s pretty easy to say what you shouldn’t do. Here’s our list of 7 mistakes people make when looking for a technical co-founder.

1. Ask them to “build it for you”

This is the most widespread and pernicious of mistakes, and easily takes our top spot. And it betrays a fundamentally insulting way of looking at your relationship with a developer.

If you’re looking for a technical co-founder (which you are, even if you’re just looking for someone who will build the product for equity), then you need to treat them like a partner. They have a valuable skill that you don’t, and their experience will allow you to not just create the product in the first place, but create a better product than you would on your own. You can’t treat them as though they are a completely interchangeable code monkey and expect to get a loyal, passionate partner out of it.

If you just want someone to ‘build it for you,’ then you’re not looking for a technical co-founder – you’re looking for a hired gun. Unfortunately, hired guns don’t work for free, and you need to be prepared to shell out a fair amount of money to have someone execute on your vision. There’s nothing wrong with that approach – it’s a large part of Thryv’s business – but it’s a mistake to treat a potential partner like a freelancer sans monetary compensation. Developers aren’t dumb, and, by and large, you won’t be able to just trick ‘some dev’ into making you rich in return for scraps (which is exactly how it can sound when you take this approach).

2. Ask for an NDA before talking about your idea

There’s nothing that screams ‘novice’ like asking for an NDA before talking about the idea.

It’s not that NDAs aren’t important – they are – but they are generally only relevant once you have a product, not when you’re still in the ideation phase.

When all you have is an idea you want the opposite of an NDA. You should be shouting your idea from the rooftops asking for feedback. You need feedback, you need people with experience to tell you what they think. Is it feasible? What do I need to build it? What haven’t I thought about? What problems am I likely to encounter? Are there competitors I don’t know about? What kind of timeline should I expect? These are all questions you’ll want to answer before attacking the problem in earnest, and if you demand an NDA before asking, you’re never going to get the answers.

“But isn’t that dangerous?” you ask. “Won’t someone steal my idea?”

No, and no. There is almost a 0 percent chance your idea will be stolen, even if it’s amazing. Why? Because the idea is one of the least important factors in success – and it’s important for you to come to terms with that. The execution, the team, the timing, the advisors are ALL more important than the idea itself. Those things also happen to be the hardest parts to get right, so until you show that you have gotten them right, no one will try to steal your company.

3. Over hype your idea

Inspiring the people around you is a vital part of business success. Over hyping, though, will actively repel potential partners.

No one is inspired by someone saying ‘this is a billion dollar idea!’ or ‘this will change the world!’ They become inspired when you tell them why – and when you show them it’s possible.

As an example: the concept of high speed transit between large cities has been around for a long time. So why was the Hyperloop so interesting? Because Elon Musk and his team wrote a whole report on how it could be done, along with realistic estimates of what sort of impact and possibilities it might entail. Strive to do the same with your own ideas.

4. Expect them to work for free

The key word here is ‘expect.’

When you’re starting out, you will almost certainly be cash strapped. You want to find someone who will help you make your idea into reality, and you can’t afford much at this point. Moreover, you want to work with someone who is as excited to work on the idea as you are. What are you to do?

Well one thing you mustn’t do is go to a developer and expect them to work for nothing. Any experienced developer has 1.2% of some failed company in their back pocket – adding another chunk of worthless equity has exactly zero appeal. It’s your job to draw them in over time, and one meeting where you tell them the idea won’t do it. A great way to get them to fall in love with the idea is give them exposure to it, with a monetary incentive to get them in the door. If, once they’ve seen the potential by working on it a bit, they want to join as a partner, then you can talk about equity only compensation – but no experienced developer will commit to something unproven, free of charge, after one conversation.

5. Act like your idea is unique

…because it almost certainly isn’t. Perhaps a part of it is, but that’s not the point, and it’s not what makes it valuable. Ideas are a dime a dozen; there are lots of ways to solve any single problem. What you need to do is show that the way you’re going about it is viable, and that you have the wherewithal to get it done. Moreover, thinking your idea is the only one in this space is almost always naive, and pegs you as a beginner – no one wants to work with a beginner.

Work hard to find other examples of similar ideas succeeding, or if they failed, find out why – and explain how you’ll avoid the same pitfalls.

6. Not doing research

If you’re looking for a technical co-founder, there are tons of questions that you need to answer. Even if you’re not technical, you need to have done some research about what you need to bring your idea to fruition – and be able to speak intelligently about your thought process.

This may sound like a chicken/egg sort of situation – if you need technical expertise to attract a technical co-founder, how are you ever supposed to do so in the first place? One way is to find a technical advisor who, while they’re not going to build your product, can point you in the right direction. Ask them what the critical decisions are, and what the trade offs are for different approaches. Consider your options, do your research, make some tentative decisions, and use that as a foundation on which to build your search for a partner.

7. String meaningless buzzwords together

No one is impressed with buzzwords. Buzzword salad immediately identifies poor partnership choices for many developers.

The most important part of any business is the problem it’s solving. Start with the problem, and build from there. If new technologies have enabled a novel solution to an old problem, all the better! But keep the problem at the center, and don’t use buzzwords if possible. People who know them will pick up on it and get a bad taste in their mouths, which makes for an uphill battle when trying to recruit them.

What do you think?

Anything we missed? Leave it in the comments. Have an idea you’d like to discuss with us, or need some advice? Contact us!

,

Decreasing Bias in Hiring Technical Roles

Many tech companies are not terribly diverse. There are a lot of reasons for this, but today, I’d like to talk about some of the ways bias creeps into hiring, and what to do about it.

Coding Challenge Format

The standard whiteboarding technical interview is completely broken. It tests for skills that are practically orthogonal to modern software engineering – when a company I work with requires me to evaluate candidates based on a whiteboarding interview, I routinely walk out of them having no idea whether the person I just spoke to will be good at the job I need them to do. Few companies need programmers who can write code in high pressure environments, by hand, on a whiteboard, in front of an audience of other developers whose job is to pass judgement.

However, many companies do need developers who can translate business requirements into code, use the best tool for the job, and integrate it into existing codebases. Luckily, testing for such skills is pretty straightforward. I ask candidates to add a feature to a dummy product that is related to the business of the company hiring them. In this way, you can test how the candidate would write code in an environment that’s similar to the one they’re entering.

Now, whiteboarding is supposed to test for ‘problem solving,’ and many programmers would complain that this format takes away that part. So, I usually try to add some sort of twist to give the candidate a challenge or two so that we can evaluate problem solving as well as platform knowledge.

Evaluation

Another issue with whiteboarding is that it’s often biased in favor of white males. People have implicit expectations of who will be right and who will be wrong, and what a good programmer looks and sounds like. All of which has nothing to do with actually writing code!

There are plenty of examples where even submitted code gets analyzed in a more or less harsh manner depending on whether the name/screenname appears masculine or feminine.

To mitigate this aspect of the process, it’s important to anonymize the candidate’s submitted code before evaluating it. I like to have the team review it with no names or other gender/ethnicity signifiers and then either have a conversation about, or numerically score it on various agreed upon criteria. Forming a ‘blind’ opinion helps inform the decision once the person comes to meet the team.

Culture

Having concluded the technical evaluation, it’s just a matter of determining cultural fit, which varies by company. In addition to the standard reference checking, I find it important to get to know the candidate outside of a work setting and ask them some questions on something they’re opinionated about. The key here is to see how they respond to that probing, and how well they can take into account someone else’s point of view – empathetic employees can almost always be reasoned with. If possible, I try to get people with several different backgrounds to meet with them, to see if they treat different groups differently. In this way you can not only hire diverse folk, but develop a culture that welcomes people from diverse backgrounds.

 

,

Mobile App Startups: Where to begin?

So, you have an awesome app idea. What do you need to make it a success? What are your first steps? What are the components you need to build for it to grow?

Generally, you need to decide on a strategy on three fronts: capital, marketing, and tech. We’ll be doing more in depth articles on each of these, but first, let’s talk about what they are and why you need to think about them.

Your capital strategy basically relates to how you’re going to pay for things, or perhaps more accurately, who is going to pay for things. There are two main categories for this: either you pay for things yourself, or you get someone else to. There are advantages and disadvantages to both, and huge challenges as well. This is one of your biggest decisions, because it may entirely determine your strategy in the other two areas.

You need a marketing strategy because you need to build buzz long before your app comes out. Being able to show interest in your product can also help with raising capital and attracting a tech team. Finally, it can help you find early testers who will give you feedback before you go primetime – which is invaluable.

Lastly, your tech strategy. What technologies will you use to build your app? Who do you know that builds with those technologies? What do you need to think about as your app grows? How much will it cost at the beginning? How will that cost grow with your app’s popularity? Realistically, how much use will your app get? These are all important questions that will shape your tech strategy.

Thryv has helped many startups develop their strategy in all of these areas. We’ve seen it all, and are intimately familiar with the pluses and minuses of each approach in each category. Do you have a question? Get in touch with us and we’d be delighted to talk to you about what you need to do to get your idea out there!

,

Mobile App Startups: Raising Capital

This topic is one of the most opaque for many entrepreneurs, and is different in every case. Some general paths can be described, though. There are two main options: using your own money, or using someone else’s.

Using your own money

Using your own money is generally referred to as ‘bootstrapping.’ Often, because it’s their own money, entrepreneurs spend less overall when bootstrapping than when running the business with investors’ money. This can express itself in many ways: keeping your day job and building your business after hours, paying people in equity, not having an office, and doing as much as you can yourself.

The advantage of bootstrapping is that you don’t owe anyone a return on their money, so if things drag on and on, you don’t have a bunch of investors breathing down your neck. You can take your time, build slowly, and make unhurried decisions about your business. It’s hard to run out of money when you’re not spending any (or spending very little).

The disadvantage is that often, quality is expensive. Paying people in equity is not always an option, and indeed, it usually isn’t for people who know what they’re doing. You either have to take a risk on someone inexperienced, pay a lot of money out of pocket, or do whatever it is yourself. None of those are necessarily bad things for your business; they’re just either risky or unpleasant.

Finally, for many entrepreneurs, a problem with bootstrapping is that it isn’t glamorous. Don’t fall into this trap! Just because your friends won’t be impressed by your after hours project doesn’t mean you should try to raise money from venture capitalists. Be aware that your ego could try to convince you to do things that are Bad For Your Company, and try to look at your situation dispassionately.

Using someone else’s money

 

There is a standard path that startups go down when looking to raise institutional capital.

Usually, it starts with what’s descriptively called a ‘friends and family’ round. Predictably, it involves asking your friends and your family for money in order to make your idea a reality. Parents, rich uncles, that lawyer friend of yours are all fair game. You’ll probably want to prepare some designs of what your app will be, since it’s always easier to support something you can see. This round will most likely involve getting money in convertible note form – basically a loan that turns into equity if things go well. This way, you can give your investors some piece of mind that they’ll get their money back if things go poorly, but also get a piece of the company if it takes off.

After using up the money your family and friends gave you on building a prototype of your app (we have lots of blog posts about how to do that correctly), you will hopefully have some sort of success. You’ll then start wanting to talk to Angel Investors. Angels are high net worth individuals who will give you something in the five to six figure range to get your app ready for prime time, add more features, or simply scale up your operations. They’ll take equity, and depending on the Angel, want some sort of input into how the company is run.

Finally, you may get to a point where you want to talk to the heavy hitters: Venture Capitalists (VCs for short). VCs really don’t care about you unless you have 10 million users or $1 million in annual revenue. They’re wanting to make big investments for a huge return – usually they’re looking exclusively for potential billion dollar businesses. If you can’t convince them that your market is large enough to support a billion dollar business, and that YOU are that business, they won’t be returning your calls.

VCs typically make investments in the seven to eight figure range and expect a lot of equity. They also want a lot of control over the company, so that if they think you’re doing a bad job, they can take it away from you. VCs can be like dealing with the devil, but they can also be amazing resources. They know tons of people who can help you, and are heavily invested in your success.

Conclusion

This is a deep topic, and there are a multitude of books written about it. And to be clear, these paths aren’t terribly clear cut, so you can mix and match as necessary. Regardless, Thryv is here to help every step of the way; we’ve seen it all, so take advantage of our experience and get in touch!

Getting Your App Built: Hiring vs Contracting

 

In our last post, we walked through some pros and cons of using an individual contractor vs. an app development shop. What if you think you want to hire somebody longer term? When should you think about hiring a programmer to work for your company instead of hiring a contractor?

Hiring a programmer in-house

Pros of programming in-house:

  1. Familiarity – If you employ a programmer, they will become familiar with your product and codebase, which can streamline development. Additionally, they will become familiar with your company culture and you will become familiar with their working style, which can improve communication if you are a good fit.
  2. Long-term solutions – An in-house programmer will be more likely to think longer term because they know they will anticipate with you a year from now. (Note, however, turn-over in tech positions is much faster than most other industries, so maybe don’t expect them to be there 3 years from now.)

Cons of app programming in-house:

  1. Time – Hiring will typically take months and months to execute. Most people who are unfamiliar with the process dramatically underestimate how long it takes to find a programmer to hire full-time. Industry wisdom says that there are 5 job openings for app development for every one programmer. Consider how you’ll compete with other companies if you want to attract top talent. Not only do you need to offer a generous compensation package, but programmers also like to choose companies they find interesting because they have the luxury of choice.
  2. Expense – Competing to attract a quality programmer will require a lot of money. If you want to hire a senior developer who you are sure can see the big picture, solve complex problems, and build a strong foundation, you’re going to need to dig deep into your pockets. If you take a gamble on a more junior developer, you risk that person getting way out of their depth when they run into bigger problems. If a junior developer doesn’t write clean code, you’re going to end up paying a lot more for somebody to go back and fix or redo what you already built, if you have to add more functionality later.
  3. Uncertainty of Quality – It’s difficult for most people to tell if a programmer is any good. You can look at past work and past employers, but there is only so much certainty that can give you.  A computer science degree from 5 years ago can approach irrelevance in today’s fast-moving, constantly changing landscape.

Contracting with an app development shop

Pros of a development shop:

  1. Dynamic scaling – If you need a lot of horse-power now while you build a prototype, you can get exactly that. If later on, you just want maintenance and some small new features, you can get exactly that. Working with a app development shop means you can scale up and scale down at will.
  2. Accurate pricing – With the right shop, you’ll pay a lower rate for basic code and a higher rate for app architecture and big-picture problem solving. Different development tasks require different levels of expertise. With an app development shop, you only need to pay for expertise where it is really required.

Cons of an app development shop:

  1. You get what you pay for – If you choose to work with a very inexpensive development company, you risk ending up with poor-quality work that nobody can build from in the future. An overbooked company may build something that minimally meets your requirements, but will fall apart if you try to add anything or make any changes later on. You should also watch out for companies that don’t make you a priority. You need your development team to take your deadline as seriously as you do.
  2. Uncertainty of future relationship – If you alienate your development team, they can choose to stop working with you. If you are constantly adding features not in the original contract or if you are late on your payments, a development shop does not have to put up with you beyond fulfilling the current contract. 

An in-house developer can feel like a terrific luxury, but you have to be prepared to spend time and money finding the right person. Contracting out to a development shop allows you to get exactly the level of work you need, for an accurate price. That means you can get your prototype out quickly and then fine-tune as needed down the road. Considering the resources you would like to devote at this time will help you make the right decision for your company. 

Thryv is here to help.

Choosing App Development Services: Individual Contractor vs. Development Shop

Your business needs an app. You’ll need specialized help to build this app, but before that, you need to know what kind of help you need. Hiring the right person or company to build an app can be daunting. It’s also something that is best done right the first time.

Let’s begin with a very basic question: Do I need to find the right person or do I need to find the right company

You have a lot of options. Matching your business needs to the right development choice will get you the right work for the right price, so let’s examine the pros and cons of an individual contractor vs a development shop. 

Individual Contractor:

One person, who can take your app from architecture to visual design to programming to setting up a server and then making it all work together.

Pros:

  1. You will probably under-pay for some aspect of development. A single contractor will be doing many types of tasks, but an hour of app architectural design would normally cost more than an hour of bug-testing. Since the contractor probably gives you one average rate, some of their work will be a bargain.
  2. It’s easier to get on the same page if you’re only working with one person. If you already know exactly what you need, then you only need to make one person understand. An app development company may give you a project manager to translate your vision into different tasks and explain those to others, but that might be overkill if you already know exactly what needs to be done and just need somebody to execute.

Cons:

  1. You will probably over-pay for some aspect of development. If you are paying an average rate for all development tasks, you’re probably paying too much for some of the more basic tasks.
  2. It’s hard to find one person qualified to do everything you need. Everybody has strengths and weaknesses. When you hire a lone contractor, you are paying for them to use both their strongest and weakest skills. Finding somebody whose weakest skills are still good enough for your project will take time and discernment.

App Development Shop:

A team of people who work together to build your app, each acting within the area(s) of their own expertise to deliver an expertly-crafted product to fulfill your needs.

Pros:

  1. You will have the right people working on the right parts of your project. You can have a project manager to understand what you’re doing, an architect to structure it, and junior developers to write clean code that you can build from in the future.
  2. You have a whole team of experts to make sure you have a strong foundation. A team has more internal accountability and may be less likely to do slap-shod work that nobody else can build from or understand. If you think you will ever want to add to or improve your app, you need to make sure that there is more than one person in the world who could possibly understand the structure of the code.
  3. You can get projects done more quickly. This is common sense, but is worth stating. If more people are working on your app, they can finish it more quickly. If your deadline needs to be moved up, a development shop is more likely to be able to apply additional resources and get it done.

Cons:

  1. You have to trust the company you are working with. If you don’t have enough experience building apps to feel comfortable with just a single contractor, you need to find a company that is capable of taking your project from idea to reality with less input from you in between. That’s a big responsibility and you should find a company you feel good about. 
  2. Big development shops only want big clients. Smaller development shops are definitely an option for almost any size app, but the big development shops mostly work with large corporations. Keep an eye out for our upcoming article on how to know what size development shop is right for you!

An Important Choice

What type of development provider you go with is an important decision to make, but also very dependent on your situation. Review your options, and keep these factors in mind to make the best choice.

Requesting new features for your app

Asking for new or different features in your app can be easier in some cases more than others. If you took our advice in Fixed Price vs. Time and Materials this just comes down to normal courtesy, politeness, and thinking things through. If you didn’t take our advice and signed a SoW with a strict, fixed scope, then this can be a huge issue which needs to be navigated carefully. Regardless, the process starts out the same, and it starts out with you.

Step one: Customer discovery

Do you really need this change? Have you validated it with your customers? How important is it to make this change? Making changes in the middle of a project can be dangerous, so doing at least some light research into how much you need to make the change is critical.

Step two: Business discovery

How hard is it to make this change? How much time will it take? How much will it cost? Businesses can often be surprised by how much work and money it takes to make what may seem to them to be a relatively simple change. Make sure you discuss such things with your development provider to determine what kind of complexity you’re dealing with, as this often affects whether you want to commit to it.

Step three: Timing the work

You’ve decided that you definitely need to make this change, and you’re comfortable with the difficulty level. Now the question is, when do you do it? Sometimes changes make more sense to do later, and occasionally even after launch of the product. It may also be easier to make the change after some other work is completed, which could save you time and money in the long run. As before, communicate with your development provider to fit the change into your development schedule.

Step four: Contract considerations (optional)

If you have a fixed price project, you’ll want to amend your SOW or, potentially, get a new SOW altogether if the change is large enough. This is one of the downsides to fixed price projects, since a) lawyers are expensive, and you may need one to review the new scope, and b) if the change needs to happen immediately, this process can really slow down development.

Every project will involve changes in scope and features, so keep this in mind when you’re considering signing a contract with a fixed scope, as it won’t truly reflect the reality of development. Regardless, if you follow these steps, requesting new features and changes to existing features will go much more smoothly for everyone involved.