I Migrated Our API From REST to GraphQL. Here’s What Nobody Warned Me About.

We spent 3 months migrating our main API. The benefits are real. So are the headaches nobody talks about.

Why We Switched

REST endpoints were multiplying like rabbits. Mobile needed different shapes than web. The versioning nightmare was real.

What Actually Happened

Week 1-4: Schema design. This is where most teams underestimate. A bad schema haunts you forever.

Week 5-8: Resolver implementation. N+1 query problems hit hard. We had to implement DataLoader everywhere.

Week 9-12: Client migration. Web first, then mobile. Both had different caching strategies.

The Real Benefits

Query-level permissions. No more endpoint explosion. Type safety across the stack. The mobile team stopped asking us for new endpoints.

What Nobody Warns You About

Error handling is brutal. A partial success in GraphQL means you’re sending 200 with partial errors in the response body. Clients don’t expect that.

Caching is harder. HTTP caching doesn’t apply. You need application-level caching.

Monitoring is different. Each query is unique. Traditional request metrics don’t tell you much.

Would I Do It Again?

For our use case, yes. For a simple CRUD API? No.

What’s your API architecture?

Two people who have never met, talking over a line that everyone can hear, can still agree on a secret number that no eavesdropper can recover. When Whitfield Diffie and Martin Hellman published this idea in 1976, it sounded like a contradiction. It is now the quiet foundation of nearly every secure connection you make.

Before 1976, encryption had a chicken-and-egg problem. To send an encrypted message you needed a shared key, but to share a key securely you needed an already-secure channel — which is the very thing you were trying to build. Spies exchanged codebooks in person; banks couriered keys in locked briefcases. The internet had no such luxury.

Diffie-Hellman key exchange broke the loop. It lets two parties derive a shared secret over a completely public channel, such that an attacker recording every byte of the conversation still cannot compute the secret. It does not encrypt anything by itself — it produces the key that something else will use to encrypt.

The Paint-Mixing Intuition

The classic analogy is mixing paint. Suppose Alice and Bob want a shared secret color, and everyone can watch the cans being passed around.

• They publicly agree on a common starting color — say, yellow. Everyone knows it.
• Alice privately picks a secret color and mixes it into the yellow. Bob does the same with his own secret. Each sends the resulting mixture to the other.
• Alice takes Bob’s mixture and adds her secret color again. Bob takes Alice’s mixture and adds his. Both arrive at the same final color — yellow plus Alice’s secret plus Bob’s secret.

An eavesdropper saw the yellow base and both mixtures fly by, but separating a mixed paint back into its components is hard. They cannot reconstruct the final blend without one of the private colors. That irreversibility — easy to mix, hard to un-mix — is the whole trick.

The Real Mathematics

The cryptographic version replaces paint with modular exponentiation. Both parties agree publicly on a large prime p and a base g. Then:

1. Alice picks a secret integer a and sends A = g^a mod p.
2. Bob picks a secret integer b and sends B = g^b mod p.
3. Alice computes B^a mod p. Bob computes A^b mod p.

Both results equal g^(ab) mod p — the shared secret. The eavesdropper knows p, g, A, and B, but to find g^(ab) they would need to recover a or b from A or B. That is the discrete logarithm problem: trivial to compute g^a, infeasible to reverse for large primes.

The asymmetry that protects you: Modular exponentiation is a one-way street. With a 3072-bit prime, computing g^a takes milliseconds, but the fastest known algorithm to invert it would take longer than the age of the universe on classical hardware. The security rests entirely on that gap.

The Achilles’ Heel: Authentication

Plain Diffie-Hellman has a fatal weakness if used alone: it provides no authentication. Because the parties never verify each other’s identity, an active attacker sitting in the middle can run two separate exchanges — one with Alice pretending to be Bob, one with Bob pretending to be Alice — and relay messages between them. This is the man-in-the-middle attack, and it defeats the secrecy entirely.

Diffie-Hellman guarantees that you share a secret with someone. It says nothing about who. Establishing who requires a separate authentication layer — certificates, signatures, or a verified fingerprint.

In practice this is solved by signing the exchanged values with a previously trusted key. In TLS, the server signs its Diffie-Hellman parameters with the private key tied to its certificate, which your browser validates against a chain of certificate authorities. In messaging apps, identity keys and out-of-band fingerprint verification serve the same role.

Ephemeral Diffie-Hellman and Forward Secrecy

The most important modern refinement is ephemeral Diffie-Hellman (DHE, or ECDHE in its elliptic-curve form). Instead of reusing a long-lived secret, the parties generate fresh, random a and b values for every session and discard them afterward.

This delivers forward secrecy: even if an attacker later steals a server’s long-term private key, they cannot decrypt past recorded sessions, because the per-session secrets no longer exist anywhere. Each conversation is sealed in its own moment. This single property is why TLS 1.3 mandates ephemeral key exchange and removed the older static-RSA handshake entirely.

Finite Fields vs. Elliptic Curves

The original Diffie-Hellman works in a finite field of integers modulo a prime. The modern variant performs the same dance using the point arithmetic of elliptic curves — ECDH — which achieves equivalent security with far smaller keys.

X25519 — ECDH over Curve25519 — is now the workhorse of secure connections, used in TLS 1.3, SSH, WireGuard, and the handshake of modern messengers. When you read that an app uses “X25519 for key agreement,” that is ephemeral elliptic-curve Diffie-Hellman.

The Quantum Horizon

Like all discrete-logarithm and factoring schemes, Diffie-Hellman is vulnerable to a sufficiently large quantum computer running Shor’s algorithm. None exists yet, but the “harvest now, decrypt later” concern is real: traffic recorded today could be broken in the future. The response is hybrid key exchange — running a classical X25519 exchange alongside a post-quantum algorithm and combining both outputs, so an attacker must break both to recover the key.

Why It Still Matters

Diffie-Hellman is half a century old and more relevant than ever. Every HTTPS page load, every SSH session, every encrypted message handshake begins with some descendant of that 1976 idea: two parties building a shared secret out in the open, protected only by a math problem that is easy to walk forward and brutally hard to walk back.

At Haven, ephemeral key agreement underpins the encrypted transport beneath our app, and the same family of primitives feeds the group key management in the MLS protocol. Understanding the handshake is the clearest way to see what your encryption actually protects — and what it leaves to the authentication layer above it.

Originally published at havenmessenger.com

Thomas Habets lleva treinta años escribiendo C y C++ casi a diario. Trabaja en Google, lee propuestas del comité ISO, escucha podcasts del lenguaje y disfruta del oficio. Su conclusión publicada esta semana en su blog personal es contundente: nadie puede escribir código C correcto. Y no lo dice contra los principiantes — lo dice contra sí mismo.

El ensayo recorre los rincones del comportamiento indefinido que la mayoría de desarrolladores ignora y lo conecta con la migración masiva de infraestructura crítica hacia Rust que vimos durante 2026. La tesis es directa: el entorno de 1972 ya no es el entorno de hoy.

TL;DR

• Thomas Habets, ingeniero con 30 años en C/C++, sostiene que nadie escribe código no trivial libre de comportamiento indefinido.- El UB no aparece solo con optimizaciones agresivas: significa que el compilador asume que tu código nunca lo invoca, en ningún backend.- Crear un puntero mal alineado ya es UB en C23 §6.3.2.3 — no hace falta dereferenciarlo, el cast solo basta.- isxdigit() recibe un int; pasarle un char con signo negativo es UB. La mayoría del código C en producción no castea a unsigned char.- El desbordamiento de enteros con signo sigue siendo UB en 2026, aunque todos los CPU reales usan complemento a dos.- Microsoft reportó que el 70% de los CVE críticos en Windows entre 2006 y 2018 fueron bugs de memoria prevenibles en lenguajes safe.- Bun, Astral, Cloudflare y módulos del kernel de Linux migraron infraestructura crítica a Rust en los últimos 12 meses.

Qué pasó

Habets publicó en blog.habets.se un ensayo titulado Everything in C is undefined behavior. El texto sostiene que todo programa no trivial escrito en C o C++ contiene comportamiento indefinido (UB, por undefined behavior), y que la industria sigue tropezando con los mismos errores década tras década.

El argumento en sí mismo no es nuevo. Lo distinto es de quién viene y cuándo llega. Habets no es un converso de Rust evangelizando contra el lenguaje viejo — es un practicante veterano de C++ que admite que no puede dominarlo y que argumenta, con casos concretos, que nadie puede. La pieza aterriza además en un momento particular: en los últimos doce meses, la infraestructura más cargada del internet hispano y global — el runtime de Bun, las herramientas Python de Astral, el edge de Cloudflare, módulos críticos del kernel de Linux — migró parcial o totalmente a Rust. Habets conecta esta migración con la imposibilidad práctica de escribir C seguro a escala.
El compilador asume que tu código nunca invoca UB, en cualquier backend.

Contexto e historia

El comportamiento indefinido es una categoría del estándar C que cubre situaciones donde el lenguaje no especifica qué debe ocurrir. La especificación C23 lista decenas de casos: doble free, uso después de liberación, acceso fuera de los límites de un objeto, lectura de memoria sin inicializar, división por cero con enteros, desbordamiento de enteros con signo, modificación de cadenas literales, y un largo etcétera.

La intuición común entre programadores intermedios es que el UB solo aparece cuando se activa la optimización del compilador. Como si el compilador, al detectar UB, dijera deliberadamente AHA, puedo hacer lo que quiera aquí — y al desactivar las optimizaciones, ese impulso desapareciera. Habets enfatiza que esta intuición es incorrecta.

UB no significa que el compilador aproveche tu descuido. UB significa que el compilador puede asumir que tu código nunca invoca UB. La intención que es obvia para un humano leyendo el código no tiene siquiera una manera de ser expresada entre las fases del compilador o entre módulos. El compilador, y el hardware abajo, juegan un teléfono descompuesto con tu intención: puede que termine haciendo lo que querías, pero no hay garantías para hoy ni para versiones futuras.

⚠️ Ojo: el compilador no tiene que implementar casos especiales en su generación de código para situaciones que “no pueden pasar”. Si tu código las dispara, el binario resultante puede tener cualquier comportamiento — incluso uno que pase tests hoy y falle en producción cuando se actualice GCC o Clang.

Casos sutiles que pocos conocen

Habets dedica buena parte del ensayo a casos donde el UB es invisible para un lector experimentado. Tres ejemplos resumen el argumento.

Acceso a un objeto mal alineado

Considerá esta función trivial:

int foo(const int* p) {
  return *p;
}

Si esta función se llama con un puntero no alineado correctamente — probablemente significando una dirección múltiplo de sizeof(int), aunque la definición exacta depende de la implementación — es UB según C23 §6.3.2.3.

En Linux Alpha, en algunos casos esto atrapaba al kernel, que emulaba en software lo que querías hacer. En otros casos crasheaba con SIGBUS. En SPARC, SIGBUS directo. En x86 y amd64 es probable que funcione, e incluso podría ser una lectura atómica — x86 es famosamente permisivo con la coherencia de caché. ¿Qué pasa en ARM, RISC-V o futuras arquitecturas? Habets imagina un futuro CPU con registros especiales para punteros enteros que no use los bits bajos, porque tales punteros no pueden existir desde la perspectiva del lenguaje.

Y acá viene el giro: el problema no está en dereferenciar el puntero. Está en crearlo. Este código ya es UB antes incluso de pasar por foo():

bool parse_packet(const uint8_t* bytes) {
  const int* magic_intp = (const int*)bytes; // UB aquí
  int magic_raw = foo(magic_intp);
  int magic = ntohl(magic_raw);
  // ...
}

El cast es el problema, no la función foo(). Es perfectamente válido para el compilador asignar significado específico — tags de garbage collection, bits de seguridad, identificadores de cache line — a los bits bajos de un int*. Si lo asume y vos pasaste bits arbitrarios, tu programa entró en territorio indefinido sin que ninguna línea de código se vea sospechosa al ojo humano.

isxdigit() con char con signo

La función estándar isxdigit() recibe un int, no un char. Acepta valores de unsigned char y el valor especial EOF. Si pasás un char con signo cuyo valor sea negativo — algo perfectamente posible cuando leés bytes de un archivo UTF-8, de la red o de cualquier fuente binaria — el resultado es UB.

bool bar(char ch) {
  return isxdigit(ch); // UB si ch es negativo
}

La forma correcta requiere casteo explícito a unsigned char antes de pasar el valor:

bool bar(char ch) {
  return isxdigit((unsigned char)ch);
}

¿Cuántas líneas de código C activo en producción en LATAM cumplen esta regla? Probablemente menos del 5%. Y este es uno de los UB más documentados del lenguaje: aparece en la página de cppreference desde hace dos décadas. Si los profesionales que escriben C cada día no lo recuerdan, ¿qué esperanza tienen los demás?

Desbordamiento de enteros con signo

En 2026, todos los procesadores que importan usan representación de complemento a dos. Sumar INT_MAX + 1 en una arquitectura real produce INT_MIN. Pero el estándar de C sigue declarando este caso como UB. El compilador puede asumir que un programador nunca dispara desbordamiento con signo, y optimizar bucles bajo esa premisa.

El ejemplo clásico es un loop con condición i <= INT_MAX: si la variable i es int, el compilador puede asumir que la condición eventualmente se vuelve falsa, porque desbordar es UB y “no puede pasar”. Si vos escribiste el código contando con el wraparound para salir del loop, podés terminar con un loop infinito en release y un loop finito en debug. Y nada en el código fuente revela la diferencia.
El compilador asume que tu código nunca invoca UB y optimiza bajo esa premisa.

El flujo del compilador con UB

Para visualizar por qué desactivar optimizaciones no salva del problema, sirve mirar el flujo conceptual:

graph LR
  A["Codigo C con UB latente"] --> B["Frontend del compilador"]
  B --> C["IR asume codigo valido"]
  C --> D["Optimizador elimina ramas imposibles"]
  C --> E["Backend genera asm"]
  D --> F["Binario impredecible"]
  E --> F

El IR (representación intermedia) carga la asunción de que el código no invoca UB desde la primera traducción. No es algo que se active con -O2. Es algo que está horneado en la semántica del lenguaje desde C89.

Datos y cifras del problema

El ensayo de Habets no sale del vacío. Aterriza en una conversación más amplia con datos concretos:

• Microsoft reportó en 2019 que el 70% de los CVE críticos parcheados en sus productos entre 2006 y 2018 fueron bugs de memoria — todos prevenibles en un lenguaje memory-safe.- Google publicó cifras similares para Chromium: aproximadamente el 70% de las vulnerabilidades de severidad alta eran bugs de memoria nativa.- Android reportó que las introducciones nuevas de Rust en su base de código tuvieron cero vulnerabilidades de memoria en 2024, mientras que el código C/C++ equivalente habría producido decenas según las estadísticas históricas.- Bun exploró un puerto de Zig a Rust usando agentes de Claude Code en 2026.- Astral, la empresa detrás de uv y ruff, escribió toda su pila de herramientas Python en Rust.- Cloudflare reescribió componentes críticos de su edge en Rust.- El kernel de Linux aceptó Rust como segundo lenguaje oficial en 2024 y desde entonces aceptó drivers y módulos críticos.

Estas decisiones no son moda. Son una respuesta racional al argumento de Habets: si nadie puede escribir C libre de UB, y los compiladores cada año son más agresivos asumiendo que el código no invoca UB, entonces la única forma de tener garantías reales es cambiar de herramienta.

Impacto y análisis

La pieza ya generó respuestas en Hacker News, Lobsters y en el subreddit r/cpp. Los críticos hacen tres puntos válidos.

Primero, existen herramientas de análisis estático y dinámico. UBSan (UndefinedBehaviorSanitizer), AddressSanitizer, ThreadSanitizer y herramientas comerciales como Coverity o PVS-Studio reducen el costo de mantener C seguro. Habets responde que estas herramientas son cinta adhesiva sobre un problema de diseño: detectan UB cuando se ejecuta, pero no garantizan su ausencia. Ningún proyecto C grande logra zero-UB verificado en producción.

Segundo, C tiene un ecosistema y un perfil de rendimiento difícil de replicar. Reescribir todo en Rust es caro y arriesgado. Habets coincide y aclara que no propone tirar C a la basura — propone reconocer la realidad y dejar de escribir código nuevo en C cuando hay alternativa razonable. La diferencia entre mantener libcurl en C y empezar un parser nuevo en C es enorme.

💭 Clave: el argumento no es contra C como artefacto histórico. Es contra C como elección por defecto para código nuevo en 2026, cuando existen Rust, Zig y otras alternativas con sistemas de tipos modernos.

Tercero, el comité C avanza. C23 fijó varios UB históricos: la representación de complemento a dos para enteros con signo ya es obligatoria, por ejemplo, aunque el desbordamiento sigue siendo UB. C2y y futuros estándares prometen más fixes. Habets reconoce el progreso pero apunta que el ritmo es de décadas, no de releases. Para un proyecto greenfield iniciado hoy, esperar a que el comité elimine el UB no es un plan viable.

Qué hacer hoy si trabajás con C

Para desarrolladores en LATAM trabajando con C/C++ activo, el ensayo sugiere acciones concretas que se pueden implementar esta semana:

• Compilar siempre con -Wall -Wextra -Wpedantic y al menos un sanitizer activo en CI.- Activar UBSan en tests, no solo ASan. UBSan captura los casos sutiles de cast, alignment y overflow que ASan no ve.- Usar -fno-strict-aliasing y -fwrapv como red de seguridad mientras se migra código heredado. No son una cura, pero reducen la superficie.- Evaluar Rust o Zig para módulos nuevos donde el rendimiento importe pero la corrección sea crítica. Un parser de protocolos, un encoder de media, un componente de red — todos candidatos.- Documentar cada cast de puntero que cruce tipos, porque casi siempre es UB y necesita auditoría manual.- Adoptar std::span y std::string_view en C++20 en lugar de punteros crudos cuando sea posible. Reducen oportunidades de error pero no eliminan UB.

Qué sigue

El debate no se cerrará con un post de blog. C va a seguir existiendo y se va a seguir escribiendo. Linux, glibc, OpenSSL, SQLite, Postgres, Redis, FFmpeg, el kernel de cada sistema operativo serio: todo eso es C o C++ y va a seguir siéndolo por décadas.

Lo que cambia es la dirección del flujo de código nuevo. Cuando una startup de Silicon Valley o de São Paulo elige un lenguaje para su backend en 2026, la decisión rara vez es C++. Cuando Microsoft anuncia que va a portar partes del kernel de Windows a Rust, el mensaje no es para los que mantienen NTFS. Es para los que van a escribir el próximo subsistema.

La industria se mueve y los lenguajes nuevos absorben las lecciones de cuatro décadas. Que un ingeniero de Google con tres décadas de C++ ratifique públicamente esta lección no cambia el rumbo, pero le da peso a una conversación que en LATAM apenas empieza.

📖 Resumen en Telegram: Ver resumen

Preguntas frecuentes

¿Qué es exactamente el comportamiento indefinido en C?

Es una categoría del estándar de C que describe operaciones para las cuales el lenguaje no especifica qué debe ocurrir. El compilador puede asumir que tu código nunca las invoca, y optimizar bajo esa premisa. El resultado puede ser un binario que funciona, uno que crashea o uno que produce resultados arbitrarios — todo es válido según el estándar.

¿Desactivar optimizaciones evita el comportamiento indefinido?

No. UB es una propiedad semántica del lenguaje, no una consecuencia de optimizar. Incluso con -O0, el compilador puede generar código que rompe con UB, especialmente en arquitecturas exóticas o cuando el backend traduce la representación intermedia a assembly.

¿Sirve UBSan para encontrar todos los casos?

UBSan encuentra muchos casos de UB pero no todos, y solo los detecta cuando se ejecutan en runtime con la instrumentación activa. Es una herramienta excelente en CI y en QA, pero no garantiza ausencia de UB en código que no se ejercitó durante los tests.

¿Rust elimina completamente el problema?

Rust elimina los UB de seguridad de memoria en código safe, que es la mayoría del código que escribís. El código marcado unsafe puede tener UB y requiere auditoría manual. La diferencia es que en Rust el código unsafe es una porción pequeña y localizada, mientras que en C todo el código es implícitamente unsafe.

¿Debería reescribir mi proyecto C en Rust?

Probablemente no. Reescribir es caro y arriesgado. Lo que sí tiene sentido es no empezar proyectos nuevos en C cuando hay alternativa razonable, y considerar Rust para módulos nuevos dentro de un proyecto existente. Bun, por ejemplo, mantiene Zig para el core y agrega Rust en módulos nuevos.

¿C23 resolvió los problemas históricos?

Parcialmente. C23 mandató representación de complemento a dos para enteros con signo, agregó atributos de seguridad y limpió casos puntuales. Pero el grueso del UB sigue presente: alignment de punteros, casts entre tipos incompatibles, desbordamiento con signo, accesos fuera de objeto y muchos más.

Referencias

• blog.habets.se — Ensayo original de Thomas Habets sobre UB en C.- cppreference.com — Documentación de comportamiento indefinido en el estándar C.- github.com/google/sanitizers — Repositorio de UBSan, AddressSanitizer y otras herramientas de detección.- open-std.org/jtc1/sc22/wg14 — Comité ISO C y documentos de C23.

📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.

You wouldn’t email your codebase to a stranger. But you might be sending it to an AI tool without realizing it.

I’ve been using AI tools for over a year now — ChatGPT, Claude, Gemini, you name it. I’ve discussed product architecture, reviewed sensitive client requirements, debugged proprietary code. And I realized something uncomfortable:

I have no idea where these conversations go after I close the tab.

Not the company. The infrastructure. The backups. The training data opt-outs. The third-party analytics embedded in the web app. I clicked “I agree” on the terms of service for five different AI platforms and never read any of them.

That’s not a flex. That’s negligence.

The Export-Local Pattern

Here’s what I started doing after the realization hit: export every important conversation and store it locally.

Not for organization. For ownership.

When a conversation contains:

• Code snippets from my projects
• Business strategy discussions
• Client-specific analysis
• Anything I wouldn’t want in a data breach

…I export it immediately. Markdown, PDF, whatever format works. Stored in an encrypted folder on my machine.

The reasoning is simple: once it’s on their servers, I don’t control it. Once it’s on my disk, I do.

The Multi-Platform Problem Makes It Worse

Most people use multiple AI tools. That’s five different privacy policies, five different data retention practices, five different potential breach surfaces. And you can’t even see all your data in one place because each platform locks you into their UI.

The export tool I use is XWX AI Chat Exporter — it works across all 5 major platforms from one extension, which means I have a single workflow for data sovereignty. Export to PDF, Markdown, or JSON, and it all lands on my machine where I control it.

Again, I’m not saying you need this specific tool. I’m saying you need a strategy.

A Simple Privacy Audit

Here’s a 5-minute exercise I recommend:

1. Open your AI tool settings and check “Data Controls” or “Privacy”
2. See if there’s an opt-out for training data usage (most have one, most people don’t use it)
3. Check how long they retain your conversations
4. Export anything sensitive you’ve discussed in the last month
5. Move it to local storage

Do this for each AI tool you use. It takes 25 minutes total and you’ll sleep better.

The Bigger Picture

AI companies aren’t malicious. But they’re businesses with different incentives than yours. Your conversations are valuable data. Their privacy policies are designed to protect their liability, not your interests.

Taking ownership of your AI conversation data isn’t about paranoia. It’s about the same instinct that makes you back up your code, encrypt your passwords, and read contracts before signing.

Your thinking process deserves the same protection as your source code.

Have you ever thought about where your AI conversations go? What’s your approach to AI privacy?

Every morning across Nepal, parents prepare their children for school based on a single piece of information: the time the bus is supposed to arrive. If the bus usually comes at 7:10, the child is dressed by 7:00 and standing at the gate by 7:08. That is the entire system. Most parents have no way to know if the bus is running on time, stuck in Kathmandu traffic, taking a different route, or already left the area.

When the bus is late, parents wait at the gate with their child, sometimes in cold weather, sometimes in rain, often without knowing whether the bus is two minutes away or has skipped the route entirely. A phone call to the school office usually returns the same answer: the office does not know either. The driver is unreachable while driving. Everyone is operating blind, every morning.

This is the gap that modern school bus systems close. Once GPS tracking and a parent app are in place, the question “where is the bus” stops requiring a phone call. Parents see the bus on a live map. They get notified when it is five minutes from their stop. They send the child out at the right moment, not too early, not too late. The change is small in technology but large in daily life.

This guide is for school administrators and transport in-charges who want to make their buses genuinely safer and trackable by parents in real time. We start with practical steps any school can take, then explain how a modern GPS tracking system fits in, what it costs, and what to look for before signing up.

Five things every Nepali school can do this term to improve bus safety

Before discussing technology, here are five operational steps any school can take, often within the same academic term, to make bus transport safer:

1. Assign one transport in-charge with real authority. Not the principal’s secretary doing it as a side task. Someone whose primary job is buses, drivers, routes, and parent communication. Most safety failures trace back to nobody being clearly responsible.
2. Build a written route and stop map. Every route, every stop, every assigned child, every parent contact, kept in one document the office can pull up in 30 seconds. Most schools rely on the driver’s memory, which fails on the day a substitute driver takes over.
3. Set a clear pickup and drop window for each stop. If the bus is supposed to reach a stop between 7:05 and 7:10, parents and drivers both know. Anything outside that window triggers a phone call. This single discipline removes most parent-school conflicts about timing.
4. Train drivers on harsh braking, idling, and turning. Bus drivers in Nepal rarely receive any formal driving review after they are hired. A 30-minute monthly conversation with the transport in-charge, based on real data, changes behaviour fast.
5. Install GPS tracking with a parent-facing app. This is the modern enabler that makes the previous four steps actually work at scale. It also adds emergency response, route history, and audit-ready records that schools increasingly need.

The first four steps are organisational. The fifth is technical, and it is what the rest of this article focuses on, because it is where most schools either save money smartly or waste it badly.

What GPS tracking with parent access actually does

A GPS device is installed inside each bus. It records the bus location every few seconds and sends that data to a server hosted in Nepal. The server feeds three things at once:

• A parent app on Android and iOS where each parent sees only their own child’s bus on a live map
• An institutional dashboard for the school transport in-charge to monitor every bus at once
• An alert engine that sends notifications for stop approach, route deviation, harsh driving, and SOS events

What makes the difference between a basic and a useful system is everything around that core: route management, stop-by-stop ETA, parent notifications, driver behaviour reports, and safety alerts. Without these, a tracker is just a moving dot on a map.

What parents specifically need from the system

Parents do not need a fleet management dashboard. They need three things, fast and reliable:

• Live location on a phone, ideally with a map view that updates in real time
• Notification when the bus is approaching their stop, so the child does not stand outside in cold or heat unnecessarily
• Confirmation that the child boarded and got off, either through RFID cards or a small driver action in the app

A few extras help: a shared route view for both parents, alerts when the bus deviates from its expected path, and a clear historical view for any parent who wants to verify a specific day. NepTrack provides all of these by default on the school bus tracking page.

The features that matter to schools

School administrators need a different set of capabilities:

• Real-time visibility over every bus in the fleet, not just one at a time
• Driver behaviour monitoring for harsh braking, rapid acceleration, and idling, so schools can take action before an incident happens
• Trip history retained for at least one full academic year so any parent complaint or safety review can be investigated
• Route optimisation to reduce fuel cost and journey time
• Centralised admin panel so the transport in-charge can see every bus on a single screen, instead of juggling separate phone calls, driver WhatsApp groups, and parent enquiries for each route

This last point is where many cheap GPS solutions fall apart. They focus only on the parent side, giving each parent a basic map view of one bus, and skip the school operations side entirely. There is no admin dashboard for the transport in-charge, no driver behaviour reports, no fleet-wide alerts. A school running 10 buses for 600 students cannot manage operations from a consumer-grade parent app.

What does school bus GPS tracking cost in Nepal

The honest range for 2026, based on what schools across Nepal are actually paying:

NepTrack installation is completely free anywhere in Nepal, with no remote-area surcharge. Full pricing details are on the pricing page, and a broader 2026 cost breakdown is in our GPS tracker pricing guide.

What schools should look for before signing up

Procurement decisions are often made under time pressure, and that is exactly when bad systems get chosen. Use this checklist before signing a contract:

1. Does the provider have a real institutional dashboard? Ask to see a live demo with multiple buses, not just one tracker.
2. Is there a parent app available on both Android and iOS? Not just a web link sent over WhatsApp.
3. How long is trip history retained? Less than one academic year is not enough.
4. What is the GPS accuracy? Ask for the exact specification. Quality devices report 2.5 metre accuracy with 33 to 72 satellite channels. Cheap devices claim 5 to 10 metres and lose lock in hills, alleyways, and dense traffic.
5. Is the data hosted in Nepal? Important for compliance and audit requirements when future government regulations arrive.
6. Does the system support Bikram Sambat dates? Important for school office paperwork and parent reports.
7. Is local support available in Nepali? Not an outsourced foreign call centre.
8. Can the school cancel anytime? Avoid long-term lock-in contracts.
9. Are SDKs and an open API available? If your school already runs its own app or website for parents, the GPS provider should offer SDKs and an open API so bus tracking can be integrated directly into your existing platform. Schools without an existing app can use the provider’s ready-made parent app instead. See NepTrack’s developer documentation for what proper SDK and API access looks like.

If a vendor cannot answer all nine clearly, that is a procurement signal in itself.

The driver behaviour question

A GPS tracker on a school bus is incomplete without driver behaviour monitoring. Three patterns matter most:

• Harsh braking, which usually means following too closely or speeding into traffic
• Rapid acceleration, which wastes fuel and unsettles children
• Idling time, which wastes fuel and increases pollution near school gates

NepTrack provides automatic driver behaviour scoring out of the box. Schools can review weekly reports and take corrective action with drivers before a small habit becomes a safety incident.

Privacy and child safety

Parents often ask one question that no GPS provider mentions in their marketing: who else can see where my child is going?

This matters. A school bus tracking system should:

• Show parents only their own child’s bus, never another route they have no business knowing
• Restrict driver location data to authorised school staff
• Encrypt all location traffic between device and server
• Never sell or share location data with third parties
• Maintain immutable audit logs of who accessed what

NepTrack follows all of these by default. Privacy is not an extra feature, it is the baseline.

SOS and emergency response

Beyond daily tracking, schools should ask what happens in a genuine emergency. The right answers:

• An SOS button on the device, accessible to the driver and bus assistant
• Automatic collision detection, which raises an alert if the bus experiences a sudden impact
• Direct alert to school office and parents within seconds, not minutes
• Escalation to higher authority if the school office does not acknowledge within the response window

NepTrack’s SOS Emergency Response covers all four. Most consumer-grade trackers cover none.

Common mistakes schools make

Patterns we see repeatedly:

• Buying the cheapest tracker on the assumption that all GPS units are the same. They are not. Cheap devices typically have low-channel GPS receivers with 5 to 10 metre accuracy, fail to hold lock under tree cover or inside narrow Kathmandu lanes, and report positions infrequently. Quality units use 33 to 72 channel receivers with 2.5 metre accuracy, hold lock in hills and dense areas, and update every few seconds. On a school bus carrying children, the difference between a position pin landing on the right gate or on the wrong street matters.
• Skipping the parent app to save money. The whole point of school GPS tracking is parent communication. Without an app, schools end up answering phone calls all day.
• Ignoring driver behaviour reports for the first few months, then being surprised when an incident happens.
• Letting the contract lapse on subscription, only to find the tracker still working but with no support when something breaks.
• Self-installing trackers on a few buses, which voids warranties and leaves wiring exposed for drivers to disconnect.

What a good rollout looks like

For a school deploying GPS tracking for the first time:

1. Week 1: Vendor meets with school transport in-charge to map routes, stops, and student-bus assignments.
2. Week 2: Devices installed across the entire fleet, free of cost. Each install takes 30 to 60 minutes per bus.
3. Week 3: Parent app rollout. Onboarding session with parents, ideally during a parent meeting day. Each parent gets installation help if needed.
4. Week 4: First weekly driver behaviour report reviewed by transport in-charge. Adjustments made if any patterns emerge.
5. Ongoing: Monthly review with vendor. Quarterly check on any feature requests from school staff.

A good vendor does not disappear after installation. They train, follow up, and adjust as the school’s needs change.

Why we built school bus tracking the way we did

NepTrack’s school bus tracking grew out of one observation: most GPS providers in Nepal sell trackers to fleet operators and treat school buses as a side category. We did the opposite. We built the school bus solution from the parent and school perspective first, then added the institutional dashboard on top.

That meant native Bikram Sambat dates across the entire platform, Nepali language support throughout, free installation across all of Nepal including remote areas, 5 year trip history retention, and a parent app that does one thing extremely well rather than a hundred things badly.

Compare detailed features on the school bus tracking page, or talk to us through the contact form for a no-pressure conversation about what your school needs.

Frequently asked questions

Is GPS tracking mandatory for school buses in Nepal?
Long-distance public buses already have a mandatory GPS requirement as of January 2026. School buses are not yet explicitly mandated, but the Department of Transport Management’s draft guidelines (Guidelines on Making Public Transport Technology-Equipped, Healthy, Safe, Dignified and Passenger-Friendly, 2026) propose making GPS and CCTV mandatory across all public transport. The draft has been forwarded to the Ministry of Physical Infrastructure and Transport for approval. Once approved, school buses are very likely to fall under this requirement. Most reputable schools are already installing GPS voluntarily ahead of the rule, partly because parents expect it and partly to avoid a rushed compliance scramble later.

How much does it cost to track one school bus?
NepTrack school bus tracking starts at NPR 10,000 to 15,000 per bus including the first year of service. Volume discounts apply for fleets of six or more buses. Installation is completely free anywhere in Nepal.

Can parents see only their own child’s bus?
Yes. NepTrack restricts parent app access to only the bus that their child is assigned to. Parents cannot see other routes or other children’s locations.

What if the bus driver disconnects the GPS device?
NepTrack devices send a power-cut alert the moment they lose power. The school transport in-charge is notified immediately. The device also has internal battery backup, so it keeps reporting for several hours even after disconnection.

Does it work in remote areas outside Kathmandu Valley?
Yes. NepTrack devices use multi-protocol GPS with LBS fallback for areas with weak GPS signal, common in Nepal’s hill regions. Installation is provided free anywhere in Nepal.

What happens during a network outage?
Devices store position data locally and transmit it once connectivity is restored. No data is lost during temporary outages.

How long is trip history retained?
NepTrack retains full trip history for up to 5 years. This is significantly longer than most providers, which keep only 30 to 90 days.

The honest summary

School bus GPS tracking in Nepal in 2026 is not a luxury. It is a baseline expectation for parents and a basic operational tool for schools. The technology has matured, the prices have stabilised, and the difference between a good system and a bad one is no longer about features, it is about discipline, support, and treating parents and schools as the actual users.

NepTrack starts at NPR 10,000 to 15,000 per bus with the first year of service bundled in. Free installation across Nepal. Native parent app on Android and iOS. Full Bikram Sambat support. Local Nepali support team. That is what we offer, and we are happy to walk any school through a demo before any commitment is made.

If you are a parent whose school does not yet have GPS tracking, share this guide with the school administration. If you are a school administrator evaluating options, use the eight-point checklist above and request demos from at least two providers before deciding. Bad choices in school transport are expensive to undo.

Reach us through the contact page or check our full FAQ for more details.

— A true story of debugging a 32‑bit kernel

A few weeks ago I was happily writing my own 32‑bit x86 operating system, AxonOS. Everything worked: the bootloader, protected mode, a simple “Hello” message. Then I decided to add keyboard input.

I wrote an IRQ1 handler, compiled, ran… and QEMU crashed hard with a General Protection Fault (#GP) on every key press. Triple fault. Reboot loop. Frustration.

After two hours of staring at the code, I finally understood the problem – and it wasn’t inside the handler logic. It was two stupid mov instructions.

🧠 What I wanted to do

• Catch keyboard interrupts (IRQ1) and read scancodes from port 0x60.
• Convert scancodes to ASCII characters and print them to the screen.
• Simple, classic OS‑dev step.

My handler looked (mostly) correct: read scancode, skip key‑release, translate via a table, write to video memory.

💥 What went wrong

Every key press caused #GP. The processor reset. No error message, no debugging output – just a black screen.

Here’s the piece of code that broke everything:

keyboard_handler:
    pushad
    mov ax, 0x1000
    mov ds, ax
    mov ax, 0xB800
    mov es, ax
    in al, 0x60
    ...

Can you spot the error?
🔍 The investigation

In real mode (16‑bit), mov ds, ax with ax = 0x1000 would set the data segment to physical address 0x10000.
In protected mode (32‑bit), segment registers hold selectors – indexes into the GDT (Global Descriptor Table).

0x1000 is a garbage selector – it points to no valid descriptor.

0xB800 is also a garbage selector.

Loading them doesn’t trigger an immediate fault, but as soon as the CPU tries to access memory through ds or es (e.g., stosw with es), it throws #GP.

The handler looked like it should work, but the environment was completely different from real mode.
✅ How I fixed it

My GDT uses the flat memory model:

Code selector: 0x08

Data selector: 0x10 (base = 0, limit = 4 GiB)

So I changed two lines:

keyboard_handler:
    pushad
    mov ax, 0x10        ; correct data selector
    mov ds, ax
    mov es, ax
    in al, 0x60
    ...

And for video memory, I stopped using segment overrides. Instead, I write directly to the linear address 0xB8000:

mov edi, [cursor_pos]
shl edi, 1
add edi, 0xB8000
mov ah, 0x07
stosw

No more es magic. Now the handler works perfectly.
📦 Key takeaways

In protected mode, segment registers store GDT selectors, not physical addresses.

Values like 0x1000 or 0xB800 are almost always invalid and will cause #GP when accessed.

Always check your GDT and use the correct selectors (e.g. 0x08 for code, 0x10 for data).

When writing to video memory, use the linear address 0xB8000 and a flat‑mapped ds/es.

One small mistake can cost you hours of debugging. But once you understand the model, it becomes obvious.
🔗 Links & resources

Source code of AxonOS (full kernel + bootloader):
👉 github.com/Paullknya/AXonOS-kernel

My GitHub profile:
👉 github.com/Paullknya

Discuss this article on the community forum:
👉 paullknya.github.io

🚀 What’s next?

Next article I’ll show how I added ring 0/3 switching and why sudo reboot asks for a password.
If you’re interested, follow me or star the repo – it helps a lot.

Happy coding, and may your selectors always be valid.