Before You Hand Over the Keys: Questions That Reveal Your Software Partner's True Colours

Hiring a software developer can feel like buying a house from a floor plan. The pitch looks promising, the screenshots sparkle, and everyone says they understand your vision — but you still need to know who will build it, how they'll handle surprises, and what happens after you move in.

The best questions to ask before hiring a software developer go beyond technology choices and launch dates. They reveal how a team works when budgets tighten, requirements shift, or something breaks. Use the questions below to compare freelancers, agencies, and in-house candidates — even if you never contact us.

Who's Actually Holding the Keyboard?

Start with a deceptively simple question: "Who exactly will write our code?" The person delivering the pitch might lead the project, contribute occasionally, or disappear after the contract lands. None of those arrangements automatically spells trouble, but you should understand the difference before signing.

Ask whether the team includes employees, freelancers, subcontractors, or junior developers. Then ask who reviews their work and who makes technical decisions. Junior developers can contribute excellent work with appropriate guidance; senior job titles alone don't guarantee quality. What matters is whether the team matches the project's complexity and provides meaningful oversight.

Try: "Can we meet the technical lead and the people assigned to our project?" Also ask what happens if a key developer leaves. A dependable partner should explain its handover process, documentation habits, and staffing arrangements without treating the question as an inconvenience.

Can They Show You More Than a Beautiful Screenshot?

A polished portfolio tells you something about presentation, though it may tell you very little about reliability, maintainability, or the team's actual contribution. When reviewing past work, look for projects with challenges similar to yours — not just businesses in the same industry.

Ask: "Can you show us comparable work and explain exactly what you delivered?" Useful comparisons might include subscription billing, complex integrations, sensitive data, or a system that staff use every day. Follow up with questions about constraints, difficult decisions, and what changed after launch.

Where appropriate, request a client reference and ask how the team handled problems rather than whether the client "liked them." Confidentiality may limit what a developer can share, so accept anonymised examples or walkthroughs where necessary. Credible evidence should still explain the work, the developer's role, and the outcome — not simply display a logo.

Does the Quote Have a Floor — or a Trapdoor?

Two quotes can describe the same idea while covering very different amounts of work. One might include discovery, testing, deployment, and documentation. Another might cover development only. Compare assumptions and deliverables before comparing the final number.

Ask the developer to explain their pricing approach: "Is this fixed-price, time-and-materials, or a combination, and why does that suit this project?" Fixed-price work usually needs clear boundaries. Time-and-materials allows flexibility but needs spending visibility. Neither model removes the need for budget controls.

Next, ask what the estimate excludes and how the team calculated it. Hosting, third-party subscriptions, data migration, accessibility work, and ongoing maintenance can materially affect your total cost. Request a payment schedule tied to clear milestones or reporting periods, and agree what happens if the forecast starts moving beyond your budget.

What Happens When the Map Changes?

Software projects rarely follow the first brief perfectly. Users reveal new needs, integrations behave unexpectedly, and stakeholders change their minds. That's why "What happens if the scope changes?" should sit near the top of your hiring checklist.

Look for a practical change process. The developer should explain how they record a request, estimate its impact, and seek approval before doing additional paid work. Ask whether you can trade one feature for another, defer lower-priority work, or release a smaller version first.

Distinguish a new requirement from a defect, too. If an agreed feature doesn't work as specified, will the team fix it within the original fee? If you request a different behaviour, how will they price it? Documenting that distinction early helps both sides avoid arguments over whether a request counts as "extra."

Who Owns the Keys After Launch?

Ask directly: "Who owns the codebase after launch, and when does ownership transfer?" Don't assume that paying an invoice automatically gives you every right you need. The contract should explain ownership of custom code, any payment conditions, and the treatment of existing tools or reusable components.

Ownership also differs from access. Ask whether you'll control the source-code repository, hosting account, domain, deployment credentials, and relevant third-party accounts. Where practical, establish business-owned accounts from the beginning and give the development team appropriate access rather than building everything around one person's login.

Ask how another developer could take over, too. You should expect an agreed handover package covering setup instructions, deployment steps, dependencies, and essential system documentation. Open-source and third-party components retain their own licences, so ask the team to identify those obligations too. A clean exit route protects your business without undermining a good working relationship.

What Happens on Tuesday Morning After Launch?

Launch day is a milestone, not a maintenance strategy. Browsers change, dependencies need updates, and real users find unexpected ways to use a product. Before hiring anyone, ask: "What does post-launch support cost, and what does it include?"

Separate defect fixes, routine maintenance, and new feature development. A short warranty period may cover agreed defects, while ongoing support may use a retainer, hourly billing, or another arrangement. Ask about minimum charges, included hours, exclusions, and any process for approving additional spending.

Then discuss response expectations. "We offer support" means little unless you know the service hours, contact route, and handling of urgent incidents. Clarify whether a promised response time means acknowledgement or resolution. Establish who monitors uptime, manages backups, and tests recovery, too — these responsibilities should never depend on an unspoken assumption.

Will You See Progress — or Just Hear About It?

Good communication makes technical work easier to evaluate. Ask: "How will we see progress, and how often will we review working software?" Regular demonstrations help you spot misunderstandings while the team can still correct them cheaply.

Ask who acts as your day-to-day contact and what input they need from you. You may need to approve designs, answer domain questions, supply content, or arrange access to existing systems. A realistic schedule accounts for those dependencies instead of pretending the developer can work in isolation.

If you're choosing a software agency UK businesses can collaborate with comfortably, discuss working-hour overlap, subcontractor locations, and data-handling arrangements rather than assuming a UK address answers every operational question. Wherever the team works, agree on a straightforward reporting rhythm covering completed work, upcoming decisions, risks, and budget.

Turn the Sales Conversation Into a Useful Comparison

When learning how to vet a software development company, consistency helps more than a long list of clever questions. Give each candidate the same short brief and ask the same core questions. Then record their answers under headings such as team, scope, pricing, ownership, evidence, and support.

Look for specific answers backed by examples or written terms. "We're flexible" is less useful than a clear change-approval process. "You own everything" needs contractual detail, too. A thoughtful question from the developer can also signal strength — good partners investigate your users, constraints, and business goals before recommending a solution.

Choose the partner whose approach you understand and whose commitments you can verify — not simply the most confident presenter. You can use this checklist with any prospective developer. And if you're considering us, we're happy to answer these for our own process directly — get in touch, so you can make the same informed comparison.