10 questions to ask before hiring a software company

Most problems come from things nobody asked at the start. These questions save you months.

About the project

• What exactly is included in the price, and what is not?
• How many revision rounds are covered?
• What is the timeline, and what happens if it slips?
• Who writes the content and supplies images?

About ownership

• Will the code, domain and hosting be in my name or yours?
• If I move to another provider, what do I receive?

These two are the most important on the list. Plenty of people discover far too late that their website is not theirs.

About life after launch

• How long is support and what does it cover?
• How are later changes charged?
• If the site goes down at 11pm, what do I do?
• Can I see a delivered project and speak to its owner?

That last one is the real filter. A confident company connects you without hesitating.

Make the comparison on evidence, not labels

The right option depends on risk, ownership and the next two years of change—not the technology name alone. Score each alternative against the same requirements: launch speed, custom workflows, security, content ownership, integrations, support and the cost of leaving later.

Ask for a small proof around the hardest requirement before signing the full project. Also confirm who owns the source files, domain, accounts and data exports. A low starting price becomes expensive when the business cannot move its content or data without rebuilding everything.

• Use one written requirement list for every vendor or option.
• Test the riskiest integration or workflow before full commitment.
• Calculate two-year ownership cost, including support and migration.
• Put ownership, access and exit terms in the contract.

A topic-specific field checklist

• Ask to see one comparable project and the acceptance criteria used—not a portfolio image only.
• Name the project owner, approval route and expected response time on both sides.
• Confirm repository, domain, analytics and production accounts will be owned by the client.
• Write change-request pricing and post-launch defect coverage before work starts.

Details most proposals miss

Vendor and platform comparisons fail when they compare labels instead of failure modes. The hard questions are who can change the product safely, how quickly a fault is diagnosed, what data can be exported, and what happens when the original person or platform is no longer available.

• A requirement scorecard weighted by business risk, not a feature count.
• A proof-of-concept for the hardest workflow or integration.
• Named ownership for domain, repository, production, analytics and vendor accounts.
• A maintenance map showing who updates code, content, dependencies and infrastructure.
• An exit test that exports content and operational data in a usable format.

The TechMate implementation layer

TechMate treats independence as part of quality. The project is structured so the client owns access and decisions while the delivery team keeps documentation, environments and release history understandable.

• One accountable delivery owner across design, content and development.
• Written trade-offs instead of promising that every option is equally good.
• Milestone demonstrations using the client journey, not isolated screens.
• Risk register for integrations, migration and third-party limits.
• Support boundaries and response routes documented before launch.

Delivery phases that reduce risk

Run the decision like a small due-diligence exercise. Start with the irreversible risks, test one difficult requirement and make ownership visible before comparing presentation quality.

• List must-have outcomes and unacceptable failure.
• Weight criteria by operational and financial impact.
• Request proof for the hardest requirement.
• Review ownership, security, support and exit terms.
• Start with a milestone that can be accepted independently.

Questions that reveal implementation quality

• Who replaces the key person if they are unavailable?
• Can another team deploy from the delivered repository?
• What data export has been tested?
• Which limitation is most likely to affect this project?
• What is explicitly outside support after launch?

A realistic scenario

Example: ask the provider to demonstrate a failed form submission, not only the successful path. Their answer reveals validation, error wording, logging, ownership and support thinking in a way that a polished portfolio cannot.