The do’s and the don’ts of working with a remote development agency

As a first-time entrepreneur and solo-founder looking to launch a start-up, are you are probably looking at retaining a development agency. The excitement that comes with launching your new business as soon as possible will push you to make a rushed decision to hire either the cheapest agency, or the one that has been the most responsive to your questions and concerns. When you retain a development agency, you are putting them in full control of your product and timeline’s fate; they can make or break your start-up.

Before I start sharing my thoughts on remote development agencies and how to manage them, remember that they are a for-profit business and they only make money as long as you remain their client; so, it is important to always keep in mind that your interests aren’t aligned.

You, as a cash-constrained start-up founder, are looking to spend as little money as possible for a reliable and bug-free product. On the other hand, the founders of the agency that you have retained know that 9 out of 10 start-ups fail; so they are probably not so excited and motivated by your product’s potential. They are mostly interested in maximizing the number of hours billed, in as little time as possible before moving into their next project. Below are some of the tricks they use to maximize their earnings at your expense:

Phase 1: Discovery & Proposal

If you have never founded a start-up before, and are not sure where to begin your search for a development agency, you will either google “website or app development in [city]” or go on Upwork. When I decided to start CarHopper, I did a simple google search and set up meetings with the first companies listed in the first 2 pages that got back to me the soonest. Amongst the five companies that I met with, one called SdSol Technologies stood out to me the most. They were located two miles away from my apartment, had an office in a fancy building, and their young employees just gave off good vibes. When I walked into the meeting and explained them the product that I was envisioning, I was tricked into thinking my idea was not perfect enough for the market, and I naively allowed them to “guide” my vision, which ultimately resulted in them defining my product. As a naïve, first time entrepreneur, I did not realize that they were trying to optimize their number of hours to be billed for the least amount of challenging work possible. After the meeting, they managed to send me a work-order within 2 days. I should have known that everything was too good and simple to be true. I was presented with a work order broken down into 4 standard sections: wireframes, UI, coding, and maintenance & support; with each phase to be pre-paid upon start.

Phase 2: Wireframes (1 month)

Story: My adventure started with a process called “wireframing”. This standard process determines the logic of a site and the functionalities it needs. Think of it as the architectural blueprint of an online store. Once I pre-paid for this phase of the project and we came close to the end, I was informed by SDSol that they had underestimated the number of hours required to complete the development work and that I either had to pay an additional $10,000 for the second phase of the project (although I had already signed the work-order broken down into 4 parts, with a grand total), or they would not be able to complete the work nor issue me a refund issued for the first phase that I had pre-paid. After a lot of back and fourth and no progress being made, I consulted a lawyer and was told it would cost me more money to sue them than forget about the amount I paid and move on.

Do’s:

• Ask to speak with at least 3 clients the agency you are prospecting has worked with.
• Take your time and compare hourly rates and total costs from different agencies, do not rush.
• Add a clause in your contract clearly stating that the agency’s lack of proper budgeting of hours required to complete the project does not entitle them to unilaterally change the terms of the agreement and features of the product

Don’ts:

• Do not let an agency define the first version of the product you are envisioning
• Do not pre-pay for the entire phase of a project, do pay based on mini-milestones

Phase 3: UI (2–3 weeks)

The UI phase is typically the most exciting one as you will finally start seeing your project come to life. It is in this stage that your product will start having its own brand identity with specific colors, designs, and fonts. It is very important to not heavily invest in your brand identity too early on as this should be established based on who your audience is (i.e age group, predominant gender, income, education etc.); you may have preliminary assumptions on who your product is for but the reality may be completely different.

Story: We first launched CarHopper as peer-to-peer neighborhood carsharing platform targeting millennials. Therefore, our colors had to reflect youth and energy and our visuals were very “Lego-like”. However, we had to change our entire branding and messaging when we found our product-market fit in a different vertical of the carsharing/car-rental ecosystem: high-end cars!

Do’s:

• Ask to pay for this phase based on number of unique page-designs needed.
• Test your product-market fit before investing too much time and money on design
• Focus on simplicity
• Create UI that is easily adjustable in case your business model and messaging needs to slightly shift
• Try to buy already built design templates if you can (until you prove the product-market fit)

Don’ts:

• Do not let the agency dictate you how many unique page-designs you need (some page designs can be used across different pages with very minor changes, do not let them charge you for more than you initially need)

Phase 4: Coding (2–3 months)

This will be the most complex and lengthy phase of your initial product development journey. It will essentially connect the designs to the logic that was created in the wireframing phase. Expect your developers to go on silent mode for a few weeks (this is normal) as by this point they received everything needed from you (logic, features, designs etc). Also expect them to start getting a bit more antsy and frustrated with you.

Story: As the coding phase of developing CarHopper was coming to an end and I was finally able to see the UI and the UX together, I was able to start testing it and realized some pages in the booking flow did not make sense and needed to be either revised or removed. This was primarily due to the developers adding more page-designs than needed (to charge me more) which was essentially complicating the booking and payment process and causing bugs. When I asked for revisions to some pages and funnels, I was faced with much resistance based on the pretext that the changes would require more hours than initially planned. Though I can certainly understand that time it is not ideal to request changes to a product when it is close to an end, it is important to remember that it’s exactly why the second phase (UI) of the development process should be kept as simple and clean as possible.

Do’s:

• Keep the pages, logic, and funnel as simple as possible in the first version of your product to avoid revisions later.
• Communicate your change requests as early as possible with your developers.

Don’ts:

• Do not stay quiet if you are not 100% satisfied with the functionalities and features on your site/app. You only get to launch and leave a positive first impression once.
• Do not fight or create friction with your developers, it is too late to start working with another team, you must remain firm but kind and respectful.

Phase 5: Post-launch & support hours (ongoing)

If you were thinking that you would be done working with your developers once the “final” version of your platform has been submitted for your approval, then you are wrong. The real money-maker for development agencies is this very phase.

Story: I had spotted a ton of bugs and error messages across the website and app once CarHopper’s “final” version was sent over to me. When I had asked our developers to fix these bugs and logic issues prior to releasing the product to the general public I was told that they can only be fixed under a separate agreement and that since the basic flow work they considered the scope of the project that we had agreed upon to be completed. As a first-time entrepreneur and someone that had never worked with a remote development agency I naively agreed and signed a new agreement for “maintenance, management, and support” of the platform. This was an hourly agreement and any improvements (bug fixes, new features, revisions etc) to the platform would be subject to this new agreement’s terms. I later realized that so many items that I (as a first-timer) assumed were “obviously” covered under the first agreement were purposely left out of it. Some of these items were:

• Outcome for alternative actions takings place on the website (i.e: what happens when a payment gets declined, what happens if the same car gets booked twice etc.)
• Insufficient functions of the administrative panel (i.e: I did not have enough visibility on the users, cars, and transactions using the admin page)

Right when I thought that I would finally stop spending money on product development with the project being “completed”, I realized that I would in fact start spending even more.

Do’s:

• Negotiate hours in bulk and make the hourly rate lower as you accumulate more hours. For example, 100 hours billed at $20/hour; additional 100 hours billed at $15/hour etc.
• Ask your developers to attach a log of each hour billed along with your invoice. This will help you keep them accountable for the work they are billing you for.
• Ask for a senior developer to manage your product. Senior developers may cost more per hour, but don’t let this mislead you. Ultimately, not only your product improvement request will be completed faster but you will also be billed less hours.
• Communicate with your developers using a project management software (i.e Jira or Trello) to keep track of items you want them to work on. Set deliverable dates, add comments, assign and prioritize projects.
• Make sure that all servers and third-party software (AWS, Cloudflare, Stripe, Mailchimp, GitHub etc.) are under your name and email address just in case.

Don’ts:

• Do not accept to move to the “support” phase yet if your product still has bugs or error messages even in the most common scenarios (i.e Facebook sign-up and login doesn’t work). At the very least, these should be covered under your first agreement.
• Do not be intimidated by your agency to “obliged” to work with them if the relationship has become absolutely unmanageable. Yes changing agencies and developers should absolutely be the last thing to do, but it might be a temporary setback if it means your product will thrive in the long-run.

In conclusion, agencies are the “necessary evil” to anyone that doesn’t have access to proven and reliable freelancer developers in their network. They are usually costly and are hard to work with, but can generally help launch a basic version of your product. Once this is launched and you have either unlocked early traction or raised money, you must immediately make your first hire an in-house engineer with equity in your start-up.

(This post originally appeared on https://www.borahamamcioglu.com/post/remote-development-agency-dos-and-donts)