Understand
What actually happens, what is wrong and what would a good result look like?
AX / SYSTEM DESIGN · SZEGEDPROBLEM → MODEL → SYSTEM
SYSTEM DESIGN · PROCESS DESIGN · DEVELOPMENT
Real problem.Working system.
I do not start with a preselected technology. First I understand how the situation actually works: who uses it, what information moves through it, where decisions are made and where control is lost. Only then do I build the system that is genuinely missing.
AX / LIVE SYSTEM MODELRELATION MAPCONTROLLED
INPUT / APEOPLEroles · responsibility
INPUT / BDATAinformation · documents
INPUT / CPROCESSstate · decisions
INPUT / DTOOLSweb · mobile · integration
SYSTEM COREREAL
OPERATIONrelationships · rules · control
OPERATIONrelationships · rules · control
OUTPUT / 01WORKING SYSTEM
AXIS / RELATIONX 048.21Y 021.06
PROBLEM FIELD → SYSTEM CORE → CONTROLLED OUTPUTAXIONA / 2026
I design the system.
Model
Roles, data, states, relationships and decision points become one coherent system.
Build
Only then do we decide what software, automation or tool is justified.
FROM PROBLEM TO WORKING SYSTEM
I am not building a screen.I am assembling an operation.
The interface is only the visible layer. Underneath it are process, data, access, decisions, automation and operations. They need to work together.
01 / DISCOVERYOBSERVE
Start with the real situation.
I do not assume how something works. I map the people, information, exceptions, bottlenecks and actual goals.
02 / SYSTEM BLUEPRINTMODEL
Turn complexity into structure.
The operation becomes a model: states, responsibilities, data, relationships, access and verifiable rules.
03 / DELIVERYBUILD
Technology finally gets its proper place.
Custom software, automation, integration, web or mobile — only what has a real function inside the system.
NOT EVERY PROBLEM IS A WORKFLOW
The type of problemdefines the system.
It may be a business problem, a work problem or something highly specific. Not everything needs automation and not everything needs a separate application. The solution should respond to the actual gap.
Clarity
It is not clear what is happening, where something stands or what belongs together.
→Decisions
There is plenty of information, but no useful support for the next step.
→Control
You need to see what changed, what works and where intervention is needed.
→Connection
People, devices or systems work separately even though they need to work together.
→Reliability
Too much depends on memory, routine or one person.
→Specific idea
A project, task or hobby needs a tool that simply does not exist yet.
→Software is not the answer to every problem. First we need to see exactly what is missing — and build only if a digital system genuinely improves the situation.
The system is not merely delivered.It stays operable.
Design, verification, release and operations form one continuous lifecycle.
- 01 / FOUNDATIONUNDERSTAND
Understand
Real situation, goals, people and constraints.
- 02 / DESIGNMODEL
Blueprint
Data, states, roles and relationships.
- 03 / BUILDIMPLEMENT
Implement
Software, automation and integrations.
- 04 / CONTROLVERIFY
Verify
Testing, security and quality gates before release.
- 05 / RELEASESHIP
Release
Controlled versions and rollback capability.
- 06 / OPERATEMAINTAIN
Operate
Monitoring, updates, backups and improvement.
SECURITY AND OPERABILITY
I am not building a demo.I am building a usable system.
A good system does not only work during the first presentation. It is verifiable, protected by access rules, safe to release, recoverable and maintainable later.
Quality gates
Testing and verification before changes ship, not firefighting afterwards.
Security foundations
Access, data handling and attack surface are part of system design from the start.
Maintainability
The system remains understandable, updateable and safe to evolve.
ONE CONCRETE EXAMPLE / AXIONA KEEPER
From a documentto a clear next step.
Keeper is only one example of how an everyday problem becomes a complete system: document reading, recognition, relationships, deadlines and human approval combined in one operation.
AXIONA KEEPER / DOCUMENT 0248REVIEW
Invoice · 2026-08-18RECOGNITION 98% · 3 RELATED ITEMS
SUMMARYPayment document with deadline
DUE DATE2026-09-01
RELATIONProject / Purchasing / Q3
NEXTApproval required
Have a problem that off-the-shelf software does not solve?
Show me the situation. First we work out what actually needs to function — only then do we talk about technology.
Discuss it↗