Find out who will actually do the work.
The people in the first meeting are not always the people who write the software. Ask directly who will design, build, and test your application, how experienced they are, and whether they are employees, contractors, or another firm. Each arrangement can work, but you should know which one you are buying.
Ask who makes technical decisions day to day and who you can reach when something is unclear. A named lead who understands both the code and your workflow is worth more than a large team you rarely hear from. Ask how often you will speak with that person and what happens if they leave the project.
Ask how the team uses AI tools in development and how that work is reviewed. Used well, these tools make a senior team considerably more productive. A good answer describes how generated code is checked, tested, and understood by the engineers who are responsible for it.
Understand how scope and price are set.
A partner should be able to explain how they turn your description of the work into a scope and a price. Good answers involve looking at the actual workflow, the systems it touches, and the data involved before committing to a number, rather than pricing from a short call.
Ask what the written scope will contain. It should name the workflows, users, integrations, data to be migrated, and acceptance criteria, and it should state its assumptions. Ask how changes are requested, estimated, and approved once work has started, because changes will come up. A good partner treats a change request as a normal part of the work.
Compare proposals on what they include, not only on the total. Two prices for “a customer portal” can describe very different applications. The proposal that is clearest about its boundaries is usually the one that will hold. Ask each firm to explain what it has left out, why, and how those items would be priced later.
Ask how quality and security are built in.
Ask what gets tested and how. Useful answers mention automated tests for business rules and permissions, checks that run before every release, and a staging environment where you can review working software with representative data before it reaches your team. Ask who reviews code before it is merged and what happens when a test fails.
Security should come up without prompting. Ask how access is controlled, how one customer’s or location’s data is kept separate from another’s, how credentials are stored, how dependencies are kept current, and how sensitive information is kept out of logs. General reassurance is not an answer.
If your work involves regulated information, ask what the partner can support directly and what it relies on other providers for, such as hosting, payments, or identity. A clear statement of those boundaries is more trustworthy than a broad claim of compliance. Ask for those boundaries in writing, alongside the obligations each party holds.
Agree on what documentation and handover look like.
Software outlives the project that built it. Ask what documentation comes with the application: how the system is structured, how it is deployed, how data flows between systems, and how to handle common failures. Ask to see an example from past work, with sensitive details removed.
Ask how knowledge moves when people change, on either side. A new staff member on your team should be able to learn the application from its documentation and training material. A new engineer should be able to understand the code without relying on the person who wrote it.
Clarify what happens after launch: who hosts and monitors the application, how bugs are reported and prioritized, how updates are made, and what ongoing support covers. These arrangements shape your experience of the software for far longer than the build itself. Ask for them in writing before the project begins.
Judge the communication before you sign.
The sales process is a preview of the project. Notice whether questions are answered plainly, whether the partner asks about your operation before proposing a solution, and whether they tell you when an idea is not worth building. A partner who agrees with everything in the sales process is unlikely to raise hard questions once the work is underway.
Ask how progress will be shown. Regular reviews of working software, a visible list of what is done and what comes next, and prompt notice of problems are more useful than status reports that describe activity without showing results. Ask to see how a recent problem was reported to a customer and how it was resolved.
Baybloom works this way: we put the scope in writing, set the price before work starts, and review working software with you throughout the project. Whichever partner you choose, look for the same clarity, because it is the best early sign you will get of how the rest of the project will go.
Put it into practice
Talk through the project you are considering.
Bring the workflow, the systems around it, and the questions you need to resolve. We can help define a useful next step.
Discuss your project