Before you spend a dime
Hiring someone to build software for your business is a big decision. It's not like buying a subscription to some off-the-shelf tool you can cancel next month. You're investing real money, real time, and real trust in someone who's going to build something that your team will use every single day.
The problem is that most business owners don't know what to ask. And that's not a knock on you — why would you? You're an expert in your industry, not in software development. But walking into this blind is how people end up with half-finished projects, blown budgets, and a system nobody wants to use.
Here are 6 questions you should ask before hiring anyone. They'll tell you everything you need to know about whether you're dealing with a professional or someone who's going to waste your time.
1. "Can you show me something you've actually built?"
This is the single most important question. Anyone can talk a good game. Slides are easy. Promises are free. But a working demo? That tells you everything.
Ask to see real projects — not mockups, not wireframes, not "conceptual designs." You want to see something running. Click around. Ask who it was built for and what problem it solved. If they can walk you through a live system and explain the business logic behind it, you're talking to someone who actually delivers.
If they can't show you a single finished project, that's not a red flag — it's a stop sign. Experience doesn't guarantee success, but the lack of it almost guarantees problems.
2. "What if I change my mind halfway through?"
Here's a reality nobody tells you: you will change your mind. It's not a question of "if." Once you start seeing the system take shape, you'll realize that what you thought you wanted isn't quite right. Maybe the workflow needs to be different. Maybe a feature you thought was critical turns out to be unnecessary. That's completely normal.
The question is whether the person you're hiring can handle that. A good developer works iteratively — they show you progress early and often, not just at the very end. You should be seeing working pieces of the system every week or two, giving feedback, and course-correcting as you go.
If someone says "we'll show you the final product in 3 months," run. That's a recipe for getting something you never asked for. You need to be involved throughout the process, not just at the beginning and the end.
3. "How does pricing work?"
Money. Let's talk about it. You deserve to know exactly how much you're going to pay and when. A trustworthy developer will give you a clear breakdown: here's the total estimate, here's the deposit to get started, and here are the milestones where the remaining payments happen.
Milestone-based pricing is key. It means you're paying for completed work, not promises. Each payment is tied to something you can actually see and approve. If you're not happy with a milestone, you don't pay for it until it's right.
What a healthy structure looks like
A typical arrangement: 30-40% deposit to start, then payments tied to 2-3 clear milestones (like "user management complete" or "reporting module delivered"), with the final payment on launch. Everything documented upfront.
What to avoid
"We'll figure out the price as we go" is a nightmare waiting to happen. Same with 100% upfront. If someone wants all the money before writing a single line of code, you have zero leverage if things go sideways.
4. "What happens after launch?"
This is the question most people forget to ask — and it's one of the most important. Because the day your system launches is not the finish line. It's the starting line.
Real users will find bugs you never imagined. Your business will evolve. You'll need new features, adjustments, integrations with other tools. If the developer disappears after delivery, you're stuck with a system that nobody can maintain or update.
Ask about post-launch support: Is there a warranty period? How do they handle bugs found after launch? What's the cost for future changes? A good partner will offer at least 30 days of bug-fix support after delivery, with clear terms for ongoing maintenance.
5. "Who owns the code?"
This one is non-negotiable. When the project is done and paid for, the code should be yours. Period. You should be able to take it to another developer if you want, host it wherever you want, and modify it however you want.
Some developers try to retain ownership of the code, which means you're locked in — if you ever want to leave, you're starting from scratch. That's not a partnership; that's a hostage situation.
"Once I pay in full, do I own 100% of the source code?" If the answer is anything other than "yes," keep looking. Also ask for access to the code repository — you should have it from day one, not just at the end.
6. "How long will it take?"
Nobody wants to hear "it depends," but honestly, it depends. A simple order management system is very different from a full ERP with inventory, invoicing, analytics, and integrations. That said, a competent developer should be able to give you a realistic range based on the scope you've discussed.
Be skeptical of two extremes: "we can do it in 2 weeks" (they're cutting corners or underestimating) and "it'll take a year" for something that should take a couple of months. Both are signs of someone who doesn't fully understand the project.
A realistic reference
For a mid-complexity custom system (user management, a core workflow, basic reporting, and a dashboard), expect 6 to 12 weeks. Larger projects with multiple modules and integrations can take 3 to 6 months. Anyone who gives you an exact date on day one is guessing.
Red flags: run if you hear this
Beyond asking the right questions, you also need to know what answers should make you walk away. Here are the biggest warning signs:
"I don't need to understand your business"
If someone doesn't want to learn how your business actually works before they start building, they're going to build you something generic and useless. A good developer asks more questions than you'd expect — about your process, your team, your pain points. That's how they build something that actually fits.
"We'll figure out the price later"
No. The price doesn't need to be exact down to the penny, but you should have a clear range and a documented structure before any work begins. Vague pricing leads to surprise invoices, scope creep, and frustration on both sides.
"That's impossible"
Very few things in software are truly impossible. When someone says "that can't be done" to a reasonable request, it usually means they don't know how to do it — not that it can't be done. A good developer will say "here's how we could approach that" or "here's a simpler alternative that gets you the same result."
"We need 100% payment upfront"
This is the biggest red flag of all. If someone wants all the money before delivering anything, you have zero protection. Deposits are normal and reasonable — 100% upfront is not. Walk away.
You're ready
If you've read this far, you're already ahead of most business owners who hire a developer for the first time. You know what to ask, you know what to watch out for, and you know what a healthy working relationship looks like.
The right developer won't be annoyed by these questions — they'll welcome them. Because they know that an informed client makes for a better project, a smoother process, and a system that actually gets used.
Ready to have that conversation?
At Utilware, we answer all of these questions before we write a single line of code. No jargon, no surprises, no fine print. Schedule a free call and see for yourself.