Most companies hire a software development partner two or three times in a decade. The firms you’re evaluating do it every week. That gap is why the same questions come up on every discovery call, and why we first wrote this list in 2016 and still hand it out. This is the 2026 version.
The point isn’t to trip anyone up. It’s to make every firm answer the same questions so you’re comparing answers, not sales decks.
Who owns what
Who owns the finished product?
In a work-for-hire arrangement the code and the intellectual property belong to you. Ask anyway, and read the contract. Some firms keep ownership of “frameworks” or “accelerators” they bring to the project, which can leave you unable to move the system to another team later. One detail from the original version of this post still holds: ownership usually transfers when the project is paid in full. If you dispute an invoice mid-project, know what that does to your rights.
Who maintains it after launch?
Software is never finished. Dependencies age, browsers change, cloud providers retire services. Note that maintenance does not mean new features. The line between the two gets blurry fast, so get it in writing: what’s covered, for how long, and what a support hour costs after that. We run hosting and support as a separate, priced service so nobody has to argue about it later.
Technology and team
Do they know more than one stack?
You want a team that picks the technology your requirements call for, not the one they happen to sell. Ask what they chose on their last three projects and why. Ask about a time they had to learn something to integrate with a client’s existing system. A firm with one answer to every problem will fit your problem to its answer.
Who, by name, will work on this?
Architecture, user experience design, testing, project management. A complete build needs all four, and they are rarely the same person. Ask whether the people in the sales meeting will be on the project. Ask what happens if one of them leaves.
How do they run a project, and what does it feel like from your side?
In 2016 this question was about agile versus waterfall. Today the useful version is about money and scope. What happens when scope grows? What happens when you’re 60% through the budget and 40% through the work? Who decides what gets cut?
Our answer: we work to a fixed budget with controlled scope, we validate before we build, and we take on the hardest things first so the surprises come early, when they’re cheap. Any firm should be able to describe its version of that in plain English. If the answer is “we bill hourly and keep going,” you’ve learned what you need to know. More on how we run it under our approach.
Can the technology grow with the company?
There may be good reasons of cost or time not to build for a future that’s three years out. That’s a fair decision. But the conversation still has to happen, and the path to the bigger system should be written down even if you don’t take it yet.
Industry experience or technology experience?
Depending on your needs, specific technical depth may matter more than experience in your industry. In other situations the vertical knowledge is the whole game. It varies, sometimes within the same company. Ask for both and decide which one you’d trade away.
How is your data protected?
Uptime, backups, and how you’d export your data to another system if you had to. Add a 2026 question: does any of your data get sent to a third-party AI model, and under what terms?
How do they use AI in the work?
Every serious firm now uses AI tools to write and review code. That’s fine. The questions are who reviews what the tools produce, who is accountable for it, and whether the firm is passing the productivity gain along or just billing the same hours. A firm that can’t answer this hasn’t thought about it.
Communication and location
Can you talk directly to the designers and developers?
There has to be a process and a project lead on both sides. But hierarchy shouldn’t slow down the resolution of a problem. Some firms keep clients and developers apart. We find projects go better when the client can talk to the people doing the work, because fewer things get lost in translation and the relationship is stronger when something goes wrong.
Do they outsource any of the work offshore?
Ask about the makeup and location of the team, and how they scale up or down. Sending technical work offshore is common in this industry. We don’t do it. Our team is in Texas, and the people who build your system are the people you meet. If a firm does use offshore labor, that’s not automatically disqualifying, but you should know before you sign, not after the first stand-up.
What is their reputation?
Ask to contact clients directly, the more recent the better. Tread lightly if they cannot give you any references from happy clients. And if you know of a project that went badly, ask them to explain what happened. How a firm talks about its failures tells you more than how it talks about its wins. Ours are at /why-frogslayer/, including the number we’re most careful about: 96.5% of our projects have met their success criteria across hundreds of projects since 2005.
What to do with the answers
Choosing the right development partner is not easy, just like software projects of seemingly moderate complexity often turn out to be much harder than expected. Ask every firm the same questions, in the same order, and weigh the answers side by side.
Then ask one more: what’s the first step? The answer should be small, priced, and useful even if you never hire them for the build. For a new system, ours is a VDP Sprint: three to four weeks of validation, design, and planning that ends with mockups, requirements, a tech-stack recommendation, and a roadmap with the investment. For a system you already run, it’s a System Evaluation. Either one starts with a 30-minute call at /contact/.