A website, an app, and an automation can all look like the answer to the same business problem. The useful first step is figuring out where the work gets stuck.
What is someone trying to do?
Describe the task without naming the technology. “Help a parent understand whether this school fits their child” is a better starting point than “rebuild the homepage.”
The task gives you something to design around and a way to judge whether the work helped.
Where does the current process break down?
Walk through the actual steps with the people doing the work. Notice the copying and pasting, the information that arrives late, and the question everyone has to ask twice.
A new interface cannot fix a missing decision. Sometimes the first improvement is agreeing on who does what.
What already works?
List the tools, data, and habits that are useful today. Keeping a familiar system and improving one connection may be more valuable than replacing the whole workflow.
A custom application is worth considering when the business process has specific needs that existing tools repeatedly fail to meet.
What is the smallest useful version?
A useful first version completes a real task from beginning to end. That is different from building a little bit of every planned feature.
For a customer portal, the first version might let a customer find their documents and ask a question. For an internal tool, it might connect one job from scheduling through completion.
How will you know it helped?
Pick a practical measure before the build. That could be whether people can complete the task unaided, whether information reaches the right person, or whether a manual step disappears.
The measure should match the problem. A visually impressive site can still fail if visitors do not know what to do next.
A focused scoping engagement can turn these answers into a written plan. Bring the messy version of the problem. That is what the conversation is for.