Working here
idataraya is a compact engineering organisation. The operating model favours individual ownership, written communication, and long engagement horizons. This page documents how the team works in practice.
See open rolesFour operating practices that define day-to-day work across the organisation. These are applied uniformly across functions and engagement stages.
Collaboration operates primarily through written surfaces: Slack threads, pull requests, and Notion documents. Synchronous meetings are reserved for decisions that benefit from real-time discussion. Core overlap hours are 10:00 to 16:00.
Each client engagement is staffed by a small team that carries end-to-end responsibility for the outcome. The same engineers conduct discovery, build the system, deploy it, and remain on the engagement for operations.
Engineers engage with clients directly. Field visits to client sites are a regular part of discovery and iteration work. Software behaviour is validated against observed operations, not inferred from requirements documents.
Decisions are taken where the information resides. Engineers closest to a system make implementation decisions on it without escalation. Cross-cutting decisions move through written proposals and open review.
Principles applied during code review, design evaluation, and hiring assessment.
A smaller system that behaves correctly under production load is preferred to a larger system with open correctness questions. Features are completed, not abandoned in partial states.
Behaviour is declared in code rather than conventions. Assumptions are documented where they cannot be inferred. Error conditions are handled rather than allowed to surface unpredictably.
Implementation clarity is prioritised over compact or optimised forms. The measure is a future engineer's ability to understand and modify the code without the original author present.
Systems are designed to be monitored, diagnosed, and recovered in production. Logging, metrics, and operational runbooks are authored alongside the code, not afterward.
Engineers at idataraya work across the application, data, and device layers. A single engineer routinely ships user-facing features, maintains the data pipeline feeding those features, and troubleshoots the hardware integrations they depend on. The organisation does not separate frontend and backend functions.
Delivery is defined by running software installed on client infrastructure and accepted by the client. Engineering progress is measured by acceptance events, not internal velocity. Work that has not been deployed is not considered complete.
The engineering team that designs and builds a system remains responsible for it after go-live. Incident response, iterative enhancements, and capacity management are performed by the original engineers. There is no handoff to a separate support organisation.
FPX, DuitNow QR, Pos Laju integration, and Bahasa Malaysia coverage are treated as primary requirements in system design. Payment rails, address formats, and regulatory conventions are implemented at the data model layer, not retrofitted as localisation.
A short introduction and a link to something you have built and operated is enough to start a conversation.