Most advice on choosing a custom software development company focuses on the build. Portfolio, process, technology stack, timeline, price.

Those matter, and they are not where projects go wrong. Projects go wrong in year three, when the software is running the business, the people who built it have moved on, and nobody can answer a question about why it does what it does.

We have been building business software since 2003, and we are still supporting some of what we built in that first decade. That is an unusual position to write from, and it shapes what we think you should be asking.

Here are the questions that separate a vendor who will still be useful to you in five years from one who will not.

Ownership: ask it in writing, before you sign

The single most expensive assumption in this industry is that paying for software means owning it. Sometimes it does. Frequently it does not, and the discovery comes at the worst moment.

Get written answers:

• Who owns the source code when the project is complete, and does that change if the engagement ends early?
• Where does the code live, and do you have access to that repository today rather than on request?
• Who holds the credentials — hosting, domain, database, certificates, app store accounts, third-party API keys?
• What third-party components are used, under what licences, and does any of it carry an ongoing fee you will inherit?
• If we part ways tomorrow, what exactly do we walk away with, and can another developer pick it up?

A vendor who answers these plainly is telling you something about how they operate. A vendor who gets uncomfortable is also telling you something.

What to Ask a Custom Software Development Company About Handover

Ask: who else at your company understands this system?

If a custom application is built by one developer who holds the whole design in their head, you have bought a dependency on that person. That is true whether they work for the vendor or for you.

Follow-ups worth asking:

• What documentation will exist at the end, and is it a deliverable or an afterthought?
• Is the architecture written down anywhere a new developer could read it?
• If your lead developer left, who picks this up and how long would they take to become useful?

The honest answer to that last one is never “immediately.” A vendor who says otherwise has not thought about it.

Understand what a fixed price actually buys

Both pricing models are legitimate, and each fails in a predictable way.

Fixed price transfers risk to the vendor, which sounds good until you want a change. The vendor has priced a defined scope, so every deviation becomes a change order, and you spend the project negotiating rather than building. Fixed price works when the requirements are genuinely well understood, which is rarer than anyone believes at the start.

Time and materials keeps flexibility and transfers risk to you. It works when there is trust and visibility, and it becomes an open-ended commitment when there is not.

What matters more than the model is what happens when the estimate is wrong — because it will be. Ask directly: when this runs over, what happens? A vendor with a clear answer has been through it. A vendor who says it will not run over has not.

What good discovery looks like

Before anyone writes code, a competent vendor should be asking about things that are not software.

How the process actually works today, including the parts people do informally. What the exceptions are. Who uses the system and what their day looks like. What happens at month-end and year-end, which is where most business systems reveal their real complexity. What the data looks like now and where it comes from.

If the first meeting is about screens and features rather than how your business operates, that is a signal. Software that fits a business is built by people who understood the business first.

Paid discovery as a separate, small engagement is usually money well spent. It gives you a written specification you own, and it lets you evaluate how they work before committing to the whole build.

Red flags worth taking seriously

No questions about your data. Existing data is where migrations go wrong. A vendor who does not ask about it early will discover it late, at your cost.

A demo that answers every question. If the demo appears to do exactly what you need with no gaps, either they have built something very close before — ask to speak to that client — or you are seeing a prototype dressed as a product.

Reluctance to put you in touch with long-term clients. New client references are easy. Ask for a client they have supported for more than three years, and ask that client what maintenance has been like.

No written architecture. For anything beyond a small application, there should be a document describing how the system is structured and why. If it does not exist at the start, it will not exist at the end.

Vagueness about who does the work. Knowing who is actually writing the code, where they sit, and how they communicate is reasonable to ask and reasonable to answer.

How a Custom Software Development Company Handles Long-Term Support

The build is a project. The support is a relationship, and over a ten-year life it is usually the larger number. A good custom software development company should make ownership, documentation, support, and handover clear before the build begins

Settle before signing:

• What is included after launch, and for how long? Bug fixes for thirty days is not a support arrangement.
• What is a defect versus a change? This distinction generates most post-launch disputes. Get it defined in writing.
• What is the response commitment when something breaks in production, and what are the hours?
• How do you handle platform deadlines? Operating systems, databases, and frameworks all reach end of support, and someone has to plan for that — see our guides to Windows Server 2016 end of support and SQL Server 2016 end of support for how quickly those arrive.
• What does year three look like in cost and involvement?

That last question is the one we would ask if we were buying. It reveals whether a vendor is selling you a project or planning to be useful to you.

Structure the first engagement to limit your exposure

Whoever you choose, do not make the first commitment the whole build.

Start with paid discovery that produces a specification you own. Then build the first real slice — something small enough to be low risk and real enough to be used. You will learn more about a vendor from one delivered slice than from any number of reference calls, and if it goes badly you have lost weeks rather than a year.

If the software is replacing an existing system, the same staged approach applies for a different reason — our guide to legacy application modernization covers why replacing a long-running system piece by piece beats a single cutover.

Where ITsoft fits

We build database-driven web applications, Windows applications, and mobile applications for U.S. businesses, and we still support systems we wrote in our first decade. That is the part we would want you to weigh — not the portfolio, but the fact that we are still answering questions about software we built fifteen years ago.

We are comfortable with every question on this page being asked of us, which is why we wrote them down.

Talk to Mike Treat about your project — we will tell you honestly whether custom software is the right answer, including when it is not. Plenty of problems are better solved by configuring something that already exists.

Related reading: software and web development · legacy application modernization · Microsoft SQL Server database development