The first Working Session helps us decide whether the work is a fit. Discovery is the deeper work of understanding how the business runs today and how you want it to run. With an existing custom system, that includes recovering its behavior and business rules. Where there is no custom system, we check what off-the-shelf tools can support and where gaps remain.
First, we should be able to explain your business back to you.
We interview the people who will use the software and the people who manage the work. We follow real examples through the current systems, including the exceptions, and learn where responsibility and information change hands.
We write that understanding down for your team to correct. The process is already there, including the work people do around the software. Requirements begin with understanding it.
That understanding should narrow the work.
If a build or an improvement is needed, we work through requirements and design with your team: the rules the software must respect, what people need to see and do, and what belongs outside the product. We explain the tradeoffs and agree on the scope before turning those decisions into code.
What we need from each other.
An onsite visit, staff interviews, and working reviews are part of the engagement. We agree on access, participation, and decision-making before work starts.
Time in your workplace
An onsite visit needs to happen. We agree on its timing together, during discovery or later in the project. You make room for us to work alongside your staff; we use that time to understand the details a call can miss.
Interviews with the people who will use it
Your team makes time for us to learn their roles, pressures, and workarounds. We bring our understanding back for them to question and correct.
Access to real examples
You arrange the relevant screens, records, and handoffs. We work through them with you to uncover rules and exceptions a feature request may leave out.
Someone who can resolve business decisions
Your team names a person who can set priorities and resolve conflicting requirements. We explain the options, consequences, and recommendation so they can decide.
Time to try the software as it takes shape
Staff need time to review working versions with real examples. We make the work concrete enough to question and change before the next decision depends on it.
Working reviews keep the build close to the business.
We build in pieces your staff can try with real examples. They can see the behavior, question the decisions, and point out what does not fit while the work can still change.
For example, staff spot a missing rule
The municipality alone is not enough.
A first version uses only the location. Staff point out that flood zone and job type also change which disclaimers belong on the contract.
The next version to review
All three fields choose the wording.
We update the rule, then try an ordinary job and a flood-zone job together. Staff check the contract each one produces.
We agree on what counts as accepted, what remains open, and how to handle changes. Each review gives the next piece of work a clearer foundation.
How do you judge progress during a build?After launch, the responsibility continues.
The relationship usually moves into Care, Team, or Advisory after the build. The right level depends on the maintenance, continued development, and technical decisions ahead. For a system you already rely on, we can begin with that work without assuming you need a new build.
See the ongoing packages