<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=752538731515435&amp;ev=PageView&amp;noscript=1">

5 Questions to Ask Before You Hire a Potential Software Development Partner

A prudent question is one-half of wisdom. Francis Bacon

Questions.

So many big events in life revolve around questions.

Buying a car? You need to ask about the selling price, the financing rate, the features, the reliability ratings and more.

Going to college? You need ask about tuition costs, available scholarships, graduation rates, credentials of the faculty, and yes, more.

Interviewing for a job? Better learn what questions they may ask, and make sure you aren't caught without good answers.

Hiring a software development company to complete a project you have is no different.

Questions

Questions they should be asking you.

Questions you should be asking them.

 

The process of asking and answering questions in both directions is the means by which you come to an understanding with a potential development partner. That understanding can go one of two ways - either they'll be a good fit for you or they won't.

There are dozens of questions to be asked. Business questions. People questions. Schedule questions. Cost questions. Tech questions. Support questions.

We can't cover them all here - so here are five questions we think are either the most important or something you may not think to ask.

1. What is your process for communicating with your client?

Communication is often the reason a software project fails. Or succeeds.

You want to hear that they have a process. Any process. But remember you are the client. Don't be afraid to set the expectations around communication channels and cadence.

2. Can you talk me through your development process?

Be prepared - there will be buzzwords here.

Waterfall.

Agile.

Extreme.

Best to read up on these before asking the question.

But you also want to hear terms like:

Developers love to write great code. But they also love to create processes that:

  • Re-use chunks of well-tested, reliable code
  • Reduce risk of rolling out new code
  • Make mode migration as efficient as possible
  • Make their projects move in a consistent fashion

When you ask this question of potential software development firms their eyes should light up and they should start talking with their hands. If not, consider that a yellow flag on the deal.

3. Can I adjust my feature set and specifications as we go?

Change requests.

Scope creep.

These can be schedule-killers and budget-busters.

Unless you plan for them.

What one firm calls scope creep another may call a revised user story.

As the client, chances are you will have other ideas for the project after the development work has kicked off. You need absolute clarity over how the potential development partner will handle your changes. And how it will impact the budget and schedule.

The conversation should circle back around to the specific development process the software development company uses. The process should allow for mid-stream course changes.

4. Who owns the code and designs you produce for me?

This question touches on Copyright Law. The answers should be documented in a contract between you and the development house. And yes, have the suits involved.

Here's the rub (at least in the USA).

Ownership of a creative work defaults to the creator.

Code is considered a creative work. If the other firm wrote the code, they own the code.

Unless they explicitly assign all ownership to you.

Which you may think would be fair, since you are paying them.

But remember why you are considering hiring this company. They know how to code something you don't.

How did they learn? By doing lots of other projects before starting on yours. They bring a weath of experience and knowledge to your project.

They likely even brought along a "toolkit" of common code functions or coding approaches they developed while working on another site.

Make sure your contract language doesn't prevent them from bringing that value to the next project after yours.

Protect your business IP - sure. But don't do a land-grab of claiming ownership of every last line of code they use in your project.

Some software development contracts end up reading like a story where you:

  • Hire a plumber to fix a pipe
  • Claim ownership of the pipe wrench the plumber used in the fix
  • Tell the plumber he can't use a similar pipe wrench to fix leaky pipes ever again
  • Have no clue how to use the wrench you now own (which is, of course, the reason you hired the plumber in the first place)

Don't be that company.

5. Will you help me transition to an in-house team or mentor and train my team?

The software development world is filled with stories of the relationship ending when the project is complete and the code delivered.

Then a year passes.

Some people turn over.

The business changes.

The software needs to be updated to stay relevant and valuable to the business.

Technologies come and go. Developers come and go. Get training or plan for the knowledge transfer at the end of the project when it's still available from the software developer.

Otherwise you risk not being able to get updates when you need them.

Ask Us Anything

We love it when potential clients come to us with a healthy round of questions. It shows you are engaged and excited about the project at hand. Contact us and we can get the conversation going!

Share:
Nick Barbera

About Author Nick Barbera

Nick Barbera is a former Business Development Manager at Omni. He had been selling IT solutions and staffing for 12+ years. Nick relied on his strong knowledge of the market and technology to help companies make the best business decisions when it comes to new and innovative approaches to IT. He graduated from the University of Wisconsin-LaCrosse, where he was a four year starter at defensive back on the football team. He is a proud husband and father of two boys.



Disclaimer:

Omni’s blog is intended for informational purposes only. Any views or opinions expressed on this site belong to the authors, and do not represent those held by people or organizations with which Omni is affiliated, unless explicitly stated.

Although we try to the best of our ability to make sure the content of this blog is original, accurate and up-to-date, we make no claims of complete accuracy or completeness of the information on this site/s to which we link. Omni is not liable for any unintended errors or omissions, or for any losses, injuries, or damages from the display or use of this information. We encourage readers to conduct additional research before making decisions based on the information in this blog.