How to Hire the Right Dev Shop: Transparent Proposals

You need a developer. Whether you are a new founder with an exciting idea, or a seasoned CXO who wants to do something new in your company, you know you need a dev, but you have no idea how they do what they do.

Don’t worry, you are in good company.

Black magic… Alchemy…. Voodoo… the act of making a computer actually do something is rarely understood. All the client knows is that they need something built and that requires a developer to work their magic. Often this uncertainty leads to a bit of intimidation and therefore mistrust.

If you have worked with a development firm in the past, then this feeling may be even stronger if that experience did not go well. This usually comes in a few different flavors:

• “My dev stopped responding to emails after I made a major milestone payment and I was left with a project that is 80% complete.”
• “My dev team went dark for six months and came out with something completely different than what I had in mind.”
• “My dev is still here! Every month I get a bill for more and more hours for stuff I thought I already paid for!”

All of these situations would make anyone wary of working with coders. Development is often compared to surgery. You know it is necessary, and you know it should help, but you don’t want to go through the pain.

So how do you find a development firm that eases these fears? How can you be comfortable and in charge even when you don’t fully understand what the team is doing?

The answer lies in finding a developer that is built from their very core on transparency. My goal with this series is to walk anyone looking for a dev team a better way to find a firm they can trust and have a long and productive relationship with.

The quest for a transparent developer starts at the very beginning of any project: the proposal. This is the first deliverable that any firm gives their client so it is a good indicator of what it will be like to work with them.

You want to know you are working with a solid and upstanding development firm. To identify the right one for you, look for these things in their proposals.

Clarity

The proposal is the bedrock of the project. It determines the specifications (or spec) of what is being done, how much it costs, and when it will be finished.

If and when a disagreement or misunderstanding happens, then both sides will reference the spec to try to resolve it. If the language is not written in a way that is crystal clear to both parties, then they will both interpret it very differently.

A consequence of unclear language often shows up like this:

Client: If the client thinks the dev is not doing their job and completing what they see as the requirements, then they may start to get angry and become harder to work with.

Developer: On the other side of the coin, if the dev feels as though the client is using their understanding of the spec to eke out some extra work for free, then they might become resentful and in some unfortunate cases may not do their best work.

In either case the project can get rocky very quickly, and that often ends with one or both parties unhappy. This can be prevented with a bit of clarity.

Keys to a Clear Proposal

• The estimate should be simple, to the point, and show a solid understanding of what a successful delivery is. A good sign that the dev is trying to keep things focused and understandable is the liberal use of bullet points instead of long, flowing paragraphs.
• A clear proposal should stay away from technical jargon and flowery language as much as possible. By necessity there will be some, but a good estimate is written for an 8th grader rather than a college professor.
• There should always be an assumptions section. This is where the developer explains the assumptions that they are making to come up with the estimate. This could be things like whether or not a web app will be usable on a phone, the tech stack the developer wants to use, or who is managing the various servers. If there are disagreements about these things, this is the time to have them rather than when the team is pushing to production.

Fixed Pricing

This is a hot button for a lot of dev shops, but if the goal is to be more transparent and open to clients than there is no better way to start the relationship than to show them exactly what something is going to cost before the first line of code is written.

By its very nature, hourly or “time and material” projects set the relationship up to be adversarial. No matter how long they have worked together the client is never sure if the dev is dragging their feet juuuust a bit for an extra hour here and there. Fixed-fee proposals solve this issue right out of the gate.

Exceptions to the Rule

No matter how transparent the dev is trying to be there are some times where it just isn’t smart or even possible to go fixed-fee. Primarily this revolves around situations with a good bit of uncertainty. Here are few examples:

• A new (or ancient) API that needs to be integrated into the project. If the project requires integration with a well known API like Stripe or Twilio then a seasoned dev knows how long it will take to integrate with it and estimating it is no problem. However, if the project is a bit out in left field and has to work with an API that uses a 10 page PDF as its “technical documentation”, or is built on tech from 1992, then there is just no way to know ahead of time how ugly this integration might get.
• Experimental or bleeding edge tech the project may need. If a project uses technology that isn’t well supported by the community (Stack Overflow, blogs, etc), then things take longer to build because the team is on their own. In these situations fixed-fee pricing is very difficult.
• There is simply something in the project with which the dev is unfamiliar and research needs to be done. This is a bit squishy, but no developer has worked with all technologies, and that doesn’t make them a bad team to work with. If you need a wizard in Power BI for your project to work then hire a wizard, but you may save some money if you work with a dev who is capable and passionate about learning something new. A small research project could go a long way in this situation.

The key point here is that even if research is needed then the goal isn’t to do the whole piece hourly. Instead, the dev should carve out just enough time to do the needed research and build the prototypes they need to feel confident with the tech, and they can estimate this part in a fixed-fee manner.

Scope

Now, to make fixed-fee pricing work requires both sides to play fairly. By committing to a fixed-fee engagement, the development team is basically doing a spit handshake, saying “I solemnly swear to do this work for $XX.XX without any sneakiness or hidden costs”.

The client’s side of this agreement is known as scope. Here the client is spitting into their hands and saying “If and when I change my mind about what I want built, I understand that both the cost and the timeline will change to reflect these additional requirements.”

This can be tricky to manage because even the most experienced client often assumes that they are paying a flat fee for the concept that is in their mind rather than what is laid out in a spec. If they tell the dev team to build something then decide they don’t like it, often it is assumed that the rework is included in the original cost.

The dev, on the other hand, believes they are building features A,B, and C that the client is requesting. If the client wants feature D for some reason, then this is a scope change. At this point the dev will expect more money and probably more time to complete the project.

The proposal should make this perfectly clear. A good estimate will have a section that outlines exactly how scope changes will be managed. This way there is no confusion and everyone understands what the expectations are.

Timelines

When committing to transparency, timelines go a long way. The problem is, as soon as the developer puts in a hard date, the client is going to hold them to it and may get cranky if it is missed, even with the best of reasons.

The balance for transparency and the “wiggle room” that projects often need is to put in a range of a couple of weeks rather than a single date. This way the developer is still being open and upfront, but still has a bit of room if/when something takes longer than expected.

Sidenote: While this isn’t specifically related to a proposal, when it comes to timelines it is important to have conversations with the team about vacation schedules and holidays. Most clients forget about holidays when it comes to deadlines. Make sure to talk to the team before every phase about how a deliverable may be impacted by vacations/holidays.

There are some amazing dev shops out there. Unfortunately, though, there are also a lot of bad apples that use the practice of obfuscation and sleight of hand to get paid more, miss deadlines, or do shoddy work. The quality and clarity of the proposal will help you a lot in determining which type you are dealing with.

Transparency signifies a different kind of developer: one that clients seek out rather than “end up with”. More importantly, transparency is a solid indicator of a firm with which most clients would prefer to have a lasting relationship. Shining a light through the proposal process is the first step in that journey, and it should be one your development firm considers worth taking.

‍