Getting started
What you need ready before a discovery call
You do not need a written specification. Bring the people who actually run the process day to day, a rough sense of what is manual or duplicated today, and any system you already use that the new one needs to work alongside. A budget range helps but is not required before the first conversation.
What matters more than a written document?
A discovery call works best with people, not paperwork. We are trying to understand how work actually moves through your business right now: where it waits, where it gets re-entered, and where two departments each keep their own version of the same information. That picture comes from a conversation, and a document written in advance often ends up describing the process as intended rather than the process as it actually runs day to day.
Who should actually be on the call?
Bring whoever runs the process, not only whoever manages it. A department head can usually describe the process as designed. The person entering orders, checking stock or approving a step every day can usually describe the workaround that keeps the real process moving when the designed version does not quite fit. Both accounts matter, but the second one is the one that is easy to miss if only management joins the call.
What helps, even if it is not required?
A rough sense of budget, a general timeline expectation, and any existing systems the new one has to work alongside all help the conversation move faster. None of them need to be final. If you already run Tally, SAP, Salesforce or an in-house system, mentioning it early means integration gets factored into the conversation from the start rather than raised as a surprise partway through.
What happens to what you bring to the call?
Everything discussed on the call feeds into the mapping phase that follows, where the actual sequence gets walked step by step with the people who run it. Nothing you bring to the first call is treated as final. It is a starting point for mapping to test against, and mapping is where the specification for the build actually gets written.
Bring the first task you want to improve
For a new application, choose a workflow your team could review from entry to completion. For automation, bring a recurring example and the exceptions that make it difficult. Our custom software service and business process automation service explain the two starting points. If AI is part of the brief, include the information it would use and the person who should review its output.
Related questions
Do we need a written requirements document before we talk to you?
No. A requirements document is something mapping produces, not something you need to arrive with. What helps more is a clear sense of where the current process breaks down, described in your own words rather than written up as a formal specification beforehand.
Who from our side should actually be on the call?
The people who run the process day to day, not only the person who manages them. A manager describes the process as designed. The person doing the work daily describes the process as it actually runs, including the workaround nobody wrote down, which is usually the more useful account.
Does budget need to be finalized before the call?
No, though a rough range helps keep the conversation realistic about scope from the start. If you genuinely do not know yet, the typical range for a project like yours is something we can walk through together on the call itself.
What if we only have a rough idea and not a full specification?
That is the normal starting point. A rough idea is what the discovery call and the mapping phase are for. Arriving with a fully formed specification is the exception, and can sometimes mean rework later if it was written without seeing how the floor actually operates.
Should we bring examples of systems we like or dislike?
Yes, if you have them. A screen you have used elsewhere and either liked or actively disliked tells us more in five minutes than a general description of preferences, because it points at something specific rather than an adjective like clean or simple that means different things to different people.
Plan your next software project
Tell us which workflow you want to improve and the systems it depends on. We will help define a practical starting point.