What happens in the first 30-minute call?
You write to Peak Code Consulting or Fiji Solutions and get an answer within one business day, with a practical first step in it. Then comes a call of thirty minutes that costs nothing. We work through the questions about your project together, and by the end of it your path is named: what the first bounded step would be, and why it comes first. A proposal follows only if you ask for one.
Before the call
Which company to write to depends on where your business is. Companies in Switzerland write to Peak Code Consulting, at info@peakcodeconsulting.ch. Businesses in Greece and everywhere else write to Fiji Solutions, at info@fijisolutions.net. Both addresses reach me.
The answer comes within one business day, with a practical first step and with the questions I cannot answer before asking them. I send no questionnaire beforehand.
In the call
We go through the questions about your project together. What I listen for is narrow: what the process actually does, who repairs it when it breaks, what happens to the business if it stops for a day, what already exists in the estate, and who has to agree before any of it changes. That last one is about the people around the process.
What you leave with
By the end of those thirty minutes your path is named: what the first bounded step would be, and why it comes first. You hear it in the call itself, and you can take it to somebody else if you want to. A proposal follows only if you ask for one.
Sometimes the honest answer is that no project should start: the process should be repaired before it is automated, the thing you want built already exists in your estate under another name, or the right first step is one I would not carry out. I say so in the call. Reaching that answer in thirty minutes is a good result.
After the call
The first paid step is bounded before anyone starts: fixed scope, fixed outcome, quoted in writing.
A new build ships with the code in your repository under your organisation, an automated test suite written around your business cases and running in your pipeline, an operations guide written for somebody who was not there, and the architecture decisions, short and dated, with the reasoning for why the alternatives lost.