How to Build a Mobile App for Digital Passes and Access Cards
Learn how to plan, build, and secure a mobile app for digital passes and access cards using QR and NFC, with issuance flows, testing, and rollout tips.
Clarify the Use Case and Success Metrics
Before you pick QR vs. NFC—or Apple Wallet vs. an in-app pass—get precise about what a “digital pass” means in your project. A single app might issue , , , or , and each has different requirements for identity checks, revocation, and how often the credential changes.
employee access badges
member IDs
event tickets
time-limited visitor passes
Define the pass type (and the real-world workflow)
Write down what happens end-to-end, including who approves it and what “success” looks like at the door.
For example:
Access badge: tied to a person; needs fast unlock; immediate revocation when offboarded.
Membership pass: may prioritize easy enrollment and renewal over strict access control.
Tickets: high-throughput scanning, anti-duplication, short validity window.
Visitor pass: sponsored by an employee; expires automatically; may be restricted to certain areas.
Identify primary users (not just “end users”)
List the people who touch the system and their goals:
Front desk/event staff: quick verification and troubleshooting during busy periods.
Choose success metrics you can measure
Pick metrics that map to both user experience and operations:
Activation rate: % of invited users who successfully add/enable the pass.
Door-open success rate: unlocks/scans that succeed on the first try.
Time-to-issue: from request/approval to credential usable.
Support tickets: volume, top reasons, and time-to-resolution.
Decide early on offline access (and its limits)
If doors or scanners must work without network connectivity, define how long offline access remains valid (minutes, hours, days) and what happens when a pass is revoked while offline. This choice affects credential design, reader configuration, and your security model later.
Choose How the Pass Will Be Presented: QR, NFC, and Fallbacks
Your “digital pass” is only as good as the moment it’s scanned or tapped. Before you build screens, decide what the reader will accept and what users can reliably present under real conditions (crowds, poor connectivity, cold weather, gloves).
Common presentation options (and what they’re good at)
QR codes are universal and inexpensive: any camera-based scanner—or even a phone camera for visual verification—can work. They’re slower per person than tap, and they’re easier to copy if you rely on static codes.
NFC (tap) feels like a physical badge replacement. It’s fast and familiar, but it depends on compatible door readers and device support. It also has platform constraints (for example, whether you can emulate a card or must use Wallet-based credentials).
Bluetooth (hands-free) can improve accessibility and speed, but it’s more complex to tune (range, interference) and can create “why didn’t it open?” moments.
One-time links / in-app codes (rotating codes, signed tokens) are strong fallbacks and can reduce cloning risk. They require app logic and, depending on design, may require periodic network access.
Map tech to your constraints
Match each method to: existing reader hardware, throughput (people/minute), offline needs, budget, and support burden. Example: high-traffic turnstiles often demand NFC speed; temporary event entrances may tolerate QR.
Pick a primary method and a deliberate fallback
A practical pattern is NFC primary + QR fallback. NFC handles speed; QR covers older phones, broken NFC, or sites without NFC readers.
Plan the “bad day” scenarios
Document exactly what happens when:
Phone is locked: can the pass be presented from the lock screen (Wallet), or must users unlock the app?
No network: is the credential verifiable offline (signed token, cached entitlement), and for how long?
Low battery / dead phone: do you offer a temporary printed QR, on-site override, or a backup physical card?
These decisions shape reader integration, security posture, and the user support playbook later.
Decide: In-App Passes vs. Apple Wallet and Google Wallet
Choosing where the credential “lives” is an early decision because it affects reader integration, user experience, and security constraints.
Option A: In-app passes (inside your app)
An in-app pass is rendered and managed by your app. This gives you maximum control over UI, authentication, analytics, and custom workflows.
Pros: full branding and custom screens, flexible auth (biometrics, step-up prompts), richer context (site maps, instructions), and easier support for multiple credential types.
Cons: users must open your app (or use a widget/quick action you build), OS-level lock-screen access is limited, and offline behavior is fully your responsibility.
Option B: Apple Wallet / Google Wallet passes
Wallet passes (for example, PKPass on iOS) are familiar and designed for quick presentation.
Pros: high trust and discoverability, lock-screen/quick access, strong OS handling for presentation, and fast “show the code” behavior.
Cons: tighter platform constraints (supported barcode/NFC formats, limited custom UI), updates follow Wallet rules, and you may need Apple/Google-specific setup (certificates, issuer configuration, and sometimes review/approval). Deep telemetry is also harder.
A practical decision rule
Use Wallet when speed, familiarity, and “always available” presentation matters (visitors, events, simple door/barcode workflows). Use in-app when you need stronger identity checks, richer workflows, or complex credential logic (multi-site staff access, approvals, role-based access).
Multiple pass types, templates, and branding
If you serve multiple organizations, plan for templates per org: logos, colors, instructions, and different data fields. Some teams ship both: a Wallet pass for quick entry plus an in-app credential for administration and support.
Pass lifecycle you must support
Regardless of container, define lifecycle actions you can trigger:
Re-issue (new device, lost phone, suspected compromise)
Keep these operations consistent across in-app and Wallet so operations teams can manage access without manual workarounds.
Design the Data Model and Pass Lifecycle
A clean data model makes the rest of your system predictable: issuing a pass, validating it at a reader, revoking it, and investigating incidents should all be straightforward queries—not guesswork.
Core entities to model
Start with a small set of “first-class” objects and grow only when needed:
User: the person who should gain access.
Organization / Site: who owns the system (and where access applies).
Pass: the user-facing “card” (what the app or wallet shows).
Credential: the token presented to a reader (NFC credential, QR payload, etc.). One pass can have multiple credentials over time.
Device: the phone instance that holds or displays the credential.
Reader / Door: the physical endpoint (reader ID, door ID, location).
Access policy: rules that connect users/groups to doors and schedules.
This separation helps when a user changes phones: the pass can remain conceptually the same while credentials rotate and devices change.
Pass states and lifecycle
Define explicit states and allow only deliberate transitions:
pending (invited/enrolling)
active (usable)
suspended (temporarily blocked)
expired (time-bound end reached)
revoked (permanently invalid)
Example transitions: pending → active after verification; active → suspended for policy violations; active → revoked when employment ends; suspended → active after admin restore.
Identifiers and mapping to readers
Plan unique IDs at two levels:
A stable pass_id (internal) for lifecycle and support.
One or more credential_id / token_id values that readers can validate.
Decide how readers map tokens to access rules: direct lookup (token → user → policy) or token → policy group (faster at the edge). Keep identifiers non-guessable (random, not sequential).
Audit logs: what to record and where
Treat audit logs as append-only and separate from “current state” tables. At minimum record:
These events become your source of truth for troubleshooting, compliance, and abuse detection.
Build the User Enrollment and Pass Issuance Flow
A digital pass project succeeds or fails on the “first 5 minutes” experience: how quickly a real person can enroll, receive a credential, and understand what to do next.
Enrollment paths (pick 1–2 primary)
Most teams support a mix of these steps, depending on security and deployment size:
Invite link: an admin (or HR system) generates a time-limited link. The user opens it on their phone and lands directly in the correct flow.
Email/SMS verification: send a one-time code to confirm the phone number or email tied to the identity record.
SSO: for employees, use SAML/OIDC so the pass is issued only after corporate sign-in.
Admin approval: for higher-security sites, put the request in a review queue (with reason codes, timestamps, and an audit trail).
A practical pattern is: invite link → verify email/SMS → (optional) SSO → issue pass.
How the pass is added (and how you guide users)
Design issuance so users don’t have to “figure it out”:
In-app pass: the credential lives inside your app; you control updates and UI. Good when you need custom authentication, offline rules, or special reader behaviors.
Wallet add: provide an “Add to Apple Wallet” / “Add to Google Wallet” button after verification. Also support deep links that open the wallet-add screen from an invite.
QR invitation fallback: on-site, allow a receptionist kiosk to display a QR that opens the enrollment link (useful when the user can’t find the email).
Keep copy extremely clear: what the pass is for, where it will appear (app vs. wallet), and what to do at the door.
Device changes and re-issuance rules
Plan this early to avoid support tickets:
New phone: provide a self-serve re-enrollment flow that re-verifies identity and re-issues the pass.
Multiple devices: decide whether to allow it. If allowed, cap the number and show active devices in settings.
Lost device: enable instant remote revoke, then allow re-issue after re-verification.
User messages for real-world failures
Write friendly, specific messages for:
Denied access (and next step: “Contact security” vs. “Try again after refresh”)
Expired pass (include expiry date and renewal action)
Connectivity issues (explain what still works offline, and how to recover when online)
Good issuance is not just “create a pass”—it’s a complete, understandable journey with predictable recovery paths.
Authentication and Authorization for Users and Admins
Digital passes are only as trustworthy as the identity and permissions behind them. Treat authentication (who you are) and authorization (what you can do) as first-class product features, not just plumbing.
Choosing an authentication approach
Pick the login method that matches your audience and risk level:
Passwordless “magic link”: great for low-friction enrollment, but requires reliable email delivery.
SSO / enterprise identity (SAML/OIDC): best for employees, contractors, and campuses; ties access to existing HR/IT policies.
If you support multiple tenants (different organizations), decide early whether a user can belong to more than one tenant and how they switch contexts.
Authorization: roles, scopes, and auditability
Define roles in plain language (for example, Pass Holder, Front Desk, Security Admin, Auditor), then map them to permissions:
Who can issue, reissue, revoke, or suspend passes
Who can view access logs and export reports
Who can change facility rules (door groups, schedules)
Keep authorization checks on the server (not just in the UI), and log every sensitive action with who, what, when, where (IP/device), plus a reason field for manual admin actions.
Sessions, device trust, and user convenience
Use short-lived access tokens with refresh tokens, and support secure re-entry via biometrics (Face ID/Touch ID) for showing the pass.
For higher-security deployments, add device binding so a credential is valid only on the enrolled device(s). This also makes it harder for a copied token to be used elsewhere.
Admin safeguards that reduce mistakes and abuse
Admin tools need extra guardrails:
Approval workflows for bulk issuance or privileged passes
Rate limits on issuance/reissue endpoints
Alerts for unusual patterns (for example, many passes issued to the same email domain, spikes outside business hours)
Document these policies in an internal runbook and link it from your admin UI (for example, /docs/admin-security) so operations stays consistent.
Security Model: Prevent Cloning, Screenshots, and Replay
Security for digital passes is less about “hiding the QR code” and more about deciding what a reader is allowed to trust. The right model depends on connectivity, reader capabilities, and how quickly you need to revoke access.
What does the reader validate?
You typically have three patterns:
Signed payload (offline validation): the QR/NFC carries a payload signed by your system. Readers verify the signature locally, so doors work offline. This is fast, but revocation is only as quick as reader updates.
Server check (online validation): the reader sends the scanned token to your backend to approve/deny in real time. Revocation is immediate, but you’re dependent on network uptime and latency.
Hybrid: readers verify a signature first (to block obvious fakes), then optionally call the server for high-risk areas or when connectivity is available.
QR codes: reduce screenshot and replay risk
Static QR codes are easy to share and screenshot. Prefer rotating or time-limited codes:
Use a short-lived token (for example, valid for 15–60 seconds).
Bind it to a device/session when possible (so a forwarded screenshot won’t validate elsewhere).
Include anti-replay data (timestamp + nonce) and have the backend reject already-used tokens where “one-time entry” is required.
If you must support offline QR validation, make the QR time-boxed and signed, and accept that true real-time revocation won’t be possible without syncing readers.
NFC credentials: protect keys on-device
For NFC, plan where secrets live and how they’re used:
Store credential keys in hardware-backed secure storage (Secure Enclave/Keystore where available).
Avoid exposing long-lived identifiers over NFC; use challenge-response or derived session keys if the reader supports it.
Assume rooted/jailbroken devices exist; rely on hardware-backed keys and server-side risk rules rather than app obfuscation.
Revocation speed: define the operational requirement
Decide upfront how quickly a revoked pass must stop working (seconds, minutes, hours). That requirement drives architecture:
Seconds: online checks (or readers with constant connectivity) are usually required.
Minutes: frequent reader sync + short-lived tokens can work.
Hours: periodic updates may be acceptable for low-risk areas.
Write this down as a security and operations SLO because it affects reader configuration, backend availability, and incident response.
Integrate with Door Readers and Access Control Systems
This is where your digital passes meet the real world: turnstiles, door controllers, elevator readers, and front-desk scanners. Integration choices here affect reliability, speed, and what happens when the network is down.
Choose the reader validation path
Common integration paths include:
Reader → your API (cloud validation): the reader (or its controller) calls your validation endpoint for each tap/scan. Flexible, but depends on network quality and requires careful rate limiting.
Reader → existing access control system (ACS): your app issues a credential the ACS understands, and the ACS makes the allow/deny decision. Less custom logic at doors, but can limit what data you can encode.
Reader → local gateway (edge validation): readers talk to an on-site service that validates credentials locally and syncs with your backend. Improves resilience and keeps latency predictable.
Set response-time and offline behavior targets
Define targets early (for example, “unlock decision in under 300–500 ms”). Also document what “offline” means for each site:
If the network drops, do you fail closed (deny all) or fail open for specific doors?
Do you support cached allowlists at the gateway/controller with short expirations?
How will you log events and sync them later without duplicating entries?
Document integration points (don’t skip the messy details)
Write down the systems and data you must align:
Badge provisioning: who creates a person record and when (HR system, visitor system, admin portal)?
Access groups and schedules: mapping roles to doors, floors, time windows, and holiday rules.
Door and reader inventory: canonical door IDs, locations, reader types (NFC, QR), and controller firmware constraints.
A simple “source of truth” diagram in your internal docs saves weeks later.
Plan monitoring and diagnostics
Treat readers like production infrastructure. Track:
Reader health: last seen timestamp, firmware version, battery/power status (if available).
Failure rates and latency: p95 validation time, timeouts, and retries.
Make these visible in an ops dashboard and route critical issues to on-call. A fast “why was I denied?” workflow reduces support load during rollout.
Backend Architecture: APIs, Signing, and Scalability
A digital pass system lives or dies by its backend: it issues credentials, controls validity, and records what happened—quickly and reliably—when people are standing at a door.
Core APIs (keep them simple and versioned)
Start with a small set of endpoints you can evolve:
POST /v1/passes/issue — create a pass for a user, return an activation link or pass payload
POST /v1/passes/refresh — rotate identifiers / update entitlements, return latest pass data
POST /v1/passes/validate — verify a QR/NFC token presented at a reader (online readers)
POST /v1/passes/revoke — immediately invalidate a pass (lost phone, terminated access)
POST /v1/events — log entry attempts and outcomes (accepted/denied/error)
Even if some validations happen on-device or on the reader, keep a server-side validation API for audit, remote revocation, and “break glass” operations.
Signing and key management (and how to rotate safely)
If you support Apple Wallet (PKPass) or other signed payloads, treat signing keys like production secrets:
Store private keys in a managed KMS/HSM; never on app servers or in CI logs.
Rotate keys on a schedule and after incidents; support multiple active public keys so old passes can keep working during a transition.
Audit every signing operation (who/what issued, for whom, when, and with which key version).
A practical pattern is a dedicated “signing service” with a narrow interface (for example, “sign pass payload”), isolated from the rest of your application.
Designing for scale at peak entry times
Entry spikes are predictable (9:00 AM, event start). Plan for bursty reads:
Use caching for revocation lists and entitlement lookups, add retries with idempotency keys for issuance, and queue non-critical work (analytics, notifications) so validation stays fast. If readers go online, keep validation latency low by avoiding chatty dependencies.
Privacy controls and log retention
Minimize stored personal data: prefer internal user IDs over names/emails in pass records and events. Define retention up front (for example, keep entry logs 30–90 days unless required longer), and separate operational logs from security/audit logs with stricter access controls.
Building faster (without locking in your architecture)
If you’re iterating quickly—admin portal, issuance APIs, and an initial mobile experience—tools like Koder.ai can help you prototype and ship an end-to-end pass system via chat while still keeping an engineering-grade stack under the hood (React for web, Go + PostgreSQL for backend, Flutter for mobile). It’s especially useful for creating a working pilot (including deployment/hosting, custom domains, and snapshots with rollback) and then exporting the source code when you’re ready to integrate with a specific ACS or on-prem gateway.
Mobile App UX: Setup, Display, and Accessibility
A digital pass succeeds or fails on the screen people see at the door. Optimize for three moments: first-time setup, “show my pass now,” and “something went wrong—help me recover fast.”
Choose the app approach
Native (iOS/Android): best for NFC experiences, Wallet integration, and polished system behaviors.
Cross-platform (Flutter/React Native): great for shared UI and faster iteration, but validate NFC, background behaviors, and Wallet handoffs early.
Web-based companion: works for QR-only programs and quick pilots, but you’ll rely more on camera permissions and connectivity.
If you support Apple Wallet / Google Wallet, make it clear whether the app is required after provisioning. Many users prefer “add to wallet and forget.”
Pass display that works under pressure
Design the “present pass” screen like a boarding pass: immediate, bright, and hard to misread.
QR rendering: use a high-contrast code with generous quiet zones, lock orientation if needed, and include a “maximize brightness” prompt.
NFC tap UI: show a simple “Hold near reader” state, an animated hint for positioning, and a clear success confirmation.
Wallet deep links: provide a one-tap “Open in Wallet” / “Open in Google Wallet” action (route users directly rather than making them hunt through apps).
Avoid burying the pass behind menus. A persistent home-screen card or a single primary button reduces door delays.
Accessibility and clarity
Support Large Text, Dynamic Type, screen reader labels (“Access pass QR code”), and high-contrast themes. Treat error states as part of the UX: camera blocked, NFC off, pass expired, or reader not responding. Each should include a plain-language fix (“Enable Camera in Settings”) and a fallback action.
Edge cases to design for
Time zones and device clock drift can make time-based passes look “wrong,” so display times with the venue’s time zone and add a subtle “Last synced” indicator.
Also plan for: airplane mode, flaky reception in lobbies, revoked permissions (camera/NFC), and low-battery accessibility modes. A small “Troubleshoot” link to /help/mobile-pass can prevent support queues at peak entry times.
Testing Strategy: Devices, Readers, Offline, and Abuse Cases
Testing a mobile access card app is less about “does it open” and more about “does it open every time, under pressure.” Treat testing as a product requirement, not a final checklist.
Build a practical testing matrix
Start with a matrix that reflects what users actually carry and what your doors actually use:
Devices: a mix of older and newer iPhones/Android phones, different screen sizes, and low-end cameras for QR code pass scanning.
OS versions: include at least the current and previous major iOS/Android versions.
Capabilities: NFC availability (and placement), camera autofocus speed, brightness, and battery saver modes.
Reader models: each door reader firmware/version you support, including turnstiles and handheld scanners.
Include both in-app credentials and wallet flows (Apple Wallet pass / Google Wallet pass), because PKPass behavior and system UI timing can differ from your app.
Rehearse real-world entry conditions
Lab-perfect scans won’t match real entry lines. Run “rush tests” where 20–50 people present passes quickly, back-to-back, with:
Poor lighting and glare (outdoor sun, dim lobby)
Spotty connectivity (Wi‑Fi drops, weak LTE)
Offline mode (airplane mode + device reboot) to confirm cached credentials and UX guidance
Measure median time-to-entry, failure rate, and recovery time (what the user does next).
Validate abuse and failure scenarios
Actively test:
Replay attempts (reusing the same QR within its validity window)
Screenshot use and screen-recording edge cases
Revoked pass attempts (immediate denial after server-side revocation)
Rate limits and lockouts for repeated failures
Stage like production
Maintain a staging environment with test readers and synthetic traffic that simulates peak events. Verify pass issuance, updates, and revocations at load, and ensure logging lets you trace “tap/scan → decision → door result” end-to-end.
Launch, Rollout, and Ongoing Operations
A successful launch is less about a big release and more about predictable entry at every door, every day. Plan for a controlled rollout, clear support paths, and metrics that tell you where friction is hiding.
Migrate from physical cards without breaking access
Most organizations do best with a phased rollout:
Pilot group first (security team, facilities, a single office/floor) to validate readers, onboarding, and edge cases.
Dual-credential period where employees can use either the physical card or the digital pass. Set a target end date, but keep exceptions for contractors or special devices.
Training and comms: short “how to enter” instructions, where to tap/scan, what to do if the phone dies, and how to request help.
Support playbooks you’ll actually use
Create simple, repeatable workflows for your help desk and admins:
Lost phone: revoke the credential immediately; re-issue to a new device after identity verification.
Denied access: check reader logs, pass status (active/expired), user permissions, and time schedules; provide a temporary fallback if needed.
Device switch/upgrade: self-serve re-enrollment when possible, with rate limits and admin override.
Re-issue: define when to rotate identifiers vs. re-activate the same pass (important for fraud prevention and audit trails).
Keep these playbooks in one place and link them from your admin console and internal docs.
Instrumentation and operational metrics
Add analytics that reflect real entry performance, not just installs:
Reader and backend errors (timeouts, offline, signature failures)
Use these metrics to prioritize reader tuning and user education.
Rollout checklist (publish and reuse)
Readers verified (NFC/QR) and fallback tested
Admin roles and escalation contacts defined
Support scripts ready (lost phone, denied access, re-issue)
Analytics dashboard live with weekly review cadence
Clear user comms and a way to request help (/contact)
Commercial and scaling plan confirmed (/pricing)
FAQ
What exactly counts as a “digital pass” in an access-card app?
A digital pass is the user-facing “card” a person presents to enter or verify entitlement (badge, member ID, ticket, visitor pass). Under the hood, it’s backed by one or more credentials (QR payloads, NFC tokens) that readers validate, and a lifecycle (issue, update, suspend, revoke, re-issue) you can manage operationally.
How do I define the use case and success metrics before choosing QR/NFC or Wallet/in-app?
Start by writing the end-to-end workflow (request → approval → issuance → entry → audit), then pick measurable metrics:
Activation rate (invited users who successfully add/enable)
First-try success rate at the door (scan/tap works on the first attempt)
Time-to-issue (request/approval to usable credential)
Support ticket volume and top reasons
These metrics keep “it works” grounded in real operations.
When should I use QR codes vs NFC for digital passes?
Use QR when you need broad compatibility and low hardware cost (camera scanners, visual checks), and can tolerate slower throughput. Use NFC when you need fast, familiar “tap-to-enter” experiences and have compatible readers.
A common, practical setup is:
NFC primary for speed
QR fallback for older phones, broken NFC, or non-NFC sites
How should I think about offline access and revocation for doors and scanners?
Decide (and document) three things:
Offline validity window (minutes/hours/days)
Revocation behavior while offline (deny only after sync, or time-boxed acceptance)
Fail open vs fail closed policy by door/site
If you need near-immediate revocation, you’ll typically require online validation or very frequent reader/gateway syncs.
Should my pass live in Apple/Google Wallet or inside my app?
Choose Wallet when fast presentation and lock-screen availability matter (visitors, events, simple badge flows). Choose in-app when you need richer workflows and stronger identity controls (approvals, multi-site access, step-up auth).
Many teams ship both:
Wallet pass for quick entry
In-app credential/admin view for support, updates, and troubleshooting
What data model do I need for passes, credentials, devices, and doors?
Model at least these entities:
User, Organization/Site
Pass (what the user sees)
Credential (the token readers validate)
Device (where the credential is stored/displayed)
What pass lifecycle states should I support (issue, suspend, revoke, re-issue)?
Make states explicit and transitions deliberate:
pending → user is enrolling
active → usable
suspended → temporarily blocked
expired → time window ended
revoked → permanently invalid
What’s the recommended enrollment and issuance flow for a mobile pass?
Build for the “first 5 minutes”:
Use invite links that deep-link into enrollment
Verify identity via OTP (email/SMS) and/or SSO for employees
Offer a clear Add to Wallet or “Pass ready” screen with instructions
Provide a or on-site fallback when users can’t find emails
How do I prevent QR screenshots, cloning, and replay attacks?
Avoid static codes. Prefer:
Rotating, short-lived QR tokens (e.g., 15–60 seconds)
If you must validate offline, accept that revocation won’t be real-time and compensate with short validity windows and periodic reader updates.
What are the main ways to integrate with door readers and access control systems?
Pick one of three patterns:
Reader → your API (cloud validation): flexible, immediate revocation; network-dependent
Reader → existing ACS: leverages current access control decisions; may limit token formats/data
Reader → local gateway (edge validation): predictable latency and better offline resilience
Set targets (e.g., 300–500 ms decision time), define offline behavior, and monitor p95 latency, failure rates, and denial reasons by door/reader model.
Reader/Door and Access policy
Separating pass from credential makes device changes and credential rotation straightforward without “losing” the identity or history.
Define who can trigger transitions (user vs admin vs automated policy) and log every change with actor, timestamp, and reason.
kiosk QR
Also plan self-serve re-enrollment for new phones and instant remote revoke for lost devices.
How to Build a Mobile App for Digital Passes and Access Cards | Koder.ai
