You can have a useful development consultation before your budget is fixed. The important preparation is to explain the problem, the people involved, the first decision you need, and any real limits you already know.
It is okay to ask before the budget is final
Teams often hesitate because they do not know whether the work costs tens of thousands or millions of yen. A number without a scope is not very informative, and a scope built only to match an arbitrary number may miss the real goal.
The short answer
Share four things before asking for a price:
- The current work and pain.
- The first users.
- The first flow or decision to validate.
- The limits and priorities already known.
Then ask for options: existing service, small prototype, phased release, or production development.
Why budget alone should not define the answer
The same amount can buy very different evidence. It might fund a clickable flow, a technical integration test, a small operational tool, or part of a production system. The appropriate choice depends on what decision comes next.
Do not hide a genuine ceiling. Explain whether it is an approved budget, an exploratory range, or an amount available before another decision.
What to share before the consultation
1. Current work
Describe repeated entry, missed messages, slow approval, or lack of visibility.
2. First users
Name the few people who can test the first version and the roles they represent.
3. First flow
Select one path from start to result. Avoid asking to digitize the whole operation.
4. Budget and priority
State the known range, deadline, and what must not be compromised, such as security or required compliance.
How to think about a small start
A small start may use sample data, one role, one location, a manual review step, or CSV instead of live integration. It should still answer a real question. Write what evidence justifies further investment.
Separate prototype limitations from production requirements so nobody mistakes a temporary shortcut for a safe launch design.
When to discuss budget
Mention the range early enough to avoid designing an impossible engagement, but after giving enough context for the partner to explain trade-offs. Ask what changes between options in deliverables, reliability, operation, and future rework.
AI changes implementation options, not the need for clear decisions
AI-assisted development can reduce effort for some tasks, but it does not remove responsibility for workflow design, data quality, security, testing, ownership, and maintenance. Evaluate the complete delivery and operating model, not a claim that code can be generated quickly.
When it is appropriate to contact a partner with an open scope
Contact them when you can explain the problem and want help selecting the next step. Be explicit if you are requesting discovery rather than a fixed production quote. A responsible partner should say what must be learned before pricing.
A request you can copy
We currently handle [workflow] using [tools]. The main problem is [time/error/visibility/customer impact]. The first users are [roles]. We first want to validate [one flow or decision]. Our current budget status is [approved ceiling/exploratory range/not fixed]. We would like to compare an existing service, a prototype, and phased development, including what each option would and would not prove.
Your next step
Write the decision you need to make after the first investment. Take that statement, one workflow example, and your honest budget status to the consultation.
Further reading
Use official security, privacy, accessibility, and platform documentation to identify non-negotiable constraints. Budget reductions should come from scope and sequencing, not from silently removing those obligations.