7 Questions to Ask Before Hiring a Web Application Development Company

Plenty of business owners hire a web application development company based on polished portfolio screenshots and a friendly sales call. Screenshots show finished work, and a salesperson's job is to be likable. Neither tells you who will build your product or how the vendor behaves when plans change.

Say you run a 40-person HVAC company and want a portal where customers book service calls and pay invoices. One of the questions below decides whether you build it all now or start with a minimum viable product, the stripped-down version an MVP development company would scope. A good vendor brings it up before you do.

"Who will actually work on my project, and will they stay until launch?"

A good answer names your project manager and lead developer, then tells you how many other projects they're juggling. Ask whether they're employees or freelancers, and what happens if one leaves mid-build.

Be wary of a vague answer that names nobody, or a senior engineer who sat in on every sales call and vanishes once you sign.

"What have you built that works like this, and can I call that client?"

The industry matters less than the moving parts. A vendor who built customer logins and card payments into a cleaning company's booking portal has solved most of your hard problems. Anyone worth hiring will walk you through a project like that and hand over a phone number. It's a bad sign when every reference is a testimonial on their website and no past client will take your call.

"When the project ends, what do I own, and whose name is on each account?"

The right answer is short and in writing. You own the source code (the files your portal runs on) and the designs once you've paid, and every account, from hosting to payments, sits in your company's name from the start.

Be careful if the vendor wants everything under their own account. We see that go wrong a lot, usually when an owner switches vendors and learns the domain was never theirs.

"If I want something changed after work starts, how do you handle it?"

You'll want changes. Partway through, your dispatchers might ask to see a technician's notes before they confirm a booking. Strong vendors handle that with a written change request showing what it does to the schedule and price before anyone builds it.

A vendor who calls themselves flexible and leaves it at that is telling you the cost will show up later, on an invoice.

"How will I see progress each week?"

Look for working software. That means a weekly demo and access to a staging site, a private test copy of your portal, where you can book a fake service call as a customer and watch it land on the office dashboard. Written status reports and a big reveal near the end should make you nervous, because anything you dislike by then costs real money to change.

"Should we build everything now, or launch something smaller first?"

I'd start smaller almost every time, since real customers show you what matters faster than any planning meeting. For your portal, that means booking and invoice payments at launch, with the live technician tracker and maintenance memberships held for phase two. The vendor you want will push you to cut part of your feature list. Watch out for one who happily quotes your whole wish list.

"What happens after launch, and who do I call when something breaks?"

Something will break, and it'll happen on the first cold morning of the year, when everyone in town wants a furnace repair. Expect a warranty period for bugs, then a written support plan covering security updates and what happens when your payment processor changes how it works.

If the proposal is silent on support, that's your warning sign. Get terms added before you commit, since you'll have far less pull once you've paid in full.

Before the first call, email these seven questions to every web application development company on your shortlist and ask for written answers. Put the replies side by side. Plain, specific answers on paper are a good preview of how a vendor runs a project, and vague ones are just as revealing.