What actually happens after you ask for a quote?
For a first software project, the unfamiliar part is often not development. It’s knowing what decisions you need to make, what the agency will deliver and how you’ll judge whether the result works.
Here’s what to ask for at each point.
Before a proposal: describe the work, not a list of screens
A useful first conversation covers who will use the system, the task they are trying to finish, the software involved today and what goes wrong.
You don’t need to know the technology. You do need someone on your side who can answer questions about the process.
Consider a client document workflow. “We need a dashboard” doesn’t tell a developer what to build. “Clients upload reports, staff check them, and the client must see whether anything is missing” is much more useful. It exposes the different users, statuses and permission questions.
What you should receive: a written description of the problem, assumptions, boundaries and an agreed next step. A discovery call is not the same as a fully scoped fixed-price commitment.
Before the build: make the scope testable
Ask the team to show what is in the first release and what has been left out. For each important feature, agree on an outcome someone can demonstrate.
For example: “A staff reviewer can reject a document and the client sees what must be replaced.” That is more testable than “document management.”
Discuss integrations and dependencies early. Who provides access to existing systems? Who supplies sample records? Will data need cleaning or migration? If approvals from third parties are needed, a schedule should account for them.
What you should receive: scope, proposed delivery approach, responsibilities, cost and payment terms, review points, and a way to handle changes.
During delivery: review work you can use
A design review is useful, but don’t rely solely on screenshots. Ask to walk through the actual task with test accounts.
Try the awkward cases: a missing attachment, a duplicate request, the wrong person attempting access, a failed integration. Ask what is real and what is still a mock service.
Feedback should be specific: what happened, what you expected, and which step failed. If you request something outside the agreed scope, the team should explain the effect on cost or timing before treating it as included.
What you should see: working increments, decisions that have been recorded, and a clear list of issues or dependencies.
At launch: check the operating side
Someone needs to own user invitations, account access, source data, updates, alerts and support. These questions matter even for a small portal.
Ask for a handover that identifies the hosting and provider accounts, code or configuration, essential instructions, outstanding limitations and the agreed support arrangement. Check how you would recover from an incorrect import or a failed deployment.
A launch date is not proof that every business outcome has been achieved. Confirm the agreed acceptance checks and note what will be evaluated once people use the system.
Three questions worth asking any development partner
- What will you recommend if our current software can already do this?
- Can you show us the error and permission cases, not only the happy path?
- What will our team own, and who can maintain the system after handover?
The answers tell you more than a long list of technologies.
For examples of the operating work behind an application, see the 21Goals prediction platform and LabLink portal. If you’re planning a first project, tell us who will use it and what they need to accomplish.