Start with a free initial conversation.
A short first conversation helps us decide whether the work is a fit. Tell us what your team is trying to do and where it gets stuck. You don’t need a technical plan. The initial fit conversation is free.
Paid discovery, builds, and improvements are scoped case by case. We agree on the deliverables, timing, and cost before work begins.
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 working out what it does and which business rules it enforces. 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. Your staff already have a process, including everything they do to work around the software, and the requirements start from that.
Why inconsistent data blocks automation
What we learn narrows down what to build.
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 anyone writes code.
What we need from each other.
An onsite visit, staff interviews, and working reviews are part of the engagement. Before work starts, we agree on access, whose time we’ll need, and who makes the business decisions.
Time in your workplace
An onsite visit needs to happen. We agree on the timing together, during discovery or later in the project. You make room for us to work alongside your staff, and we use that time to pick up the details a call can miss.
Interviews with the people who will use it
Your team makes time for us to learn their roles, what makes the job hard, and how they work around it. Then we bring what we learned 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 decide when requirements conflict. We explain the options, what each one leads to, and what we’d recommend, so they can decide.
Time to try the software as it takes shape
Staff need time to try working versions with real examples. We make each version concrete enough to question and change before the next decision depends on it.
Your staff try each piece as we build it.
Each piece gets tried on real examples, so your staff can question a decision or point out what doesn’t fit while it’s still easy to change.
For example, staff spot a missing rule
The wording depends on more than where the job is.
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.
At each review we agree on what counts as accepted, what’s still open, and how we’ll handle changes, so the next piece starts from something everyone has already checked.
How do you judge progress during a build?Agree on ownership and access before work starts.
Each project agreement defines rights to the delivered work, how reusable components can be used, source-code access, repository and account access, documentation, and third-party licenses. We agree on these terms before work begins.
Someone still has to look after the software once it’s live.
After the build, the work usually moves into Care, Growth, or Advisory, depending on how much maintenance, new development, and technical decision-making is ahead. If you already rely on a system, we can start with that work without assuming you need a new build.
See the ongoing packages