Most expensive software projects don’t fail because the developers were bad. They fail because nobody asked a few awkward questions at the start, when changing course was still an affordable choice.
You’ve probably seen a version of it. The “simple” website that needed a booking system halfway through. The app that worked perfectly on the founder’s iPhone and crashed on every Android phone in the office. The agency that went quiet the week after the final invoice, taking the only copy of the code with them.
None of that is bad luck. Every one of those problems could have been caught with a question asked before anyone wrote a line of code. So before you hire web developers, here are the nine worth asking, starting with the ones you need to ask yourself.
1. What Problem is this Actually Solving?
“We need a new website” isn’t a problem. It’s a solution someone has already picked.
Try to write the real problem in one plain sentence. “Customers keep calling to check order status because they can’t see it online.” “Our sales team spends two hours a day copying leads between spreadsheets.” If you can write that sentence, you’ve got a project. If you can’t, you’ve got a wish list, and wish lists turn into long, expensive builds that never quite feel finished.
That one sentence also becomes your filter for every feature request later on. Does this help solve the problem? No? Then it can wait.
2. Do You Need Something Custom at All?
Once you know the problem, check whether someone has already solved it.
A lot of businesses pay for custom builds when Shopify, WordPress or a decent off-the-shelf tool would do 90% of the job for a fraction of the cost. Custom makes sense when your process is genuinely different from everyone else’s, when you need to connect systems that don’t normally talk to each other, or when the software itself is what you sell.
The same goes for apps. Custom mobile app development services are worth paying for when people will use the thing often, need it to work offline, or need phone features like the camera, GPS or notifications. If customers will open it twice a year to check the price, a mobile-friendly website will do the job and save you a lot of money.
A good developer will tell you this. If the first person you talk to jumps straight to a full custom build without asking about alternatives, that tells you something.
3. Who Writes the Spec, and What Happens When it’s Wrong?
The next question is how the work gets defined.
Someone has to write down what’s being built. Screens, features, what happens when a user clicks each button. If you write it, gaps you didn’t think of become your problem. If the developer writes it, check it properly before signing, because whatever’s in that document is what you’ll get.
And the spec will be wrong somewhere. It always is. So ask how changes are handled. On a fixed-price deal, every change becomes a new quote, which is fine until you’re on your twelfth one. On a time-and-materials deal, changes are easy but the budget can drift. Neither is wrong. You just need to know which one you’re signing up for and how change requests get priced.
4. Who Will Actually Be Doing the Work?
Here’s something that happens all the time. You meet a sharp, senior developer in the sales meeting. Then the project starts and you never see them again, because the actual work has gone to someone with eight months’ experience.
Ask straight out: who will write the code, and can I speak to them before we sign? Ask how long they’ve been with the company, and whether they’ll stay on your project until it’s done or get moved elsewhere halfway through. Team changes mid-build cost weeks, because the new person has to learn everything the old person knew.
5. Who Owns the Code, and Where Does it Live?
This one gets missed more than any other, and it’s the most painful to fix later.
The code should sit in a repository that you own, like a GitHub or GitLab account in your company’s name, with the developer given access. Not in their account with you given access. Same with hosting, domain names, app store accounts and any paid services the project runs on. All of it should be in your name, with your login.
Check the contract says you own the code once it’s paid for. Plenty of small agencies keep ownership by default, not because they’re dodgy, but because nobody changed the template. You don’t want to find that out on the day you try to move to someone else.
6. How Will You Know It’s Going Well Before It’s Finished?
Once the build starts, the biggest risk is silence. Three months of “it’s coming along” and then a big reveal that isn’t what you pictured.
Ask how often you’ll see working software. Not screenshots or progress reports. Something you can click on. Every two weeks is a sensible rhythm. You should also get a test link, usually called a staging site, where you can try things out yourself whenever you want.
Seeing it early means spotting problems early, when they cost an afternoon to fix instead of a month.
7. Who’s Testing it, and On What?
Related to that: who checks it actually works?
Developers test their own code, but they test it the way they built it, which means they miss the things real people do. Ask whether there’s a separate tester, and what devices and browsers they check on. If most of your customers use cheaper Android phones, it doesn’t matter how good the app looks on a new iPhone.
Get a handful of real users to try it before launch too. Watching someone who’s never seen the thing try to use it will show you more problems in ten minutes than a month of internal review.
8. What Happens After Launch?
Launch day feels like the finish line. It’s closer to the start.
Every website and app needs looking after. Security updates, bug fixes, hosting, and for apps, keeping up with new versions of iOS and Android. Apple and Google release updates every year, and those updates break things. A login screen that worked fine in September can stop working in October with no warning.
Ask what support looks like after the launch. Is there a warranty period for bugs? What does ongoing maintenance cost per month? How fast will they respond if the site goes down on a Saturday? A common rule of thumb is to budget somewhere around 15 to 20% of the original build cost every year for upkeep. If nobody mentions ongoing costs at all, ask why.
9. What Will This Really Cost?
Which brings us to the number that matters.
The developer’s quote isn’t the full cost of the project. You’ll also need to pay for design if it’s not included, content and photos, third-party tools and integrations, hosting, app store fees, testing, and the ongoing maintenance from the last question. Then there’s your own team’s time, which almost nobody counts. Someone on your side will spend hours every week answering questions, checking work and making decisions.
Add all of that up before you commit. If the real total makes you nervous, it’s much better to know now, when you can still cut features, than halfway through when you can’t.
Before You Sign Anything
If you only take one thing from this, make it the first question. Write down the problem in one sentence. Most of the other eight get easier once that’s clear, and a surprising number of projects get smaller, cheaper or cancelled altogether at that stage. That’s a good outcome, not a bad one.
If you’d like a second pair of eyes before you commit, talk to our team. We’ll go through what you’re planning and tell you honestly if an off-the-shelf tool would do the job instead. If it does need building, you can see how we approach web development and mobile app development projects.
FAQs
How much does it cost to hire web developers for a business project?
It depends mostly on what you’re building, not who builds it. A standard business website on WordPress or Shopify is a very different job from a custom web app with logins, payments and integrations. Most developers charge either a fixed project fee or an hourly or monthly rate. Get at least three quotes for the same written spec so you’re comparing like with like.
Should I hire a freelancer, an agency, or dedicated developers?
A freelancer suits small, well-defined jobs with a clear finish line. An agency suits projects that need design, development and testing together, managed for you. Dedicated developers, where you hire people who work only on your project, suit longer builds where you want control over priorities without the cost of hiring staff directly.
How long does it take to build a custom website or app?
A straightforward business website usually takes a few weeks. A custom web application or mobile app typically takes three to six months for a first version, depending on how many features it has and how quickly decisions get made on your side. Slow feedback from the client is one of the most common reasons projects run late.
Do I need a mobile app or will a mobile-friendly website do?
A mobile-friendly website is enough for most businesses. Custom mobile app development services make sense when customers will use it often, need it to work offline, or need phone features like notifications, the camera or location. If people will only use it occasionally, a website is cheaper to build, cheaper to maintain and easier for people to find.
Who owns the code when I hire an outside developer?
Only whoever the contract says owns it. Many templates leave ownership with the developer by default. Make sure the agreement clearly transfers the code to you once it’s paid for, and that the code, hosting and domain all sit in accounts registered to your business.