How Kalax works.
Kalax doesn't start with a technology. It starts with the business problem or requirement, works out what response is warranted, and only then decides what should be built, changed or implemented — if anything.
Problem unclear? Start with Diagnose
Know what you need? Discuss the requirement directly
From the problem to what's warranted.
An engagement can end at stage 02 or 03 — with a recommendation, a plan or a defined requirement. Stages 03 to 05 happen only when implementation is warranted.
Understand the problem
The business situation or requirement, its constraints, the systems already in place, and what actually needs to change. No technology is chosen yet.
Recommend a direction
Decide what response is warranted: automation, software, an integration, better use of information, marketing or search analysis, advisory, a requirements or architecture exercise, an improvement to an existing system — or not building anything.
- If warranted
Scope the work
If implementation is warranted, agree the intended outcome, boundaries, dependencies, key technical decisions, deliverables and commercial scope before work starts — in as much detail as the work needs. A formal PRD or BRD is one option, not a requirement.
- If warranted
Implement & validate
Build, configure or integrate what was agreed, test it against the real problem and requirements, and iterate where needed.
- If warranted
Deliver, and continue if needed
Deploy and hand over, with documentation appropriate to the system. Ongoing maintenance or iteration is optional and scoped separately.
How the work is run.
Clear scope
What is being done — and what isn't — is agreed before implementation begins.
Visible decisions
Important technical and product decisions are explained rather than hidden, so they can be questioned.
Appropriate documentation
Documentation matches the system and the engagement, rather than being produced for ceremony.
Direct communication
Uncertainty, blockers and trade-offs are raised when they appear, not smoothed over.
Maintainable systems
Unnecessary complexity is avoided, so what is delivered can be understood, operated and changed.
Common questions.
How long does the work take?
It depends on scope, complexity, dependencies and the type of engagement. Timing is estimated once the problem or requirement, and what it depends on, is understood.
What if I don't know what I need?
Start with Diagnose. Describe the business problem, Sam reviews it, and you receive a recommended next direction. Diagnose is free for now, and any implementation is scoped separately.
What if I already know what I need?
Email the requirement and discuss scope directly. You don't need to go through Diagnose first.
Do I need Advisory before a build?
No. Advisory is paid, deeper consulting on a specific decision, with written recommendations. It is useful when a decision needs that depth, but it isn't a prerequisite for a build, and it isn't the same as Diagnose.
Can Kalax work with an existing team?
Yes, where it suits the work — for example, defining the requirements or architecture that your team then builds. How Kalax works alongside a team is agreed as part of the scope.
What happens after delivery?
It depends on the engagement. Handover and documentation are agreed as part of the scope, and ongoing maintenance or iteration can be scoped as a separate engagement.
A business problem — or a requirement?
Problem unclear? Start with Diagnose — technology isn't presumed. Already know what you need? Email the requirement and discuss scope.