The problem, not the screens

You don’t need to arrive with the solution designed to request a proposal. What helps most is knowing who will use the system, how the work is done today and what result is expected. “We need each incident assigned automatically to the most suitable available technician” says far more than “we want a modern dashboard”.

I also need to know which systems you work with and where the information lives today. If there is a document or internal tool the team uses to manage the process, it is worth seeing, with anonymised data if necessary. That is usually where the undocumented business rules are.

Explore the idea

Prepare a focused conversation

Tick what you already know. The summary separates defined items from open questions.

  1. 01Current work
  2. 02Initial scope
  3. 03Acceptance criteria

What have you already defined?

Separate the essential from what can wait

I recommend starting with a short list of what the first version must solve and leaving the rest for later phases: who has access and what each profile sees, which operations happen daily, which systems it must integrate with and whether there is data to migrate. If a date is decisive, explain why, because it can change the order in which things are built.

With that list, every provider you ask for a proposal is pricing the same project. Without it, each imagines a different system and the proposals can’t be compared.

What I would check in a proposal

Price on its own says little. I would check whether the proposal explains what the system will do and how it will be verified before acceptance. Also what documentation is delivered, how it goes live and how much time your team will need for testing and validation.

Make clear from the start who owns the code, which licences are involved and how maintenance will work. Add the monthly costs of infrastructure, AI model usage and external services, and ask how later changes will be quoted, because they always come.

When an analysis phase comes first

In some projects a reliable figure isn’t possible upfront: for example, when integrating with a poorly documented legacy system or migrating data nobody has analysed in depth. In those cases I propose a focused analysis phase, with a defined scope and deliverable, rather than an unfounded estimate. Most projects don’t need it.

Either way, the first meeting should end with a clear next step: preparing the proposal or gathering the missing information.

If you are considering an AI project or a custom application, here is how I work, or book a meeting and we’ll look at your case.