Backend Systems
APIs and application services built around clear contracts, reliable data flows, authentication, persistence, asynchronous work, and production failure handling.
Backend / Product Engineer
I build backend systems that connect products, developers, data, and AI.
I’m Naveed Ahmed, a Backend / Product Engineer working with Node.js, TypeScript, NestJS, and PostgreSQL. I build APIs, SDKs, integrations, and production systems — from enterprise document-viewing integrations at Rasterex to personalized AI infrastructure at PlayLight.
SYSTEM / REQUEST FLOW
Product / Client
request
API Boundary
route
Service
context
Data / Context
result
Useful Result
What I build
Backend engineering across product, platform, and production boundaries.
My work is centered on building the systems behind products — APIs, SDKs, integrations, data flows, background processing, and AI-enabled backend features. I care about the boundaries between systems: how they communicate, fail, scale, and remain understandable to the developers using them.
01020304
Engineering area / 01
Backend Systems
APIs and application services built around clear contracts, reliable data flows, authentication, persistence, asynchronous work, and production failure handling.
Scroll to move through the system
SYSTEM / BACKEND SYSTEMS
Request
API
Service
Database
Developer Platforms & SDKs
Developer-facing APIs, npm packages, integration contracts, documentation, and tooling designed to make complex products easier to embed and operate.
Integrations
Systems that connect products across browser boundaries, external APIs, Stripe Connect payments, calendar and meeting platforms, and customer environments.
AI-enabled Backend Systems
Backend architecture for personalized AI products involving persistent context, embeddings, vector retrieval, context construction, model APIs, and the reliability boundaries around them.
Production Engineering
Rasterex Software AS · Oslo, Norway
Decoupling an on-premise technical viewer from the customer applications that embed it.
Rasterex provides an on-premise technical drawing and document viewer. I worked on changing how customers integrate with and deploy the product: separating customer-owned UI from the Rasterex Canvas, simplifying the Windows Server installation flow, and later making evaluation possible through an npm package and sandbox environment.
01020304
01 / The problem
Customer customization was coupled to the delivered Rasterex Canvas.
Rasterex originally delivered a complete Canvas application together with three MSI components. Customers could customize code inside that delivered application. When Rasterex shipped a new feature or bug fix, updating the delivered Canvas could conflict with or overwrite those customer customizations, making upgrades harder to manage.
Scroll to inspect the integration
RASTEREX / ARCHITECTURE
Rasterex Canvas + UI
Customer customization inside Canvas
Upgrade conflicts
01 / The problem
Customer customization was coupled to the delivered Rasterex Canvas.
Rasterex originally delivered a complete Canvas application together with three MSI components. Customers could customize code inside that delivered application. When Rasterex shipped a new feature or bug fix, updating the delivered Canvas could conflict with or overwrite those customer customizations, making upgrades harder to manage.
Rasterex Canvas + UI
Customer customization inside Canvas
Upgrade conflicts
02 / Architecture change
We separated the Rasterex viewer from the customer application.
We changed the integration model so Rasterex owned the compiled Canvas/viewer while customers owned their own UI, workflows, and business logic. I built the browser postMessage bridge and integration layer that lets the customer application control Rasterex functionality without modifying the Canvas source code.
Customer Application
postMessage / integration boundary
Rasterex Canvas viewer
03 / Deployment
I simplified the on-premise installation into one primary setup flow.
The underlying Rasterex installation still required three MSI components, so I built an EXE installer that orchestrates their installation and configures IIS for the Canvas. Customers still deploy Rasterex on their own Windows Server, but they no longer need to install and wire the individual components manually.
Single EXE installer
3 MSI components + IIS
Customer Windows Server
04 / Evaluation
Developers could evaluate Rasterex without setting up Windows Server first.
The production deployment was easier, but evaluation still required the full on-premise environment. To remove that barrier, we introduced a sandbox Canvas and I built the npm integration package so developers could prototype against Rasterex, test the integration API, and decide whether it fit their product before installing the production stack.
npm package
Sandbox Canvas
Developer prototype
What I built and worked on
From integration architecture to customer deployment.
postMessage integration boundary
I built the iframe postMessage bridge that exposes Rasterex viewer functionality to the customer application. Customers can build and maintain their own UI while controlling the viewer through a defined interface instead of changing Canvas source code.
Unified on-premise installer
I built an EXE installer that coordinates the three required MSI packages and configures IIS for the Rasterex Canvas, reducing the amount of manual setup required on customer Windows Server environments.
npm package + sandbox evaluation
I built the npm integration package used with a sandbox Canvas so developers can test Rasterex from their own application without first installing the complete on-premise environment.
Customer deployment and feedback
I joined customer installation and technical meetings, helped deploy the new setup on customer servers, debugged integration issues, and contributed documentation and examples. Customers responded positively to the simpler setup and the ability to keep their UI separate from Rasterex Canvas.
Engineering impact
Separating Rasterex releases from customer application code.
- Customer UI, workflows, and business logic stay inside the customer's own application.
- Rasterex owns the compiled viewer implementation instead of customers modifying Canvas source code.
- The separation reduces conflicts between Rasterex updates and customer-written customizations.
- The three underlying MSI components are installed through one EXE-led setup flow with IIS configuration.
- Developers can evaluate the integration through npm and a sandbox Canvas before setting up the full Windows Server deployment.
Zero-to-one Product Engineering
PlayLight · Personalized AI Product
Building a backend that gives an AI product persistent, user-specific context.
PlayLight is a personalized AI product I'm building with my co-founder. I own much of the backend architecture, including how user context is stored in PostgreSQL, represented with embeddings, retrieved for individual requests, and assembled before reaching the model.
The engineering problem is larger than calling an LLM API. The backend has to preserve user isolation, decide which stored context is useful for a request, keep model input bounded, run asynchronous embedding work reliably, and handle AI providers as external dependencies rather than as the application itself.
0102030405
01 / Context & Data
Persistent personalization starts with structured user-owned data.
PlayLight stores user-specific information in PostgreSQL and uses vector embeddings to make selected context searchable. The backend keeps this data scoped to the user so later requests can retrieve relevant history instead of relying only on the current message.
Scroll through the data flow
PLAYLIGHT / DATA FLOW
Current Request
User-owned Data
PostgreSQL + pgvector
Searchable Context
01 / Context & Data
Persistent personalization starts with structured user-owned data.
PlayLight stores user-specific information in PostgreSQL and uses vector embeddings to make selected context searchable. The backend keeps this data scoped to the user so later requests can retrieve relevant history instead of relying only on the current message.
Current Request
User-owned Data
PostgreSQL + pgvector
Searchable Context
02 / Retrieval
Retrieve relevant context without crossing user boundaries.
For a new request, the backend performs user-scoped retrieval over stored context and selects information relevant to the current interaction. The current system focuses on relevance and user isolation; retrieval quality, recency, and stale-context handling are areas we are continuing to improve.
Incoming Request
User-scoped Retrieval
Relevant Context
03 / Context Assembly
Retrieved data still has to become useful model context.
Retrieved information is combined with the current request and application instructions before being sent to the model. The backend controls what context is included so the model does not receive the user's entire stored history for every request.
Instructions + Request
Retrieved Context
Context Assembly
Model Request
04 / Model Boundary
The LLM is one dependency inside the backend, not the whole system.
The model provider sits behind an application boundary. The backend prepares the request, sends only the context required for that interaction, handles the provider response, and persists application state independently of the model itself.
Application
Model Boundary
LLM Provider
Application Response
05 / Reliability & Cost
AI features also create ordinary backend engineering problems.
Embedding jobs, provider requests, stored context, and retrieval all have operational costs and failure modes. We are designing the system around bounded context, asynchronous processing, user isolation, retries, and observability so these dependencies can be operated more reliably as usage grows.
User Isolation
Async Processing
Context Budget
Operational Controls
Experience
Building deeper backend ownership across products, integrations, and systems.
My experience has moved progressively toward backend systems, integrations, developer platforms, and product ownership — from building e-commerce applications and APIs to payment and scheduling systems, production SDK work, and zero-to-one AI backend architecture.
JAN 2026 — PRESENT
Technical Co-Founder / Backend Engineer
PlayLight
Co-founded PlayLight and own much of the hands-on backend and technical architecture for a personalized AI product built around NestJS, PostgreSQL, pgvector, embeddings, retrieval, and persistent user context.
NestJS · PostgreSQL · pgvector · Retrieval · LLM Integration · User Isolation
NOV 2024 — PRESENT
Backend Software Engineer
Aridian Technologies LLC / Rasterex Software AS
Work on Rasterex’s developer-facing integration platform, including the @rasterex/viewer SDK, framework-independent integrations, iframe/PostMessage communication, documentation, customer debugging, and delivery workflows.
SDK Engineering · Integration Contracts · PostMessage · Developer Experience · Customer Integrations · 50+ Countries
OCT 2023 — JUL 2024
Backend Software Engineer
M TECHUB LLC
Built backend services for mobile products using Node.js, Express.js, and PostgreSQL, including scheduling, payments, marketplace workflows, and geospatial features.
Node.js · PostgreSQL · Stripe · Stripe Connect · PostGIS · External APIs
SEP 2021 — SEP 2023
Software Developer
Media Techtics
Built e-commerce applications and backend APIs using Node.js and Next.js, covering products, carts, checkout, orders, authentication, and payment flows.
Node.js · Next.js · REST APIs · Authentication · Payments · E-commerce
Engineering Practice
Understanding systems by measuring, breaking, and tracing them.
I use production work, controlled experiments, architecture tracing, and failure analysis to deepen my understanding of the systems I work with. My current focus is Node.js runtime behavior, PostgreSQL performance, backend reliability, and retrieval systems used in PlayLight.
System walkthrough
Tracing a PlayLight AI request end to end
A walkthrough of how a PlayLight request moves through the backend: from the NestJS API into user-scoped data access, retrieval and context assembly, through the model boundary, and back into application state.
- 01Request
- 02NestJS
- 03User Data
- 04Retrieval
- 05Context
- 06Model
- 07Response
Performance
01Understanding Node.js behavior under load
I use controlled load tests to study how concurrency, blocking work, external dependencies, and event-loop behavior affect API latency. The goal is to identify the actual bottleneck from measurements rather than optimize based on assumptions.
PostgreSQL
02Validating database performance with query plans
I am working through PostgreSQL access patterns using EXPLAIN ANALYZE, indexes, transaction behavior, and realistic datasets to understand why a query is slow before changing the schema or adding an index.
QueryPlannerExecution Plan
Reliability
03What should happen when part of the system fails?
I study failure behavior around timeouts, retries, duplicate work, idempotency, background jobs, and unavailable dependencies by reproducing those conditions and reasoning about how the system should recover.
RequestDependency ✓Dependency ✕Recovery →
AI Systems
04Evaluating retrieval instead of assuming personalization works
In PlayLight, I am working on how user-scoped retrieval, embeddings, context selection, and context limits affect model behavior. The next step is making retrieval quality measurable instead of treating a plausible response as proof that the system works.
User ContextRetrievalSelected ContextModel
About
I care more about understanding systems than collecting technologies.
I’m Naveed Ahmed, a Backend / Product Engineer based in Islamabad. I started by building web products and gradually moved deeper into backend systems, integrations, SDKs, databases, and production engineering.
Today, I work on developer-facing integrations at Rasterex and build PlayLight with my co-founder, where I own much of the backend and technical architecture.
Alongside application engineering, I work with Docker, Linux, AWS/Azure, CI/CD, and observability to help production systems ship and remain understandable.
My long-term direction is toward production, platform, systems, and performance engineering — while keeping strong product instincts and the ability to ship useful software.
- 01Build
- 02Understand
- 03Measure
- 04Explain
- 05Improve
Understand the boundary
Most difficult production problems happen between systems — APIs, browsers, databases, external services, customer environments, or model providers.
Prefer evidence
When performance, reliability, or architecture is uncertain, I prefer experiments, logs, query plans, measurements, and reproducible failures over assumptions.
Keep architecture proportional
I like clean architecture and clear boundaries, but I do not believe every product needs microservices, queues, caches, or complex infrastructure.
Own the outcome
Engineering work is not finished when code compiles. Documentation, integration experience, failure handling, deployment, and communication are part of the product.
Where I’m going
- 01Backend
- 02Production / Platform
- 03Systems / Performance
I’m deliberately deepening my understanding of Node.js runtime behavior, PostgreSQL, networking, reliability, distributed-system fundamentals, and lower-level systems concepts while continuing to build production backend products.
I also study C and lower-level systems concepts to strengthen my understanding of memory, processes, files, sockets, and the abstractions underneath the backend runtimes I use every day.
I’m interested in AI as a backend engineering problem: retrieval, data ownership, context construction, evaluation, security, cost, and reliability — not as a replacement for strong software engineering.
Let’s talk
Looking for a backend engineer who can own more than just endpoints?
I’m open to backend, product engineering, developer-platform, integration, and selected AI-backend opportunities. If you’re building a serious product and think my experience could be useful, I’d be glad to talk.
Email me technaveedahmed@gmail.comDownload résumé