PryonexMethod
Three stages, and the honest exit at the end of each one.
We work in three stages. Each one answers a question, produces something you keep, and ends with a decision that is yours. Any of them can be the last one, and that is a normal outcome rather than a failure.
The three stages
What actually happens, stage by stage.
Open a stage to see what it answers, what we do, what you receive, and when we would tell you not to continue.
01DiagnoseWhere is the work actually breaking?
- What this answers
- Where the work breaks, who owns which decision, and what context keeps going missing. Not what software to buy.
- What we do
- We talk to the people doing the work, follow one real case end to end, and write down where it stalls and who was waiting for whom. We look at what already exists before proposing anything new.
- What you receive
- A problem statement your own team recognises and agrees on, the decision and ownership map behind it, and a short view of the options with what each one would demand of you.
- The decision that follows
- Whether the problem is worth solving with software at all, and if it is, which single part to make tangible first.
- When going further is not justified
- If the diagnosis shows the problem is a process, an ownership gap or a staffing question, we will say so and stop. You keep the problem statement, and it is usually cheaper to act on than anything we could have built.
02PrototypeDoes the intended way of working actually hold?
- What this answers
- Whether the way of working we agreed on survives contact with the people who would have to live with it.
- What we do
- We build the narrow slice that carries the risk, using real examples rather than invented ones, and put it in front of the people who would use it. We change it while changing it is still cheap.
- What you receive
- A working prototype you can open and operate, a record of what changed after people used it and why, and a clear statement of what is still unknown.
- The decision that follows
- Whether to build it properly, and if so, what the first release must contain and what can wait.
- When going further is not justified
- If people do not use the prototype, or the workflow only holds when someone is watching, that is the answer. Stopping here is a good outcome. The expensive version of this lesson arrives after the build.
03BuildWill it still work on an ordinary Tuesday, a year from now?
- What this answers
- Whether this can be a real system that people depend on, rather than a demonstration that impressed everyone once.
- What we do
- Design, build, deploy and keep improving it, with the authentication, consent, audit and operational discipline that running a live system properly requires. We agree the handover at the start, not at the end.
- What you receive
- A system in production, the operational detail needed to run it, and a route for your own team to take it forward. What we learn from real use goes back into the work.
- The decision that follows
- What the system should learn to do next, based on what people actually did with it rather than on what a roadmap assumed a year earlier.
- When going further is not justified
- If a capable tool already does most of this, we would rather help you use it well than rebuild it. We take on focused, bounded engagements, so we will tell you when the work is larger than what we should be responsible for.
Where this method has been used
The three stages are not specific to one industry. We have run them while building our own product for insurance agents, and in diagnosis and prototype engagements across healthcare, manufacturing, professional services and public-sector operations.
Engagement details stay confidential. We do not name clients.
Where this starts
Most of it begins with one honest description.
You do not need a specification to start a conversation. A description of where the work keeps getting stuck is enough for us to tell you whether we are the right people.
A person reads every enquiry. You are welcome to write in English or Bahasa Malaysia.