Shopping for a Dev Shop

Hiring software developers is notoriously hard to do, even for those of us who are technically savvy. Hiring developers is like buying a book; just because the editorial blurb on the back is great doesn't make the writing great.

If you have a project that is more than just a single-page website, you'll need to hire a development shop (or go through the effort of hiring your own staff, which is a very different topic) to do the heavy lifting. Your project may be starting from scratch, or maybe your existing application is buggy or not very scalable and you need to refresh it. For whatever reason, you recognize that hiring a person off of Fiverr, Upwork, or Freelancer just isn't going to hack it. You're already on the right track.

Cost

Let's just get this out of the way. No matter how you look at it, good software development is expensive. There's simply no way around it. The tale of the single coder pumping out a full-fledged application in a single day is a farce.

So what can you expect in the way of cost? Depends on the project and the skill set you're hiring for.

• Simple Website Adjustments/Fixes: $40 - $60/hour for 10 to 60 hours.
• Basics Single Page Web Application: $50 - $100/hour for 20 to 100 hours.
• Fullstack Web Application: $75 - $125/hour for 500+ hours.
• Enterprise-grade Application: $100 - $200/hour for six or more months.

And to be clear, this is the hourly rate of a single developer. A good team will include three to four developers at least, and for complex projects, a project manager and UI/UX specialist will need to be included. This doesn't include the need for a graphic designer (which you would usually hire separately to work with the team).

So, yeah. Expensive.

A Silver Lining on Cost

The good news is usually a dev shop will offer a blended rate that is less than the average rate of the individual developers (and project manager and UI/UX specialist). They can offer this because a team is made up of more than just one type of developer and they do not all work eight hours a day, five days a week. Experienced developers and a good project manager can help improve the value you get from the team through higher quality code, delivered faster, and with greater degrees of communication.

What About a Flat Rate?

If you're requesting software that isn't particularly complex (at least from the initial concept you provide), then the shop may be able to offer a flat rate. This is more cost-effective for you, but if your project requires more work than anticipated, then you run the risk of overage costs (which are often built into the contract). It doesn't hurt to ask, but be aware unless the shop has done similar work, they'll likely insist on an hourly rate.

Offshore?

Yes, they can often be less expensive on an hourly basis... but there are consequences to going offshore. To keep it short, time zones alone make working with off-shore developers prohibitively expensive in terms of sanity and lifestyle rather than cost. Cultural and language barriers will get in the way as well, and unless you're well versed in the technologies being used and actually can keep track of the details of the work being done, you can be bamboozled with absolutely no recourse to fall back on.

There are off-shore organizations that are great to work with, but generally speaking, they are 1) hard to find and 2) only nominally less expensive to work with since they already know they're great to work with.

Time and Schedule

Often, the earliest question asked by a potential client to the development shop is "How long do you think it will take?" If they respond casually back with a number, consider not using them. Why?

Software development is inherently non-deterministic. Unlike building a house, which has predictable (relatively speaking) actions that can be timed and calculated to determine a schedule, it is very hard to know how long it will take to develop most software. There are simply too many different ways that things can go wrong and won't crop up until well into the development cycle.

Rough estimates can be given, but you should always anticipate a set of caveats to accompany those estimates.

Agile to the... Rescue?

You may have heard the words "Agile," "Scrum," "Kanban," or "Lean Development" bandied about. Agile is the umbrella term for a set of project management methodologies that originated partially in manufacturing and partially in software development.

A typical Agile project will release a version of your software to you every two weeks or so, demonstrating the progress that has been made. This process gives you a real sense of the work needed, and the confidence that your project is moving forward. The worst, in theory, that can happen is your project is off by two weeks because something has to be undone and corrected.

It's not a panacea, however, and certainly cannot predict how long the project will ultimately take. A lot of that depends on you, the client, and how often you make requests to change things. The more significant the changes, the longer it will take. But the end result should, if all has gone well, be a product that works well, the way you want, and the way that your customers will enjoy and gladly pay for.

The Vetting Process

The first thing you need to do is vet the dev shop. This means having a call with them so you can explain your idea, get a feel for personalities, and hear their story and perspective on the level of effort it will take to approach your project.

An honest shop will tell you if they think they're the right fit for the job or not. They may acknowledge that they are not the perfect fit, and that's okay. They still may work if other factors such as cost, personality, contracts, and management all make sense.

NDAs

You may have heard the aphorism of "An idea is only as good as its execution." Basically, you may have a great idea, but if you don't do anything with it, then it's worth nothing. A lot of people fear sharing their ideas with others, especially dev shops because they might have the skill and talent to execute.

True, they may. But it's highly unlikely they will. With the exception of huge corporations who have unlimited resources, even the biggest of dev shops are not going to spend the time to verify that the idea even works, much less make the financial investment in time and resources to work on something that is probably not in their domain of expertise. They could be making money with another client instead, where the success or failure of the idea is on the client, not on themselves (assuming the dev team did a good job in implementing the details).

Most dev shops will sign an NDA if you like. You can provide one of your own, but likely they'll provide one.

Asking Questions

You should feel free to ask any question, even "dumb" ones. No good shop will make you feel silly or uncomfortable. A good shop will encourage questions, offer suggestions, and like I'm doing here, tell you what you should expect should you choose to take your business elsewhere. There is nothing lost in providing goodwill.

What questions should you ask? Good question!

The big questions have been addressed already: Cost and Time. If those don't scare you off, then it's time to start asking these sorts of questions:

1. Who owns the code?

• Typically, you would own the code. As such, you should have access to it any time, usually through a repository service such as GitHub. You'll have to pay for such services to keep them private (the free versions leave your code exposed, which is great for open source software, not so great for entrepreneurs).
• A dev shop may use open source code to develop your project; this is customary, expected, and fine. You will not own that part of the code, of course. If a special custom library would help the development along, you would be responsible for paying for the license and thus also own the license.

2. Who will maintain the code and services?

• After the project is done, the software doesn't simply live in a vacuum. Maintenance still needs to happen for things like scaling up servers, applying security patches, monitoring the service, and so on. The dev shop will typically offer that service; the overall rate for providing it will be far less than development and will often be restricted to a certain number of hours per month.

3. How will the project be managed?

• If you have a small project needing only a single full-stack developer, then that developer may be enough to run the project. The developer may bring on specialists for certain parts of the code, but often that will be behind the scenes and self-managed.
• For larger projects needing three or more developers, ideally, the dev shop will provide a project manager. This is the person you engage with on regular basis and who "translates" your needs into the actions the developers will take (this is a vast oversimplification of the process, but I think you get the point).
• You should get regular updates regarding the projects. More importantly, you should feel free and able to ask questions and make requests at any time. A good project manager will discuss those request with you to make sure it fits within the scope of the work.

4. How do you like to communicate?

• The dev shop will generally communicate in a way that best works for you. However, if you're flexible, the shop may offer its own solution, such as bringing you into a project-specific channel on Slack or other instant messaging services.

Other things to listen for:

If you don't hear any of these words mentioned, don't panic. The dev shop may not want to burden you with too much techno-babble. If you do hear these words, then at least on the surface, they might know what they're talking about:

user interface, user experience, Google Cloud Platform (GCP), Amazon Web Services (AWS), Javascript, Scrum, Agile, Kanban, Jira, Microsoft Teams, BitBucket, Git, GitHub, repository, codebase, object-oriented, procedural, functional, lambda, elastic, application program interfaces (APIs), web sockets, Ajax, Node JS, React JS/Native, Angular JS, Vue JS, PHP, Python, Django... and so, so much more

Mind you, this might mean they've read this article or are really good at speaking techno-babble. But it's a start.

More importantly, if you don't hear them speaking about your project, your needs, and your expectations, that's a bigger warning sign than being able to spout out a litany of software words.

Scoping the Project

Lastly, at least as far as looking for a good dev shop is concerned, is asking about how the project will be scoped. That is, despite the vagaries of software development I've already highlighted, what is it that will actually be worked on, what is the rough timeline, and what is expected of both parties?

Before you sign to fully commit to using a dev shop, make sure you get and carefully read over what is often called a "Statement of Work."

This document, at a minimum, will take several hours of work on the part of the dev shop, possibly several days if it's a complex project. You may be requested to pay a flat fee for creating this document for such large projects.

What you should see in a statement of work are enough details to satisfy you that the development shop actually listened to what your project is about and read any documents that you may have shared with them (highly recommended to do so; if you don't have documentation of your own, you may not be ready to start on a large project). To be clear, what it won't contain is a line-by-line list of things that are going to be done. The statement of work is a high-level document, not a recipe.

The shop should be fairly specific in what they will and won't do. What they won't do is just as important and usually means two things: You're protected from developers doing miscellaneous work that isn't really needed and the shop can push back on you if you try to insist on adding new features or functions that weren't anticipated the beginning of the project.

The statement of work will also clearly state the deliverables to be handed over at the end of the project. This should include at the very least the code base, documentation, and if applicable items like configuration and security files. Again, the specifics should be enough, but not overly detailed — no company can tell you everything up front; if they could, they should charge you a flat rate for cost.

Notes on Complexity

Software development has gotten easier over the decades, but in exchange, the problems being solved are dramatically more complex. Most people think that an application, be it Gmail or Netflix on the web, or Excel and Word on the desktop consists of just the graphic and interface they see and interact with on a daily basis.

Aside from the work assuring that the workflow is pleasurable to work with, the user interface is actually one of the easier parts of the development process, at least coding-wise. Where it gets complicated is behind the scenes, with the administrative interfaces and the infrastructure setup and all the layers in between, to the sides, and on top of the interface, the end-user sees.

Keep this all in mind when the statement of work is presented to you, as well as when trying to plan for the costs and schedules of your project.

Concluding Thoughts

There's a lot to ponder when hiring a development shop for the project of your dreams. Costs will likely run higher than you think, partly because of the persistent myth of the Fiverr-hired cowboy coder whipping out an application in one day on the cheap which highlights the reality of software development: In this modern age, coding is easy to learn, but it's incredibly difficult to execute well, especially at the enterprise scale.

Schedules will be unpredictable. Again with the housing metaphor, software development is nothing like the repetitive business of erecting walls, installing plumbing and electricity, and finishing the place before (and as someone whose done that work in the past, I can tell you it's also not easy, but it's still mostly predictable).

And no matter the size of the project, you're going to have to expect problems to crop up that will seem trivial, but turn out to be far mor difficult than expected to solve. You'll have to be comfortable knowing you'll never be able to verify if that extra work was necessary, but an good dev shop will be more than willing to explain the details to you if you want. A good shop wants to educate you and make you a smarter participant in the project because it will make their job that much easier.

I hope this article has given you enough food for thought. If you want to know more, feel free to reach out to me and I'd be glad to discuss the details of your search for a great development shop that works for you.