Before you sign with a software firm: the questions that separate builders from sellers

The questions that matter most, in one paragraph

Before you hire a custom software firm, ask how they will learn your business before quoting, who will actually write and review the code, how often you will see working software, how they will move and protect your data, who owns the finished code, and what happens after launch. The answers tell you more than any portfolio. A firm that is vague on discovery, demos or support is usually selling hours, not solving your problem.

I sit on the other side of these conversations every week, and I would rather a prospective client ask hard questions than easy ones. The rest of this guide explains each question, what a good answer sounds like, and which answers should make you walk away.

How will you learn our business before you quote?

This is the most revealing question you can ask. The most expensive mistake in custom software is building the wrong thing well, and it happens when a firm prices a project from a one-hour call and a few screenshots. A good answer describes a discovery or design phase: interviews with the people who do the daily work, a map of the real process rather than the official one, an inventory of the data and systems involved, and a written scope you review before any build estimate.

At Aezion this is the first stage of our Design, Develop, Validate and Steward cycle, and it is where we invest the most effort up front. Whatever firm you choose, ask to see a sample discovery document. If they do not have one, they probably do not do discovery.

• Who from your team will you need to interview, and for how long?
• What document will we receive at the end of discovery?
• Can we take that document to another firm if we choose to?
• How do you handle the exceptions our current spreadsheets deal with quietly?

Who will actually write and review the code?

The people in the sales meeting are rarely the people who build the software. That is normal, but you deserve to know who will do the work, where they sit, how experienced they are and whether the same team will stay with the project from start to finish. Turnover in the middle of a build is one of the quieter ways projects slip.

Ask how the team is structured and who your named point of contact will be. We are open about our own model: a Frisco headquarters with development centers in the US and India, which keeps cost of ownership down while giving clients a local contact. Ask every firm to explain its model as plainly, including how code is reviewed before it reaches you and who is accountable when something goes wrong.

How often will we see working software?

The right answer is regularly and early. Agile delivery works in short, fixed cycles that each end with something you can see and test. The Scrum Guide, the reference document for the most widely used agile framework, describes sprints as fixed-length events of one month or less, each followed by a review where the outcome is inspected and next steps are adapted. Firms vary in their exact rhythm, but you should be looking at real screens within the first few cycles, not a big reveal at the end.

Frequent demos protect your budget. They let you catch a misunderstanding when it costs a day to fix rather than a month, and they let your staff start getting used to the new way of working before launch. If a firm proposes months of silence followed by a delivery date, ask why.

How will you test it before our people depend on it?

Testing is the line item most often trimmed to make a proposal look cheaper, and it is the one you will miss most on launch day. Ask what kinds of testing are included and who does them. A serious answer covers functional testing of every workflow, testing on the browsers and mobile devices your staff and customers actually use, testing of the connections to other systems, and load testing to see how the application behaves when many people use it at once.

Ask also who signs off. In our Validate stage, work continues until the client is certain the solution meets their needs, and your own staff should take part in that acceptance testing. They know the odd cases, like the customer with two billing addresses or the order that ships in three parts, that a test script written by outsiders will miss.

Finally, ask how defects found after launch are handled. Is there a warranty period, how are fixes prioritized and how quickly does a critical problem get attention? A firm that has thought this through will answer without hesitating.

Red flags that should end the conversation

Some answers are reason enough to keep looking. None of these is about price; a firm can be inexpensive and excellent, or expensive and careless. These are signs that the process behind the price is weak. Any one of them can usually be explained; several together usually cannot.

If you are seeing several of these, it is worth pausing and getting a second opinion before you sign anything. A short conversation now costs far less than a stalled project later.

• A firm fixed price before anyone has seen your process or data.
• No mention of data migration, testing or security in the proposal.
• Agreement with every idea you raise, with no pushback or questions.
• No named point of contact, or a different contact at every meeting.
• Vague answers about who owns the code and the cloud accounts.
• No plan for support, hosting or updates after launch.
• References only from projects much simpler than yours.

What happens to our data, and who owns what you build?

New screens are the visible part of a project. Moving your existing data is the part that decides whether people trust the system on day one. Ask how the firm will inventory your spreadsheets, documents and old databases, who will clean duplicates and inconsistent codes, and how they will prove the migrated data is complete. Bad data moved into a good system is still bad data.

Then ask about ownership and access. Who will own the source code, the cloud accounts, the domain and the administrator credentials when the project ends? Whose name will be on the hosting bill? These are contract terms, and it is worth having your attorney read that section before you sign. The safest arrangement is one where your company could hand the system to a different firm without asking permission.

• How will you test that every record arrived correctly?
• Where will our data be stored during development, and who can see it?
• What security testing happens before launch?
• Will we hold the administrator accounts from the start?

What does support look like after go-live?

Software that nobody maintains becomes the next legacy system. Ask whether the firm offers ongoing support, security patching, monitoring and hosting, how quickly they respond to problems and how enhancements are priced. Ask what happens if you decide to bring support in-house: will they document the system and train your people? A firm confident in its work should be comfortable with that question, because good documentation is part of what you paid for.

A firm that disappears at launch leaves you with an orphan application. We built our Steward stage around this, and I cover the details in my guide to planning maintenance after launch.

Checking references in a way that tells you something

Most firms can produce a happy client. The useful reference is one whose project resembled yours in complexity: similar number of workflows, similar integrations, similar data problems. Ask for that specifically. Then ask the reference what went wrong and how the firm handled it, because every project has a rough patch and the response to it is what you are buying.

Public review sites help as a first filter. Aezion has a profile on Clutch with verified client reviews, and most established firms have something similar. Read the reviews for patterns about communication and deadlines rather than the star rating alone. When you compare proposals side by side, my guide on what drives custom software cost explains why two quotes for the same idea can be far apart.

Finally, pay attention to how the firm treats your questions. A partner who answers directly, admits what they do not know and pushes back on your ideas when they have reason to is one you can work with for years.

How I answer these questions for our own clients

Since I am asking you to put these questions to every firm, here is how we answer them. We start every engagement with discovery and design. We build in agile increments with frequent demos so you see progress throughout. We validate the work with quality engineering, including web, mobile, API and load testing, until you are certain it meets your needs. Then we steward the system through support, security and managed hosting. Our A-Z Performance Guarantee sums up the promise: We Get It Right, We Make It Right, Period.

If you are a founder rather than an established company, the questions are the same but the stakes differ; my guide on how long it takes to build a startup MVP covers that path. If your starting point is a business running on spreadsheets, my guide on replacing the spreadsheet that runs your company will help you prepare. Either way, a first conversation with us is a working session on your problem, and Dallas-area leaders are welcome to meet us in person.

Questions people ask me