Searching for a software house means a lot of work, but still less than building your own development team - it just takes a lot of careful research. And even after you've spent days going through portfolios and analyzing websites, you might still have doubts if the team that made a bunch of beautiful apps is actually the team that should build your app.
Because not all apps are created equal. Or will be created, in your case.
And there are things you need to know that you won't find out from reading a website.
#1 Do a background check
A website won't tell you if a software house sticks to agreed deadlines or stays within budget. You won't know whether they're easy to communicate with or drop off the face of the planet in the middle of the project. And if they stick to the terms you agreed on (such as providing documentation and source code). Can you rely on them to advise you if your own project needs to be revised?
Ask your prospective software house for references and talk to some previous clients about how their cooperation went.
#2 Schedule a demo call
You shouldn't even consider hiring someone who won't give you an hour or two of their time before taking on your project. If you can't meet them in person, ask for a Skype call (or, apparently FaceTime is now the video call app of choice for busy and important people).
Prepare a list of things that definitely need to be discussed:
- The exact skillset you need.
- How you will communicate. It's understandable if you want to discuss every idea immediately and on the phone, but email or Slack is less disruptive and often times more than enough to talk about progress.
- How often you will communicate. Find the balance between keeping you posted and letting them focus on the job. Each minute spent talking about the project is a minute not spent working on it. (And you will probably be billed for all the phone calls and extra meetings).
- How they manage their projects. It's important to divide development into modules and set checkpoints to control the pace of the progress.
- How hard is it to make changes.
- How the project will be documented. Do insist on documentation, in case you’re unhappy with the cooperation and want to continue app development elsewhere.
- And of course, the pricing model (and why it should be T&M)
- Will you be able to contact developers directly, or always through the project manager?
After the demo call (or calls), are you feeling good about it?
#3 Hire them for a test assignment
If you’re planning a big project, betting your whole budget on one
horse house is a big risk. But you can minimize it even more.
If you decide on the t&m pricing, it’s natural to worry about how reliable a development team is and if they’re worth the hourly rate you’ll pay them.
A good software house will let you hire them for a test assignment, developing a small part of your product so you can test the waters before committing to a long contract. We recommend doing the test for a fixed price - that will let you arrive at a more accurate cost estimate later, in the time & materials model. Plus, you won't have to pay extra if the test assignment goes into overtime, but the task will be small enough that it will be overtime hours, not days.
The test task should be a part of the full product that you can take away with you if the cooperation doesn’t go well. A reasonable deadline for the test would be less than a month, preferably two weeks, with the scope of the task adjusted accordingly. Ideally, the test would produce a stripped-down version of an MVP, but even just a JS-powered storefront will do if your product is too complicated to build one full functionality in two to four weeks.
Take for example an online store with a responsive bike customization configurator. The bike configurator would be the best task for a test because it's the most challenging part. The rest - customer support backend, payments, billing, returns - is something any professional development team can build. The challenging part will prove the team's worth.
#4 The test results
It’s very important to agree beforehand on regular communication of the project’s progress. Set at least one checkpoint during the test period - once a week is reasonable - shorter deadlines and smaller tasks keep the team more focused and the progress easier to control. A good project manager will give you a checklist of sub-tasks that the test project requires, and update you regularly on their completion.
After the test you will be able to verify all the promises you were given at the start of the project.
Did they fill the communication quota you agreed on? Did they leave you with good documentation and test logs? Were they reasonably close to deadlines? And by the way - does the code work?