Skip to content
  • New: asasii S2 handheld barcode scanner. 1D and 2D, IP52 rated.View S2
  • asasii POS is live and deploying to Malaysian retailers.See asasii POS
  • asasii BSC: supply chain software for multi-outlet operators.See asasii BSC
  • Browse the full asasii hardware line: terminals, printers, scanners, payment, drawers.View hardware
idataraya
idataraya

Engineering culture.

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.

How we work in practice.

Four operating practices that define day-to-day work across the organisation. These are applied uniformly across functions and engagement stages.

Asynchronous by default

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.

OPS-ASYNCCommunication surfaces
Verified
  • Primary channelPull requests and Notion
  • Synchronous meetingsDecision-oriented only
  • Core overlap window10:00 to 16:00
  • Status reportingWritten, weekly cadence
Written over verbal

Small engagement teams

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.

Engagement staffing patternTypical team composition
System statusEnd-to-end ownership
  • Discovery phaseSame team throughout
    Operational
  • Build phaseSame team throughout
    Operational
  • Deployment phaseSame team throughout
    Operational
  • Operations phaseSame team throughout
    Operational
No handoff boundaries

Direct client access

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.

Typical engagement cadenceAuto
WhenEngineer on-siteclient operational context
Then
  1. 1Observe counter operationscashier shift, live
  2. 2Validate refund workflowoutlet manager session
  3. 3Run scanner integration testwith warehouse team
  4. 4Document findings for teamwritten summary
Verified against practice

Distributed decision authority

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.

DECISION-PROCESSDesign decision, typical lifecycle
Accepted
ProposalReviewDecision

What we value in engineering work.

Principles applied during code review, design evaluation, and hiring assessment.

01

Correctness over completeness

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.

02

Explicit over implicit

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.

03

Readable over clever

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.

04

Operable over complete

Systems are designed to be monitored, diagnosed, and recovered in production. Logging, metrics, and operational runbooks are authored alongside the code, not afterward.

See how the team is structured.

Open positions, team breakdown, and how to apply.