So. You have an idea for an app and you want to make it real. First, how do we even get started? There are three common ways to find an agency.
The first is to mine your network. Odds are one of your connections knows someone who works at an agency or who has worked with an agency. From there, find out if your reference had a good experience and if so, ask for an introduction.
The second common way is to find them through their website. In this scenario, you do a lot of searching for agencies that can handle what you want. Generally, your experience will be better if they’re local and if they’ve done something similar in the past to what you’re wanting. Don’t mistake me, remote agencies or ones in distant locations do great work and there are many great reasons to go with them. Reduced operating costs and finding the best talent come to mind. However, some problems are better solved face-to-face or with a whiteboard. Technology can almost bridge that gap, but you will be doing both the team and yourself a favor if you spend at least the first few weeks in-person at meetings.
Also worth noting, there are no great sites which review the work agencies produce. If you find one that’s offering reviews, they’re usually from their best clients or otherwise manipulated. To do your homework on the agency, your best bet is to try to find the people who did projects with them in the past and ask their opinion.
The third common way to meet agencies is with a Request for Proposal (RFP). This is the way of large organizations like global corporations and governments. Likely your company has its own process, so follow it and try to give the best description of the problem you’re trying to solve. For this article, I’m assuming you’re using one of the other two methods, but even for RFP’s much of the advice remains the same.
A little heuristic I’ve picked up over the years: you can tell a lot about an agency by their website. If it’s trendy, then the agency values design. If it loads quickly, the console is free of errors, and when you adjust the page nothing ever looks off; then they value engineering quality. If there are subtleties and animations on the page, they value attention to detail. And if the copy really catches your attention, they must have talented copywriters.
This is a heuristic, so there are exceptions. The agency’s website serves as their best tool to engage the public, so they tend to showcase their best side. If you want specific attributes in your work, look for indicators on the agency’s website.
This is a topic for another article. I want to briefly mention that when building a product, there are four common routes: do it yourself, build a team, hire an agency, or hire freelancers. Depending on your situation, one option will be more appealing than the others. For the sake of this article, I’m assuming you have done the pros and cons and decided to hire an agency.
Whether you found an agency through a connection or through their marketing efforts, your next step is to have your initial conversations. For smaller agencies, this will often be with their founder. It’s also common for this to be with a salesperson.
These meetings are for determining mutual fit. The agency is looking for BANT (Budget, Authority, Need, and Timeline). I’m assuming if you’re thinking of reaching out to an agency, you have the authority and need. The two most common causes for an agency to reject an idea is either you lack enough budget or they lack the expertise with what you’re wanting. That’s ok. There are usually budget agencies or ones with different talents. Keep looking!
When you are talking with the salesperson, ask for case studies in similar domains or with similar technologies. The first time an agency does something new, there’s the overhead of learning. No matter what, any new product requires learning. What you have a little control over is the degree of that overhead by choosing an agency with similar experience to what you need.
It’s also helpful to ask for a demo of one of their apps. A lot can be told by seeing an app operate instead of static screenshots and descriptions of its features. However, it’s also common for these to be covered by a Non-Disclosure Agreements (NDA’s). If they decline due to an NDA, find out what public sites they can refer you to, and then explore that site yourself.
A note about NDA’s: it’s natural when you have a brilliant idea to want to be cautious about sharing it. The thought of bringing it to people who have the technical know-how to pull it off is quite the catch-22. Don’t fear, every agency should be willing to sign an NDA. Even if you don’t go through with an NDA, you can feel somewhat confident your idea is safe. I have never heard of an agency stealing a potential client’s idea and turning it in to a product.
Assuming the agency you’re working with thinks your budget, domain and technologies all roughly fit with what they offer; and you think they can handle the work, the next step is to estimate. You will describe what your app will do and its major features, and the salesperson will get back to you with an estimate of how much it will cost and how long it will take.
To get an estimation started, the salesperson pulls in members of the production side (developers and designers, usually). If a salesperson gives you figures without doing this, they better have the proper background to handle it. If you’re doing something cookie cutter that they’ve stamped out many times in the past, you could get an accurate answer. If the salesperson was a former production member, it might also be accurate. Otherwise, it’s likely fantasy.
Which isn’t a surprise, because even done by production staff it’s a fantasy. People are in general optimistic with their estimations. What you get back will likely be lower than the actual time or money it takes.
The production team members will take the features you want and break them down into hourly, daily, or weekly estimates. Sometimes there are formulas involved. In the end, this time is multiplied by the agency’s rate and you get a total.
Here people are tempted to haggle over resources or services. Commonly they’ll ask for fewer design hours or to scrap Quality Assurance (QA). Both lead to worse products.
The projects I’ve seen that cut design hours usually get incomplete designs of their app. This leads to developers needing to improvise what something should look like. Most developers have little design talent, so you end up with something that either needs rework or looks ugly to the end user.
When you choose to scrap QA, your product will have more bugs and will take more time to complete. No one puts out physical products without running them through some quality assurance, so don’t think of doing that with a digital one. Manual QA is often very cost effective for short-lived projects.
Having said that, many agencies will spend the time to fix those bugs for free. If they fix the bugs produced by not having QA for free, you’d be a fool not to cut QA out of the bid. However, the agency really should offer no quality guarantees when you skimp on paying for it.
The better option for your product and budget is to instead cut out features. Make the tough decision on what belongs in your Minimum Viable Product (MVP) and what realistically fits in your budget. Your product idea is like your dream house list. Chances are it has so many items that you can’t afford all of them. Unlike the dream house list, if you choose and prioritize the right items on your product dream list, that product can make you the revenue needed to get those other features.
You will get back an estimate, then you negotiate a little—maybe you asked for a lower rate, maybe you had to cut features—what’s next? After this you will sign a Statement of Work (SOW) with the company and get your project scheduled!
Often your project can’t kick off as soon as you sign, but usually will in the next few weeks. When it does, you start off in the discovery process. This is where you’ll meet the people working on your product and they’ll start learning the ins-and-outs of everything you want. Many agencies operate in one- or two-week cycles, but either way expect this phase to last a couple weeks.
During this phase, you or a representative will attend a lot of meetings. The first meeting is the sales handoff, where the team working on your product learns what it does. Try to share your excitement and I hope the team is as enthused. The project manager will begin pulling out your major requirements and mapping them to epics.
The first couple meetings will be to get more and more clarity, as well as start providing you some value. This begins as a whiteboarding exercise to figure out how the features you want should fit within your product.
By the end of it, you’ll receive documented requirements; a rough roadmap; mockups, prototypes, and maybe a styleguide or some high fidelity compositions; and the initial source code repository created.
After your first couple weeks—sometimes referred to as Sprint 0—you start to hit the regular cadence of sprints. Each sprint includes a planning meeting, a demo, and a retrospective.
During sprint planning, the team estimates your highest priority items. This estimation helps them plan and after a few sprints they’re able to predict how many items they’ll complete. This knowledge lets you know whether you’re on track or not. This is also the time where the team clarifies requirements to make sure they build it right.
The demo is a chance to show what’s been completed that sprint. Each member of the team should have an opportunity to present what they’ve done, even if it’s some behind-the-scenes work which doesn’t make a visible difference. This is usually a feel-good time where you get to feel the progress in your product and those who did the work get to feel a little bit of accomplishment for the week.
Finally, the retrospective is a chance to figure out what’s going well in the project and what is going poorly. By having an open discussion, the team can focus on improving sprint after sprint.
As a client, you should try to attend all of these meetings. In planning, you will be needed for clarifying and prioritizing. It is your product, and if you don’t attend it can start going in a different direction than you want. The demo is your chance to see what’s been done and give feedback that the team can learn from. If you are going to miss a meeting, the retrospective should be the one. However, your input on how things are going—maybe you don’t feel consulted enough or you’re worried about the timeline—is valuable and can result in a better experience for both you and the team.
Production continues like this for many sprints until your product is ready to be released. Remember what I said earlier about most estimates being optimistic? Well, there’s a good chance the team is behind schedule. If you have a deadline, hopefully you’ve been prioritizing along the way so that what you have by the deadline will be presentable. If you are running out of budget, many agencies will continue the work until it’s done so long as you’ve performed your part and not held up the team’s work.
You’ve got every feature needed for your initial release and it’s bug-free. The next step is to release your product to the world. Product agencies don’t often offer communications and marketing plans for the release. They only deliver the product needed for it.
However, marketing and communications plans are critical for your product’s success. While the product is in development, you should be developing a plan around it going live and should already be releasing content about the product and its domain. Even the best products fail if no one finds them.
If you do it right, you should have a list of users ready to go and an audience for your release announcement. Many product agencies know and can refer you to good marketing agencies, so make sure to ask early on.
You have a few options here after the release. Sometimes there’s still budget and things needed to be done, so the team continues working. This is the ideal scenario.
More regularly, the budget has run out, and we need to see the product gain traction and start generating revenue. This can take a few months, but keep in touch and the agency should also be reaching out to you to make sure everything is going well.
Truthfully, the agency wants to see you succeed because if you do, that’s more opportunity for work for them. So if you have bugs or problems, reach out in a cooperative manner and the agency may fix them for free, even if they didn’t guarantee their work. Remember, they’re a partner and if you succeed, they succeed.
If you do start earning revenue, you’ll find after a few months you have another list of things you’d like done for your product. This is a good time to go back and get another bit of work estimated and an SOW signed.
Eventually though, the demand for work and revenue usually supports building a full-time team. This is an exciting time for you and the sign that your product is now becoming a real business. Discuss with your agency a transition plan and begin rolling off their team members for your own.
You may even be able to hire team members from the agency that you’ve been working with for months, but make sure to keep on good terms with the agency leadership. Usually you sign a non-solicit, but I’ve seen it happen enough times to know agencies don’t usually stand in the way if everyone is happy.
This is what the lifecycle of a product with an agency is like. There’s stressful times and exciting times throughout. The best feeling for everyone is when your product comes out as you imagined and begins to take off. I love working at agencies because I get to see this many times a year with many different clients. If you are thinking about going to an agency and have questions about the experience, contact me and I’ll be glad to offer my advice.
Zach Kuhn is a Director of Development at Smashing Boxes, a Durham, N.C.-based digital agency. He has built web and mobile apps for over a decade, and is involved with startups and emerging technologies like blockchain, IoT, and machine learning.